Num lock startup oddity

Just noticed that when my Beagleboard -xM boots the three lamps (Num/Caps/Scroll lock) light as usual but when they extinguish the num lock lamp remains lit. Touching a key or mouse button, basically any activity, causes the lamp to extinguish so it doesn’t affect usage.

Backtracking versions, the behaviour changes somewhere between 30th January and 4th February ROMs. The keyboard’s attached to the OTG.

when they extinguish the num lock lamp remains lit.

That’s just the default value, set in the time of King Arthur. It looks like when I shuffled stuff on 3rd Feb to fix one issue, I neglected to account for that OS_Byte variable having sideeffects (ie. it’s not sufficient to just update the variable, it needs explicitly pushing to the keyboard).

Try this test ROM and see if that solves it.

I’ve often thought, right back to the Risc PC, that it’d be useful to have the keyboard LEDs count down (or do some other animation) in the window within which you need to be pressing magic keys. However, I’m not sure if all keyboards have them in order Num/Caps/Scroll so maybe flash rather than count?

With that ROM the num lock lamp does extinguish though much later than the other two (just before PlingBoot, I guess).

I’m not sure if all keyboards have them in order Num/Caps/Scroll

This cheapo Zippy mini keyboard does.

One thing to be wary of with flashing the LEDs is that compact keyboards, where the numpad is overlaid ontop of the main alphabet, will generate different key codes depending on whether num lock is enabled or not. This may in turn have an effect on the user’s ability to press the desired keys during the keyboard scan. So I’d say flash caps lock (+ scroll lock?) but leave num lock to be processed normally.

This cheapo Zippy mini keyboard does.

So does my cheapo keyboard; but I’ve seen some with key lights under the keys.

I’d say use a binary code and leave it up to the user to decipher it…

I’ve often thought, right back to the Risc PC, that it’d be useful to have the keyboard LEDs count down (or do some other animation) in the window within which you need to be pressing magic keys.

Could it not mirror PC BIOS behaviour and prompt for the check after the video is initialised to a standard VGA mode?

I’ve often thought, right back to the Risc PC, that it’d be useful to have the keyboard LEDs count down (or do some other animation) in the window within which you need to be pressing magic keys.

I tried this, and concluded it was ugly and confusing. Because we only use a 3s window to capture keys your brain has to process what the animation means (which kind of looked like an error when I tried toggling caps lock and scroll lock) which is barely enough time before the final state of num lock is reached, which was also confusing. Counting down from 3 was also a non starter because the loop exits early if a key is spotted, so there’s more random fairy light state changes.

For now, I’ve at least fixed Frederick’s original report.

Though it hasn’t made it to daily betas. Was it supposed to?

Though it hasn’t made it to daily betas.

Give it chance! The change was only done 2 hours ago … maybe the overnight fairies will manage to play nicely and include it in the next daily build.

Don’t get your knickers in a twist. I hadn’t seen it in the CVS when I wrote and the reference was to our posts up thread in February.