udev rules not loading for G710 keyboard.

jpsimard · 2014-02-10 14:42:18

While trying to get the extra keys of the logitech G710 to work, I have found a good topic on the Arch Linux Forums:

So, I installed the driver talked about in the forum from the AUR, put in the suggested udev rule in /etc/udev/rules.d, and technically things work. My problem is that if I shutdown the system, the rule is not applied upon booting the next morning. I actually have to unplug and replug the keyboard for the rule to be applied.

The rule is as suggested, and goes as following:

ACTION=="add", SUBSYSTEM=="hid", DRIVER=="hid-generic", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c24d",  RUN+="/bin/sh -c '/sbin/modprobe hid-lg-g710-plus; if test -d /sys/bus/hid/drivers/hid-generic && test -d /sys/bus/hid/drivers/hid-lg-g710-plus; then /bin/echo -n %k > /sys/bus/hid/drivers/hid-generic/unbind; /bin/echo -n %k > /sys/bus/hid/drivers/hid-lg-g710-plus/bind;fi'"

I have tried using "udevadm control --reload-rules" and "udevadm trigger" together to try and get the rule for the keyboard to be applied, but it doesn't help. If I do udevadm trigger --verbose, the keyboard is listed, and so udev seems aware of it correctly. I tried subtracting and adding things to the rules like modealias stuff and so on, but that didn't change anything. I'm no udev rules expert, so I'm unsure as to what I should try, or if even the rule is at fault. Once the rule is applied, suspending doesn't affect the keyboard once the proper driver is applied, only shutting down is the problem.

As a wild guess, since I run XFCE, I tried MATE just in case there was somehting in my DE interfering, but the problem remains under MATE too. Since fooling around with the keyboard settings in XFCE seemed to help, I though I'd give a go with another DE, in the hope a finding a clue, but that didn't go anywhere.

That being said, I was wondering if anyone had any suggestions as to what to try next. I got the keyboard really cheap for what it is, in particular since it is a brown cherry switch equipped mechanical keyboard, so even without the extra keys it was a good buy. But if I get those keys runnig reliably after a reboot, I'll be a happy camper.

Rexilion · 2014-02-16 18:38:05

I can see you are testing for the existance of several directories. A few scenario's why your setup fails come to mind:

- race condition -> hid_generic is not there yet
- race condition -> hid-lg-g710-plus is not there yet

OR: Your initramfs calls udev to process all of it's events. Big chance your rule is not included in it's default ruleset. This will cause udev to correctly detect the keyboard, but not act on since the rule you provided is not there (assumption since you did not indicate which file you put it). lsinitcpio lists the following:

lsinitcpio wrote:

./usr/lib/udev/rules.d/11-dm-initramfs.rules
./usr/lib/udev/rules.d/69-dm-lvm-metad.rules
./usr/lib/udev/rules.d/11-dm-lvm.rules
./usr/lib/udev/rules.d/95-dm-notify.rules
./usr/lib/udev/rules.d/13-dm-disk.rules
./usr/lib/udev/rules.d/10-dm.rules
./usr/lib/udev/rules.d/80-drivers.rules
./usr/lib/udev/rules.d/64-btrfs.rules
./usr/lib/udev/rules.d/60-persistent-storage.rules
./usr/lib/udev/rules.d/50-udev-default.rules

Try adding your rule there and regenerate your initcpio afterwards to apply the change.

jasonwryan · 2014-02-16 19:42:37

Use SYSTEMD_WANTS, don't abuse RUN+=

man udev wrote:

This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.
Starting daemons or other long running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.

Rexilion · 2014-02-16 19:46:02

Looks like one of 'very short-running foreground tasks'. But maybe that is something to wonder as well.

jpsimard · 2014-02-16 19:55:22

Thanks for your answer Rexilion.

The author of the module, and the rule, suggest to put the rule in /etc/udev/rules.d under the file name 90-logitech-g710-plus.rules. So that is what I have tried up to now, along with putting the file in /usr/lib/udev/rules.d and changing the preceding number to 10 instead of 90. The only thing that my tinkering has done is that changing ACTION=="add" to ACTION=="add|change" has allowed udevadm trigger to apply the rule. Of course, I could use that to generate some real ugly workaround, but I would rather not. Otherwise, from what I have seen, you are probably right about a race condition, but I have been in the dark as to how to resolve it.

At this point, I have put the rule in /usr/lib/udev/rules.d and used "mkinitcpio -p linux" to rebuild the image, but it doesn't make a difference as to what default rules are in the image. In mkinitcpio.conf, I have the udev hook, but I figure that is kind of defautl, am I to modify that hook? What am I missing? I have read and reread the wiki about udev, and mkinitcpio, but I'm very unclear as to how to add the rule for the keyboard to the default set.

@jasonwryan: Perhaps I'm being stupid, but is loading a module and binding it to the keyboard considered a long running process? I would have thought it is an event which is very short and needs no further attention or resources once it is done.

