disable numlock in integrated keyboard and enable it in external one

juanp_1982 · 2013-04-13 20:12:05

Hi Everybody,

I have two keyboards one integrated to my laptop(without num keyboard) and another wireless(with num keyboard). the problem that I have, its that when numlock is on and I'm using the keyboard from my laptop, some keys (i o p k l ; m , .) become in numbers (simulating the num keyboard) so I have to hit the numlock button, the opposite happen when I'm using the wireless keyboard. so I came up with a piece of code that I inserted in /etc/gdm/Init/Default

if [[ -f /dev/input/by-path/pci-0000:00:14.0-usb-0:2:1.2-event-kbd ]]; then
         numlockx on
fi

this file /dev/input/by-path/pci-0000:00:14.0-usb-0:2:1.2-event-kbd represent my wireless keyboard, so the logic is very simple, when the file exist, turn on numlock, otherwise leave it off. the problem is that this file is created after I press any key so, if I don't press any key this file is not created and then numlock always is going to be off. can any one give me a hint? or another approach? please

have a nice day!

barto · 2013-04-14 23:37:48

I’m not sure I understand you, but you could make up an udev rule to execute “numlockx on” when the external keyboard is, let’s say so, attached. Or if you would like to be able to use both your keyboards simultaneously, you could leave numlock off, and remap num keypad keycodes to behave as if numlock was on (see xmodmap).

Edit: typo

Last edited by barto (2013-04-15 08:32:52)

juanp_1982 · 2013-04-15 01:48:52

thanks so much! that's a good hint! (to use a udev rule). just to clarify I want to

use one keyboard at the time
use "numlockx on" only in the external keyboard

however the system only recognize the external keyboard until I press a key.

if you have any other question, please let me know! :-)

thanks once again

barto · 2013-04-15 08:37:08

Yes, I have a question: why would you need numlock to be on before pressing any key?

juanp_1982 · 2013-04-15 18:56:04

it's doesn't have to be before or after pressing any key, what I meant is that the computer doesn't see the keyboard until I press any key, hence it cannot create the file mentioned in my first post
Today I'll research about udev rules :-)

thanks!

barto · 2013-04-16 11:03:37

You don’t need to monitor the creation of that file, or do anything inside the GDM init file since it is executed only once. Udev is aware of new hardver attached at anytime, so it is able to issue a command exactly when you press a key on your external keyboard (as apparently only pressing a key on the keyboard is interpreted as the keyboard being attached).

juanp_1982 · 2013-04-16 17:33:55

you are right, I started to research about udev rules and that is what i need, the problem is that I haven't had time to dig in but I'll get it this week :-) I'm reading:

if you know another source that I might be missing please let me know :-)
thanks!

juanp_1982 · 2013-04-21 17:58:16

ok, I created two rules, one for when the keyboard is connected and the other one when it's disconnected

/etc/udev/rules.d/80-addkeyboard.rules

#!/usr/bin/env bash

KERNEL=="event%n", SUBSYSTEM=="input", ATTR{name}=="Logitech Unifying Device. Wireless PID:4004", ATTR{phys}=="usb-0000:00:14.0-2:1", KERNELS=="0003:046D:C52B.0003", SUBSYSTEMS=="hid", DRIVERS=="logitech-djreceiver", ENV{action}=="add", RUN+="/usr/bin/numlockx on"

/etc/udev/rules.d/80-removekeyboard.rules

#!/usr/bin/env bash

KERNEL=="event%n", SUBSYSTEM=="input", ATTR{name}=="Logitech Unifying Device. Wireless PID:4004", ATTR{phys}=="usb-0000:00:14.0-2:1", KERNELS=="0003:046D:C52B.0003", SUBSYSTEMS=="hid", DRIVERS=="logitech-djreceiver", ENV{action}=="remove", RUN+="/usr/bin/numlockx off"

both have executable permissions
then I tested them with: udevadm test $(udevadm info -q path -n /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.2/0003:046D:C52B.0003/input/input11/event11) 2>&1 and they showed on the screen but when I reboot the computer didn't work, can you see what I did wrong or what I am missing? please

thanks in advance

WorMzy · 2013-04-21 18:03:52

Why have you put a bash shebang in there?

Also, you'll probably want the rules in your initramfs if you want them to be applied at boot time.

juanp_1982 · 2013-04-21 18:48:34

WorMzy wrote:

Why have you put a bash shebang in there?
Also, you'll probably want the rules in your initramfs if you want them to be applied at boot time.

I read here this

