This is a really silly request. Please feel free to completely ignore it, especially if it's not easy to implement.

Sometimes I'd like to have the player boot into forced-DC mode, but only once. For instance, to quick-test a piece of software like GPSapp that I only run in DC mode. Or maybe to change one of the DC-specific settings while I'm in the warm comort of my office. In other words, I don't want to have to make two trips into the hijack menu just for the one reboot.

Is it possible to have the kernel look and see if one or more buttons is being held down at boot time, and if so, have it force AC or DC for that boot depending on which button is pressed?

Note that this wouldn't change the flash memory setting that governs the next boot, it would just force the mode for that particular boot that's currently in progress. You wouldn't have to waste any flash bits on it.

Does this sound easy?

I don't know, but I'll guess it needs to decide before it can check buttons.

Ah, well never mind then if that's the case.

I can't remember exactly but don't we only get notification of button press and then button release? If so then holding down the button wouldn't work unless you hit it at exactly the right point where the kernel is watching.

I'm racking my brains to think what within the kernel needs to know the state and what might break if the state, ahem..., suddenly changed. As far as the player software is concerned, that's fairly trivial - kill it and when it reloads it should pick up the change.

But the kernel...
I guess that we'd have to reparse config.ini for ;@AC / ;@DC parameters. I guess that this is the important part and the reason for the feature request - testing EXEC lines and the like. I don't know how messy this part would be or whether it's even feasible. There's a whole bunch of stuff relying on config.ini options, eg khttpd, kftpd, ir_translate and so on. I'm fairly sure that much of this is multithreaded so somehow all those threads would need to be killed and restarted etc.

I wonder though...,if the button thread starts before config.ini gets parsed then it might be possible to do something silly like boot with an obscure mapping (eg button.L = force DC, button.R= force AC) and overwrite that mapping when we read config.ini (but obviously before ir_translates get applied).

I don't really know. I'm just speculating.

The state wouldn't suddenly change though if we check the button/whatever early enough. We wouold get all those problems if we allowed the user to change states when everything was up and running though.

I'm trying to think of a nice way of notifying the kernel what mode you want to be in. If we can tell if a button was held down when booting then we just need to write the code to query it and put it in roughly the same place that the existing flash check is. I've no idea how hard it will be to poll the buttons this early on in the boot process.

The hard part is if we can't do this detection because it only does state changes. The userland interface only does state changes but I've not looked at the kernel driver to see if it knows exactly what state it is.

It's something to ponder and I need to read the kernel driver to see how it does it.

Heh, like I said, if it's not an easy/quick thing, then never mind.

Oh no. It's an interesting idea and could be used for other things. Not quite sure what other things but it's a possibility

I could do this, using a memory signature or some such thing.

But I don't want to.

You see, the player firmware already has a similar idea, used to detect "first boot" (after poweron). And one result of that is that sometimes "reboot" hangs, because (my guess) of the "first boot" flag being zero, the firmware doesn't reinitialize everything in quite the same way as it would after a power on.

Very hard to debug, and I can see similar scenarios might emerge if we had Hijack doing anything other than a clean start-up each time.

Cheers