jasonwryan · 2014-02-16 20:03:16

Your tests, and the possibility as Rexilion points out, that the directories might not yet be created suggest the potential for blocking.
Write a service file and find out.

Rexilion · 2014-02-16 20:06:02

What I really intended to suggest is to test the most likely hypotheses: initcpio does not contain the rule.

Just bluntly add the rule to /usr/lib/udev/rules.d/50-udev-default.rules (at the top or bottom) and then rebuild the initcpio.

This is just for tests, to see if my hypotheses holds. The race condition I told you earlier should give you varying results which is not the case. From what I gather, you get 0 result everytime. So go with the above. Good luck!

jpsimard · 2014-02-16 20:34:41

Well, I never thought buying a keyboard would have been a learning experience! The only reason I bought the damn thing was that it was so damn cheap for what is underneath, I never even given much thought about the extra keys.

Anyway...

For giggles, I've tried the blunt approach with adding the rule to 50-udev-default.rules, but still no luck.

So off I go to learn how to write a service file. Thanks to you both for your time, you've have given me more to tinker with just when I was wondering what I was supposed to do next. And I have not better to do than this on a cold winter day. I'll post back if I get stuck again, but hopefully I'll be able to move on to a final solution without futher assistance.

jasonwryan · 2014-02-16 20:37:24

Good luck!

Rexilion · 2014-02-17 06:55:00

That's odd. I thought I nailed it.

You didn't forget to include the hid-generic and hid-lg-g710-plus in initcpio?

You could create a file in /etc/initcpio/install called myfunnykeyboard and make it contain this:

#!/bin/bash

build() {
	add_module hid-lg-g710-plus
}

Then in mkinitcpio.conf you should add myfunnykeyboard to the HOOKS array in mkinitcpio.conf.

Check that your newly generated initrd contains both hid-generic (which I think it already has) and hid-lg-g710-plus (since it's an out of tree module).

jpsimard · 2014-02-17 12:36:07

@Rexilion

Maybe I did it wrong, but I will avoid the idea of tweaking initcpio for now. My system is pretty basic, not much in the way of tweaks, and it has been really stable too. So, I'm feeling kind of scared to fool around with initcpio too much. If I can manage things with udev and a service file, I feel safer, for a deletion or a simple command, will be enough if things go wrong.

And then there's the fact that the driver does work, but I haven't been using it for long. Including it in the image generated by mkinitcpio seems an unecessary risk. Not that I understand C all that much either, so I'm not qualified to evaluate if the code is "clean". I mean, I did look at it, and it seems clean but my understanding is very limited. If ever thing are ok now, but go south later, simply disabling some service seems, again, more expeditious.

I'll keep your suggestion in mind if I don't manage otherwise. If you think I'm wrong about this, feel free to chime in.

Rexilion · 2014-02-17 12:43:28

If you wonder about the quality of the module, then you should not use it at all. If something goes south, you can rebuild initcpio without it by excluding the myfunnykeyboard out of your HOOKS array in /etc/mkinitcpio.conf. Furthermore, including it in your initcpio allows you to use your keyboard in case your system fails to mount for whatever reason.

That being said, I have no idea how a service file would work around it. If it involves polling, it's not a really nice solution.

And my last pitch: If you do it with initcpio, you can apply your modifications in the form of new files. Not having to adapt existing configuration is a nice thing I think. But, to be honest, this goes for the .service file as well I think.

brebs · 2014-02-17 13:05:31

jpsimard wrote:

RUN+="/bin/sh -c '/sbin/modprobe

Run a script in /root/bin/ instead, and add lots of lovely debugging info to it, e.g. writing to a logfile you create in /tmp/.

The module might need a second, to initialize, as with e.g. the iwlwifi module.

Arch Linux

#1 2014-02-10 14:42:18

udev rules not loading for G710 keyboard.

#2 2014-02-16 18:38:05

Re: udev rules not loading for G710 keyboard.

#3 2014-02-16 19:42:37

Re: udev rules not loading for G710 keyboard.

#4 2014-02-16 19:46:02

Re: udev rules not loading for G710 keyboard.

#5 2014-02-16 19:55:22

Re: udev rules not loading for G710 keyboard.

#6 2014-02-16 20:03:16

Re: udev rules not loading for G710 keyboard.

#7 2014-02-16 20:06:02

Re: udev rules not loading for G710 keyboard.

#8 2014-02-16 20:34:41

Re: udev rules not loading for G710 keyboard.

#9 2014-02-16 20:37:24

Re: udev rules not loading for G710 keyboard.

#10 2014-02-17 06:55:00

Re: udev rules not loading for G710 keyboard.

#11 2014-02-17 12:36:07

Re: udev rules not loading for G710 keyboard.

#12 2014-02-17 12:43:28

Re: udev rules not loading for G710 keyboard.

#13 2014-02-17 13:05:31

Re: udev rules not loading for G710 keyboard.

Board footer