udev does not run these programs on any active terminal, and it does not execute them under the context of a shell. Be sure to ensure your program is marked executable, if it is a shell script ensure it starts with an appropriate shebang (e.g. #!/bin/sh), and do not expect any standard output to appear on your terminal.

could you tell me how I add these rules to the initramfs? please, (something tells me is related to mkinitcpio, but I'm not sure)

Last edited by juanp_1982 (2013-04-21 18:51:00)

WorMzy · 2013-04-21 19:44:54

Fair enough. I've never used external applications with udev rules before, so I can't say whether that's necessary or not. As long as udev doesn't get confused by the shebang, I guess it doesn't matter whether it's there or not.

Have a look at /etc/mkinitcpio.conf, the comments should point you in the right direction. Remember to regenerate your initramfs after you've made the changes.

juanp_1982 · 2013-04-22 05:34:39

WorMzy,
even though I read what I read, I'm pretty sure you were right, I don't need the shebang line because the one who process the file is udev not bash. on the other hand I also looked into other rules and none of them have them. so I removed it and also remove the executable permission.

the bad news is that I don't see how to put my rules in my initramfs. do you have any other hint?

barto · 2013-04-23 02:25:47

The paragraph regarding the shebang and being marked executable is about the command you want udev to run at the specified event, not the udev rule itself. Numlockx is by default fully prepared to be run, so no further actions needed.

Furthermore, I’m pretty sure that you don’t have to mess with initramfs.

And one more hint: the two rules can be placed in one common file to ease their management. In two separate lines, of course.

And for your rules:
1. Some values at the attribute matching key-value pairs contain numbers I’m not sure are constant. If you detach and reattach the keyboard, these values seem likely to change, so they won’t match next time, and numlockx won’t be executed. (Especially “PID:4004” and “usb-0000:00:14.0-2:1” appear suspicious.) (Doesn’t the keyboard have a USB RC unit? Doesn’t its plugging in itself provide a suitable udev event?)
2. As far as I know there are no such things that ENV{action}=="add" or ENV{action}=="remove". They should be ACTION=="add" and ACTION=="remove" respectively.
3. You are attempting to run an X program from a non-X environment. You should add ENV{XAUTHORITY}="/home/<your user>/.Xauthority" and ENV{DISPLAY}=":0".

juanp_1982 · 2013-04-23 04:38:16

barto wrote:

The paragraph regarding the shebang and being marked executable is about the command you want udev to run at the specified event, not the udev rule itself. Numlockx is by default fully prepared to be run, so no further actions needed.
Furthermore, I’m pretty sure that you don’t have to mess with initramfs.
And one more hint: the two rules can be placed in one common file to ease their management. In two separate lines, of course.
And for your rules:
1. Some values at the attribute matching key-value pairs contain numbers I’m not sure are constant. If you detach and reattach the keyboard, these values seem likely to change, so they won’t match next time, and numlockx won’t be executed. (Especially “PID:4004” and “usb-0000:00:14.0-2:1” appear suspicious.) (Doesn’t the keyboard have a USB RC unit? Doesn’t its plugging in itself provide a suitable udev event?)
2. As far as I know there are no such things that ENV{action}=="add" or ENV{action}=="remove". They should be ACTION=="add" and ACTION=="remove" respectively.
3. You are attempting to run an X program from a non-X environment. You should add ENV{XAUTHORITY}="/home/<your user>/.Xauthority" and ENV{DISPLAY}=":0".

Hi! barto,

you are right, I re-read the article that I was reading, and I changed from this ENV{action}=="add" or ENV{action}=="remove" to this ACTION=="add" and ACTION=="remove"

I understand that numlockx is a X program, and need this ENV{XAUTHORITY}="/home/<your user>/.Xauthority" however I need to run this command even before I log in. I'll check it out

so far I got this

KERNEL=="event%n", SUBSYSTEM=="input", ATTR{name}=="Logitech Unifying Device. Wireless PID:4004", ATTR{phys}=="usb-0000:00:14.0-2:1", KERNELS=="0003:046D:C52B.0003", SUBSYSTEMS=="hid", DRIVERS=="logitech-djreceiver", ENV{DISPLAY}=":0", ACTION=="remove", RUN+="/usr/bin/numlockx off"

KERNEL=="event%n", SUBSYSTEM=="input", ATTR{name}=="Logitech Unifying Device. Wireless PID:4004", ATTR{phys}=="usb-0000:00:14.0-2:1", KERNELS=="0003:046D:C52B.0003", SUBSYSTEMS=="hid", DRIVERS=="logitech-djreceiver", ENV{DISPLAY}=":0", ACTION=="add", RUN+="/usr/bin/numlockx on"

thanks so much for your hints!!!

Arch Linux

#1 2013-04-13 20:12:05