Setting Num Lock on

Is there a way to force a keyboard’s num lock key to the ON state?

OS_Byte 202 followed by OS_Byte 118 should do the trick, e.g.:

SYS "OS_Byte",202,0,-4
SYS "OS_Byte",118

SYS “OS_Byte”,202,0,-4
SYS “OS_Byte”,118

Thanks, a useful pointer.

the -4 needs to be 1<<4 however.

SYS “OS_Byte”,202,0,-4
SYS “OS_Byte”,118

I got confused there.

What seems to be working is

SYS “OS_Byte”,202,0,NOT (1<<2)
SYS “OS_Byte”,118

The difference is that -n produces the 2’s complement of n, whereas NOT produces the 1’s complement.

Just one side comment – be careful of releasing any software that does this, as some laptop keyboards (eg. ARMbook) use numlock to re-assign alphabetic characters to numerical ones for the purpose of re-creating a keypad in a confined space. Example – OvPro did this (fix available on the ARMbook download site) and continually forced it on, making it impossible to type alphabetic characters on half the keyboard.

There’s also a trend towards keyboards without keypads to save space on the desk, these could (I’m not saying they do) apply the same logic.

So now it works on the ARMX6 keyboard. It doesn’t work on the rPi numeric keypad which I am using instead of a keyboard.

os_byte 202 can return the value it found before modification. The value retturned on a pi seems to be random. However if I also plug a keyboard into the pi, the nums lock key is reset correctly, and the returned values make sense for the keyboard state.

It seems that the pi isn’t treating the keypad as a keyboard, although the keypresses on it are returned correctly. What am I missing?

Following Andrew’s comment, the application for this is very specific – rPi’s with a 7 inch screen, and a keypad instead of a keyboard for data entry. I want to stop the user accidentally turning off num-lock, because that makes 4 of the number keys into cursor keys, and will confuse them.

If there is a way to identify that the input device is a keypad that would be good, and if then the num lock could be controlled, even better.

Following Andrew’s comment, the application for this is very specific – rPi’s with a 7 inch screen, and a keypad instead of a keyboard for data entry. I want to stop the user accidentally turning off num-lock, because that makes 4 of the number keys into cursor keys, and will confuse them.

If there is a way to identify that the input device is a keypad that would be good, and if then the num lock could be controlled, even better.

Hum… I could use *usbdevices and look for “Vendor ID 13bA product ID 0001”, which is the keypad. Then I just need to know how to alter the num lock status on this device.

Might be worth seeing if you can use KeyMapper module to remap the numlock key if the OS is getting said keypress. I have a bad feeling that your USB input device might be handling that in hardware somehow, and returning cursor keys when it is disabled, and numeric keys when not. Ie. it is acting as a toggle rather than a key.

Possible solution (again using KeyMapper) would be that when the program is running, you could remap the cursor keys to the appropriate number keys. This would make cursor keys fail, of course, but whilst your program is active, it sounds like they wouldn’t be needed.

as it is used in a specialist way, could you not physically block the NunLock Key?

That way it cannnot be pressed.

I have a bad feeling that your USB input device might be handling that in hardware somehow, and returning cursor keys when it is disabled, and numeric keys when not. Ie. it is acting as a toggle rather than a key.

I don’t think so. I connected the keypad to a phone charger to power it. The numlock key doesn’t toggle the LED.

Possible solution (again using KeyMapper) would be that when the program is running, you could remap the cursor keys to the appropriate number keys. This would make cursor keys fail, of course, but whilst your program is active, it sounds like they wouldn’t be needed.

That would be good, except that when 2,4,6 and 8 generate cursor key codes, the 5 key in the middle of them generates nothing. The numlock doesn’t generate a code that the application can see, but then it doesn’t do that with a real keyboard either.

I also tried when I had both keypad and keyboard connected, turning num lock on and off on the main keyboard. It changed the key codes generated by the keyboard’s pad, but not those for the separate keypad.

It looks to me as though RISC OS is handling them as two distinct devices, with the numlock key acting on the input stream for each separately.

