
corbet at lwn
May 10, 2012, 3:51 PM
Post #14 of 15
(85 views)
Permalink
|
|
Re: [now bisected] Weird bluetooth keyboard regression - just me?
[In reply to]
|
|
On Wed, 2 May 2012 23:27:24 +0100 Matthew Garrett <mjg [at] redhat> wrote: > Hm. Well, easiest thing to do would just to be to delete that for the > moment and make sure that things work again - beyond that it's me trying > to figure out how to write a udev file to do the right thing when I > don't have hardware that has this layout. I'll see if I can mock it up. I get the implied hint there ... :) Every time I delve into udev I have to learn it all over again. I've just done a bit of that. Looking at the 42-usb-hid-pm-rules file you sent me, I see this at the end: ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="removable", GOTO "usb_hid_pm_end" ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", ATTRS{removable}=="unknown", GOTO "usb_hid_pm_end" ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", ATTRS{removable}=="fixed", TEST=="../power/control", ATTR{../power/control}="auto" LABEL="usb_hid_pm_end" The two GOTO rules are the ones you've added over what Rawhide provided me. By a laborious path I figured out that they were not working as expected, while if I instead just commented out the final rule my keyboard was happy again. Then I looked closer and noticed that they read: GOTO "usb_hid_pm_end" GOTO considered harmful indeed, at least when it's written as above, instead of: GOTO="usb_hid_pm_end" Once I dug up a couple of spare equals signs and stuffed them in there, things worked. Sure was nice of udev to tell me about the problem... Sorry it took me so long to figure that out, and thanks for the help. Can you get the fixed rules into rawhide, or should I go bug somebody? Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo [at] vger More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|