I’ll try keymapper. I’m thinking if I can find out what key code numlock on the keypad generates, I could map that to something that does nothing. For the matter of that, I could do it for the standard code, if I detect that the keypad is present (see above for that), as I wouldn’t then need the numlock from a standard keyboard. So If I map it to something like space or null, and the LED still toggles – ?!?!?

Sounds like you might need a bespoke HID driver. Either the NumLock is being handled by the device and not generating a key press, or its generating an extended value that RISC OS doesn’t understand. The same goes for 5 when NumLock is off.

If you want to try reading the USB data, I posted some example BASIC code for reading keyboard HID data directly here you’ll want to see if 5 generates key up/down events with/without NumLock.

Thanks. I’ve got that running.
Numlock doesn’t produce a code.
With numlock on, 5 produces 5d
With numlock off 5 produces 53 then 5C then 53
Left arrow (4) produces 53 then 5C then 53

The commented output follows:

Nums lock ON Key Pressed

00 00 5C 00 00 00 00 00 4
00 00 00 00 00 00 00 00

00 00 60 00 00 00 00 00 8
00 00 00 00 00 00 00 00

00 00 5E 00 00 00 00 00 6
00 00 00 00 00 00 00 00

00 00 5A 00 00 00 00 00 2
00 00 00 00 00 00 00 00

00 00 5D 00 00 00 00 00 5
00 00 00 00 00 00 00 00

00 00 56 00 00 00 00 00 -
00 00 00 00 00 00 00 00

Nums lock OFF

00 00 53 00 00 00 00 00 8
00 00 60 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 53 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 53 00 00 00 00 00 8
00 00 60 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 53 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 53 00 00 00 00 00 4
00 00 5C 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 53 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 53 00 00 00 00 00 6
00 00 5E 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 53 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 53 00 00 00 00 00 2
00 00 5A 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 53 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 53 00 00 00 00 00 5
00 00 5D 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 53 00 00 00 00 00
00 00 00 00 00 00 00 00

00 00 56 00 00 00 00 00 -
00 00 00 00 00 00 00 00

00 00 58 00 00 00 00 00 Return

So the keypad returns extended codes for the cursor keys and 5 with numlock off, and RISC OS understands them except for the 5 key. It translates the cursor sequences into the RISC OS 16-bit cursor codes, and ignores the 5.

I think this says that I can only disable the numlock physically, either by blocking the movement of the key, or cutting a PCB track to the keyswitch.

So on investigation, the keys press down on a plastic membrane. The easiest way to disable the key is to remove the physical key, leaving a gap. The tidy way would be to remove the bump on the bottom of the key so it doesn’t touch the membrane.

Or I just live with it.

It turns out that the bump is a separate component from the keytop, so it’s easy to remove. Job done.

Or put a piece of tape over the contacts on the membrane, so the key can’t close them. As a bonus, it’s reversible.

I think this says that I can only disable the numlock physically, either by blocking the movement of the key, or cutting a PCB track to the keyswitch.

Or tweaking the Keyboard Driver’s mapping table so that both sets of codes map to the same internal keys.

Or put a piece of tape over the contacts on the membrane, so the key can’t close them. As a bonus, it’s reversible.

Removing the bump is reversible, as long as i don’t lose them.

Or tweaking the Keyboard Driver’s mapping table so that both sets of codes map to the same internal keys.

Yes, as although RISC OS doesn’t present the 5 key to the application, is does receive a code.

Looking again at those extended sequences, and wondering how RISC OS recognises them, I am wondering whether it is sending “num lock”, “numeric key code”, “num lock” when it has its num lock LED unlit, thus fooling RISC OS into thinking it’s a sequence of three keys.

&53 is the USB HID scancode for NumLock, yes.

With NumLock off, it’s sending:

NumLock down
Number key down
Key up
NumLock down
Key up

Which appears a bit strange. You should be able to force NumLock on in RISC OS and remap the NumLock key so it’s ignored.