* Re: manually generate event, possible ?
From: Martin Pitt @ 2010-11-02 13:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020649.oA26n1vk004765@dcnode-02.unlimitedmail.net>
Hello,
J. Bakshi [2010-11-02 16:13 +0530]:
> udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
Try --sysname-match=input11. Also, it's "--action", not "action".
Also, you really don't want "add", use "change" (which is the default
now).
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* can we print the attr{} also ?
From: J. Bakshi @ 2010-11-02 12:31 UTC (permalink / raw)
To: linux-hotplug
Hello,
With the help of "udevadm monitor --environment" I can find the following when inserting my usb pendrive
````````````````````````````
ID_VENDOR_ENC=JetFlash
ID_VENDOR_ID\x058f
ID_MODEL=Transcend_8GB
ID_MODEL_ENC=Transcend\x208GB\x20\x20\x20
ID_MODEL_IDc87
ID_REVISION=8.07
ID_SERIAL=JetFlash_Transcend_8GB_MTIKD5C1-0:0
ID_SERIAL_SHORT=MTIKD5C1
````````````````````````
Can I send these information through notify-send ? I have already tried with [ notify-send %d-%k-$attr{ID_VENDOR} ] and the $attr{ID_VENDOR} is blank.
I have also tried with "udevadm info -a -p /sys/block/sdc" and foound
`````````````````
ATTRS{vendor}="JetFlash"
ATTRS{model}="Transcend 8GB
```````````````````````
using these as $attr{vendor} also has no effect.
Could anyone kindly give me a clue please ?
Thanks
^ permalink raw reply
* [bisected] Commit e17f9c3cd58 doesn't let my notebook monitor sleep
From: Rogério Brito @ 2010-11-02 12:05 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
Hi there.
After a very painful bug-hunting that involved switching back and
forth between distributions (Debian and Ubuntu) and many versions of
them, I finally found that the culprit for my notebook's dpms not
being able to blank my monitor screen under X was commit
e17f9c3cd589ee50ba74976d11a5804ca2562472.
Indeed, the notebook that I have *is* an MSI one (and this thing is
quite buggy) and reverting only that makes everything work again.
This was hunted, bisected, tested, and retested.
Just for the record, the symptoms when I have that commit in are that
my notebook monitor flickers *a* *lot*, like if it were trying to go
to sleep and then a keyboard event preventing it from actually
sleeping. And it doesn't sleep. OTOH, when I leave it off, everything
works fine, with the exception of the kernel generating messages
telling me that some keycodes are not known (as would be expected). I
am attaching a dmesg snippet showing the kernel complaining about the
keycodes.
Perhaps a good fix would be something related to
/lib/udev/keymaps/micro-star, but I fear that we may have to
workaround things here due to a buggy hardware.
Regards, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
[-- Attachment #2: bad-keymap.txt --]
[-- Type: text/plain, Size: 2782 bytes --]
[ 16.714504] r8169 0000:03:00.0: eth0: link down
[ 16.714673] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 16.789766] iwl3945 0000:02:00.0: loaded firmware version 15.32.2.9
[ 16.856052] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 20.174342] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 20.174349] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 20.175265] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
[ 20.175270] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 20.175901] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 20.175906] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 20.176765] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
[ 20.176770] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 20.968029] wlan0: authenticate with 00:24:b2:a5:da:6c (try 1)
[ 20.969843] wlan0: authenticated
[ 20.970605] wlan0: associate with 00:24:b2:a5:da:6c (try 1)
[ 20.974523] wlan0: RX AssocResp from 00:24:b2:a5:da:6c (capab=0x411 status=0 aid=1)
[ 20.974531] wlan0: associated
[ 20.976170] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 27.378205] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 27.378209] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 27.379138] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
[ 27.379142] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 31.256691] wlan0: no IPv6 routers present
[ 46.863313] atkbd serio0: Unknown key pressed (translated set 2, code 0xf7 on isa0060/serio0).
[ 46.863317] atkbd serio0: Use 'setkeycodes e077 <keycode>' to make it known.
[ 46.864243] atkbd serio0: Unknown key released (translated set 2, code 0xf7 on isa0060/serio0).
[ 46.864247] atkbd serio0: Use 'setkeycodes e077 <keycode>' to make it known.
[ 46.873319] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 46.873323] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 46.874317] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
[ 46.874323] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 48.677562] atkbd serio0: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 48.677572] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
[ 48.678481] atkbd serio0: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
[ 48.678490] atkbd serio0: Use 'setkeycodes e078 <keycode>' to make it known.
^ permalink raw reply
* Re: problem executing command substitution from udev rules
From: J. Bakshi @ 2010-11-02 11:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020634.oA26Y57h004184@dcnode-01.unlimitedmail.net>
On Tue, 2 Nov 2010 12:51:16 +0300
Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 9:34 AM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> > it works well. But if I try to add command substitution ( with in back-qoutes ) to dynamically collect the user name , it stops working. The rule is like
> >
> > ```````````````
> > ACTION="add", SUBSYSTEM="input", ENV{ID_CLASS}="mouse", ENV{DISPLAY}=":0.0", ENV{XAUTHORITY}="/home/user1/.Xauthority" RUN+="/bin/su `ps aux | grep startx | grep '/bin/sh' | awk '{print $1}'` -c "DISPLAY=:0.0 notify-send "test" "
> > ``````````````````````````
> >
>
> I do not think udev is using shell to start external commands. You
> will need to use something like
>
> RUN+="/bin/sh -c '...'"
>
> Quoting will quickly become unmanageable I am afraid :)
Yes, I have tried with that but no success. I used
RUN+="/bin/sh -c '/bin/su user1 -c 'DISPLAY=:0.0 notify-send test''"
and no luck.
^ permalink raw reply
* Re: manually generate event, possible ?
From: J. Bakshi @ 2010-11-02 11:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020649.oA26n1vk004765@dcnode-02.unlimitedmail.net>
On Tue, 2 Nov 2010 13:51:25 +0300
Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 1:43 PM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> > On Tue, 2 Nov 2010 12:52:10 +0300
> > Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> >
> >> On Tue, Nov 2, 2010 at 9:49 AM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> >> > Hello list,
> >> >
> >> > To check the udev rules, say for a pendrive or mouse, we have to manually plug/unplug the devices every time, just after a modification in the rule sets. is there any way to generate the event for a *particular device* from command line ?
> >> >
> >>
> >> See "udevadm trigger".
> >>
> >
> > Thanks , but I have already tried with ( for usb mouse )
> >
> > ````````````
> > udevadm trigger --verbose  --sysname-match=/sys/class/input/input11  actiond
> > ``````````````
> >
> > but no luck :-(
> >
>
> This is event for input subsystem device input11, not for USB mouse.
> You probably want to use real device name (under /devices) for it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Ok, I am trying with a pendrive now. It is detected as below
``````````````````````
Nov 2 16:49:32 debian kernel: [69795.593055] sd 48:0:0:0: [sdc] Write Protect is off
Nov 2 16:49:32 debian kernel: [69795.596322] sdc: sdc1 sdc2
Nov 2 16:49:32 debian kernel: [69795.606536] sd 48:0:0:0: [sdc] Attached SCSI removable disk
```````````````````````````````````
The udev rules already has a notify-send which has shown on Desktop. Now I am trying to generate an event
`````````````````````````
udevadm trigger --verbose /dev/sdc
`````````````````````````
But no success... Any clue please ?
^ permalink raw reply
* Re: [RFD] Device Renaming Mechanism
From: Greg KH @ 2010-11-02 11:14 UTC (permalink / raw)
To: Jon Masters
Cc: Nao Nishijima, James.Bottomley, rwheeler, linux-kernel,
linux-hotplug-devel, linux-hotplug, masami.hiramatsu.pt, mdomsch
In-Reply-To: <1288681208.3916.170.camel@constitution.bos.jonmasters.org>
On Tue, Nov 02, 2010 at 03:00:08AM -0400, Jon Masters wrote:
> I have read the other mails, but I would love to know what Greg and Kay
> think about supporting automatic renaming in the case where the system
> *actually told you the preferred name* in such a table. Perhaps we can
> discuss this in Cambridge this week.
Perhaps you should look in the archives where I have stated my position
about this a number of times[1] :)
thanks,
greg k-h
[1] Do it in userspace
^ permalink raw reply
* Re: manually generate event, possible ?
From: J. Bakshi @ 2010-11-02 10:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020649.oA26n1vk004765@dcnode-02.unlimitedmail.net>
On Tue, 2 Nov 2010 12:52:10 +0300
Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 9:49 AM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> > Hello list,
> >
> > To check the udev rules, say for a pendrive or mouse, we have to manually plug/unplug the devices every time, just after a modification in the rule sets. is there any way to generate the event for a *particular device* from command line ?
> >
>
> See "udevadm trigger".
>
Thanks , but I have already tried with ( for usb mouse )
````````````
udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
``````````````
but no luck :-(
^ permalink raw reply
* Re: manually generate event, possible ?
From: Andrey Borzenkov @ 2010-11-02 10:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020649.oA26n1vk004765@dcnode-02.unlimitedmail.net>
On Tue, Nov 2, 2010 at 1:43 PM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> On Tue, 2 Nov 2010 12:52:10 +0300
> Andrey Borzenkov <arvidjaar@gmail.com> wrote:
>
>> On Tue, Nov 2, 2010 at 9:49 AM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
>> > Hello list,
>> >
>> > To check the udev rules, say for a pendrive or mouse, we have to manually plug/unplug the devices every time, just after a modification in the rule sets. is there any way to generate the event for a *particular device* from command line ?
>> >
>>
>> See "udevadm trigger".
>>
>
> Thanks , but I have already tried with ( for usb mouse )
>
> ````````````
> udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
> ``````````````
>
> but no luck :-(
>
This is event for input subsystem device input11, not for USB mouse.
You probably want to use real device name (under /devices) for it.
^ permalink raw reply
* Re: manually generate event, possible ?
From: Andrey Borzenkov @ 2010-11-02 9:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020649.oA26n1vk004765@dcnode-02.unlimitedmail.net>
On Tue, Nov 2, 2010 at 9:49 AM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> Hello list,
>
> To check the udev rules, say for a pendrive or mouse, we have to manually plug/unplug the devices every time, just after a modification in the rule sets. is there any way to generate the event for a *particular device* from command line ?
>
See "udevadm trigger".
^ permalink raw reply
* Re: problem executing command substitution from udev rules
From: Andrey Borzenkov @ 2010-11-02 9:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201011020634.oA26Y57h004184@dcnode-01.unlimitedmail.net>
On Tue, Nov 2, 2010 at 9:34 AM, J. Bakshi <j.bakshi@unlimitedmail.org> wrote:
> it works well. But if I try to add command substitution ( with in back-qoutes ) to dynamically collect the user name , it stops working. The rule is like
>
> ```````````````
> ACTION="add", SUBSYSTEM="input", ENV{ID_CLASS}="mouse", ENV{DISPLAY}=":0.0", ENV{XAUTHORITY}="/home/user1/.Xauthority" RUN+="/bin/su `ps aux | grep startx | grep '/bin/sh' | awk '{print $1}'` -c "DISPLAY=:0.0 notify-send "test" "
> ``````````````````````````
>
I do not think udev is using shell to start external commands. You
will need to use something like
RUN+="/bin/sh -c '...'"
Quoting will quickly become unmanageable I am afraid :)
^ permalink raw reply
* manually generate event, possible ?
From: J. Bakshi @ 2010-11-02 7:01 UTC (permalink / raw)
To: linux-hotplug
Hello list,
To check the udev rules, say for a pendrive or mouse, we have to manually plug/unplug the devices every time, just after a modification in the rule sets. is there any way to generate the event for a *particular device* from command line ?
Thanks and regards
^ permalink raw reply
* Re: [RFD] Device Renaming Mechanism
From: Jon Masters @ 2010-11-02 7:00 UTC (permalink / raw)
To: Nao Nishijima
Cc: gregkh, James.Bottomley, rwheeler, linux-kernel,
linux-hotplug-devel, linux-hotplug, masami.hiramatsu.pt, mdomsch
In-Reply-To: <4CAEAAD4.2080504@hitachi.com>
On Fri, 2010-10-08 at 14:23 +0900, Nao Nishijima wrote:
> I'm trying to solve a device name(or device node) mismatch problem caused by
> device configuration changes. Now I have an idea of device renaming to solve it,
> and would like to request for comments from kernel developers.
I apologize that I missed this mail until I was doing some podcasts ;)
Although not necessarily useful for within-device volumes, I would
nonetheless like to call attention to the DMTF SMBIOS specification, and
in particular structure Type 9, which allows system vendors to provide
various information about the correct mappings of physical system slots
to devices. Matt Domsch produced a utility a while back called
biosdevname that can be used to implement one possible device renaming
mechanism for network interfaces, based on the system slot identifier,
but of course there is no reason not to support the other devices.
I have read the other mails, but I would love to know what Greg and Kay
think about supporting automatic renaming in the case where the system
*actually told you the preferred name* in such a table. Perhaps we can
discuss this in Cambridge this week.
Jon.
^ permalink raw reply
* problem executing command substitution from udev rules
From: J. Bakshi @ 2010-11-02 6:46 UTC (permalink / raw)
To: linux-hotplug
Hello llist,
I am using notify-send in my udev rules to send desktop notification. Here is the actual command which is working fine for me, even from the root shell.
````````````
/bin/su `ps aux | grep startx | grep '/bin/sh' | awk '{print $1}'` -c "DISPLAY=:0.0 notify-send "test"
`````````````
the part [ ps aux | grep startx | grep '/bin/sh' | awk '{print $1}' ] is for collecting the user-name who is running startx.
now in my udev rule if I hard-coded the user name like
```````````````
ACTION="add", SUBSYSTEM="input", ENV{ID_CLASS}="mouse", ENV{DISPLAY}=":0.0", ENV{XAUTHORITY}="/home/user1/.Xauthority" RUN+="/bin/su user1 -c "DISPLAY=:0.0 notify-send "test" "
``````````````````````````
it works well. But if I try to add command substitution ( with in back-qoutes ) to dynamically collect the user name , it stops working. The rule is like
```````````````
ACTION="add", SUBSYSTEM="input", ENV{ID_CLASS}="mouse", ENV{DISPLAY}=":0.0", ENV{XAUTHORITY}="/home/user1/.Xauthority" RUN+="/bin/su `ps aux | grep startx | grep '/bin/sh' | awk '{print $1}'` -c "DISPLAY=:0.0 notify-send "test" "
``````````````````````````
Definitely I have user1 who is using startx here. Surely the command substitution with in udev rules is not working at all. Can't understand why it fails. I would be grateful if any one point out what is missing/wrong here.
Thanks
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Greg KH @ 2010-11-01 20:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
On Mon, Nov 01, 2010 at 07:57:23PM +0100, Hr. Philip Rueegsegger wrote:
> >Anyway, it's probably easier to leave it as a module. There are
> >thousand ways to get code into the running kernel with the right
> >permissions, disabling the module loader does not really add security.
> >
> >Kay
>
> Is it really possible to get code into the running kernel with module loader
> turned off and no /dev/kmem support?
Yes it is.
For examples of how to do this, use google.
And it's way off-topic here so please don't discuss it here.
good luck,
greg k-h
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Hr. Philip Rueegsegger @ 2010-11-01 18:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
>Anyway, it's probably easier to leave it as a module. There are
>thousand ways to get code into the running kernel with the right
>permissions, disabling the module loader does not really add security.
>
>Kay
Is it really possible to get code into the running kernel with module loader
turned off and no /dev/kmem support? If so, what can be done to prevent this?
Cheers,
Philip
^ permalink raw reply
* Fix touchpad toggle on HP laptops breaking the keyboard
From: Bastien Nocera @ 2010-11-01 17:44 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
As seen in:
https://bugzilla.redhat.com/show_bug.cgi?id=623239
Tested by mjg59
Note that a lot more work is needed to make this "sane". We have 3
different "function keys" being mapped to various touchpad toggle
buttons (F21, F22 and F23).
[-- Attachment #2: 0001-keymap-Add-force-release-for-HP-touchpad-off.patch --]
[-- Type: text/x-patch, Size: 1934 bytes --]
From cb6f46d8b97e9c026cb244abc7a11a00e45ec368 Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Mon, 1 Nov 2010 16:29:09 +0000
Subject: [PATCH] keymap: Add force release for HP touchpad off
Force the touchpad off/on keys getting released, as they usually
only send a "repeat".
https://bugzilla.redhat.com/show_bug.cgi?id=623239
---
| 5 +++++
| 3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
create mode 100644 extras/keymap/force-release-maps/hp-other
--git a/extras/keymap/95-keyboard-force-release.rules b/extras/keymap/95-keyboard-force-release.rules
index 562dc8d..6f7c0fd 100644
--- a/extras/keymap/95-keyboard-force-release.rules
+++ b/extras/keymap/95-keyboard-force-release.rules
@@ -35,4 +35,9 @@ ENV{DMI_VENDOR}=="TOSHIBA", ATTR{[dmi/id]product_name}=="Satellite U300|Satellit
ENV{DMI_VENDOR}=="Viooo Corporation", ATTR{[dmi/id]product_name}=="PT17", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+# These are all the HP laptops that setup a touchpad toggle key
+ENV{DMI_VENDOR}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*[pP][aA][vV][iI][lL][iI][oO][nN]*", RUN+="keyboard-force-release.sh $devpath hp-other"
+ENV{DMI_VENDOR}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*[tT][xX]2*", RUN+="keyboard-force-release.sh $devpath hp-other"
+ENV{DMI_VENDOR}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*2510p*|*2530p*|HP G60 Notebook PC", RUN+="keyboard-force-release.sh $devpath hp-other"
+
LABEL="force_release_end"
--git a/extras/keymap/force-release-maps/hp-other b/extras/keymap/force-release-maps/hp-other
new file mode 100644
index 0000000..6621370
--- /dev/null
+++ b/extras/keymap/force-release-maps/hp-other
@@ -0,0 +1,3 @@
+# list of scancodes (hex or decimal), optional comment
+0xd8 # Touchpad off
+0xd9 # Touchpad on
--
1.7.3.1
^ permalink raw reply related
* Re: USB suspend and Logitech Iilluminated Keyboard
From: Kay Sievers @ 2010-11-01 16:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101031183827.31d721ef.mail@roland-ramthun.de>
On Mon, Nov 1, 2010 at 17:38, Roland Ramthun <mail@roland-ramthun.de> wrote:
> On Mon, 1 Nov 2010 16:33:38 +0100
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> > I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
>> >
>> > Is there another way to circumvent this problem?
>>
>> I think usb-auto-suspend is usually off by default and needs to be
>> enabled per device. The idea is/was to have whitelist of devices and
>> enable devices which are known to be safe. But as far as I know, no
>> such list exists or is in common use.
>
> You mean the device driver needs to enable it?
> The Logitech is a standard USB keyboard.
>
> [3.052761] generic-usb 0003:046D:C318.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input0
> [3.279286] generic-usb 0003:046D:C318.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input1
>
> I think this suggests it uses "normal" USB HID drivers.
>
> Reading the USB power management documentation it turns out, such problems are known.
>
> Documentation/usb/power-management.txt
> ==
> Sometimes it turns out that even when a device does work okay with
> autosuspend there are still problems. For example, there are
> experimental patches adding autosuspend support to the usbhid driver,
> which manages keyboards and mice, among other things. Tests with a
> number of keyboards showed that typing on a suspended keyboard, while
> causing the keyboard to do a remote wakeup all right, would
> nonetheless frequently result in lost keystrokes.
> ==
>
> I'm sure I have no "experimental patches" applied, I use a vanilla 2.6.34 kernel.
>
>> > If not, please consider to include this rule into the official udev release.
>>
>> Besides a few (pretty broken) exceptions the udev sources do not carry
>> quirks for individual devices, only generic subsystem specific things.
>
> I see how that's reasonable, as this list would need constant care and could become large.
> E.g. in the meantime I discovered the same problems exist with a Logitech G15, too.
>
>> We can't add this at the moment, there is at the moment no
>> infrastructure to keep lists like this maintained.
>
> Obviously we shouldn't add these exceptions to udev.
> But what is the right place?
There is none at the moment. It would probably need to be some generic
device database, that this info can be extracted from and put into
some new tool.
> Judging from the above documentation snippet, there might be something wrong with the fact USB suspend is active on a keyboard at all.
As far as I understand it, usb autosuspend should only be enabled
per-device from userspace and by default be off for most device types.
Kay
^ permalink raw reply
* Re: USB suspend and Logitech Iilluminated Keyboard
From: Roland Ramthun @ 2010-11-01 16:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101031183827.31d721ef.mail@roland-ramthun.de>
On Mon, 1 Nov 2010 16:33:38 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:
> > I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
> >
> > Is there another way to circumvent this problem?
>
> I think usb-auto-suspend is usually off by default and needs to be
> enabled per device. The idea is/was to have whitelist of devices and
> enable devices which are known to be safe. But as far as I know, no
> such list exists or is in common use.
You mean the device driver needs to enable it?
The Logitech is a standard USB keyboard.
[3.052761] generic-usb 0003:046D:C318.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input0
[3.279286] generic-usb 0003:046D:C318.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [Logitech Logitech Illuminated Keyboard] on usb-0000:00:1d.0-1.1/input1
I think this suggests it uses "normal" USB HID drivers.
Reading the USB power management documentation it turns out, such problems are known.
Documentation/usb/power-management.txt
==
Sometimes it turns out that even when a device does work okay with
autosuspend there are still problems. For example, there are
experimental patches adding autosuspend support to the usbhid driver,
which manages keyboards and mice, among other things. Tests with a
number of keyboards showed that typing on a suspended keyboard, while
causing the keyboard to do a remote wakeup all right, would
nonetheless frequently result in lost keystrokes.
==
I'm sure I have no "experimental patches" applied, I use a vanilla 2.6.34 kernel.
> > If not, please consider to include this rule into the official udev release.
>
> Besides a few (pretty broken) exceptions the udev sources do not carry
> quirks for individual devices, only generic subsystem specific things.
I see how that's reasonable, as this list would need constant care and could become large.
E.g. in the meantime I discovered the same problems exist with a Logitech G15, too.
> We can't add this at the moment, there is at the moment no
> infrastructure to keep lists like this maintained.
Obviously we shouldn't add these exceptions to udev.
But what is the right place?
Judging from the above documentation snippet, there might be something wrong with the fact USB suspend is active on a keyboard at all.
Kind regards,
Roland
^ permalink raw reply
* Re: USB suspend and Logitech Iilluminated Keyboard
From: Kay Sievers @ 2010-11-01 15:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101031183827.31d721ef.mail@roland-ramthun.de>
On Sun, Oct 31, 2010 at 18:38, Roland Ramthun <mail@roland-ramthun.de> wrote:
> I recently bought a Logitech Illuminated Keyboard, which has, as the name suggests, a background illumination.
>
> After activating USB suspend (USB_SUSPEND) in the kernel, the keyboard is rendered unusable:
> *) It starts to flash (suspend -> immediate wakeup, even without a key pressed -> suspend -> ...)
> *) While starting up the illumination after every suspend, key presses are not recognized for fractions of a second
>
> I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
>
> Is there another way to circumvent this problem?
I think usb-auto-suspend is usually off by default and needs to be
enabled per device. The idea is/was to have whitelist of devices and
enable devices which are known to be safe. But as far as I know, no
such list exists or is in common use.
> If not, please consider to include this rule into the official udev release.
Besides a few (pretty broken) exceptions the udev sources do not carry
quirks for individual devices, only generic subsystem specific things.
We can't add this at the moment, there is at the moment no
infrastructure to keep lists like this maintained.
Kay
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Greg KH @ 2010-10-31 20:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
On Sun, Oct 31, 2010 at 09:09:03AM -0700, Laszlo Papp wrote:
> Hi,
>
> My further question is that whether libudev can help me to handle
> input events, like keyboard, mouse, touch presses ?
No, that is what x.org is for.
> What is the best to do that in a userspace input system where I would
> like to avoid the 'root' usage, 'root' privileges so that simple users
> can use it.
See the x.org input subsystem code for examples of how to do this.
good luck,
greg k-h
^ permalink raw reply
* USB suspend and Logitech Iilluminated Keyboard
From: Roland Ramthun @ 2010-10-31 17:38 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
Hello list,
I recently bought a Logitech Illuminated Keyboard, which has, as the name suggests, a background illumination.
After activating USB suspend (USB_SUSPEND) in the kernel, the keyboard is rendered unusable:
*) It starts to flash (suspend -> immediate wakeup, even without a key pressed -> suspend -> ...)
*) While starting up the illumination after every suspend, key presses are not recognized for fractions of a second
I wrote an udev rule to disable USB suspend for this specific model, which solves the described problems. You'll find it attached.
Is there another way to circumvent this problem?
If not, please consider to include this rule into the official udev release.
Kind regards,
Roland
[-- Attachment #2: 99-logitech-illuminated-keyboard.rules --]
[-- Type: application/octet-stream, Size: 242 bytes --]
#Disable USB power suspend on Logitech Illuminated Keyboard, which leads to flashing background illumination and short episodes of non responsiveness
SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c318", ATTR{power/control}="on"
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Laszlo Papp @ 2010-10-31 16:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
Hi,
My further question is that whether libudev can help me to handle
input events, like keyboard, mouse, touch presses ? What is the best
to do that in a userspace input system where I would like to avoid the
'root' usage, 'root' privileges so that simple users can use it.
Best Regards,
Laszlo Papp
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Laszlo Papp @ 2010-10-31 14:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
On Sun, Oct 31, 2010 at 7:39 AM, Laszlo Papp <djszapi@archlinux.us> wrote:
> On Sun, Oct 31, 2010 at 7:23 AM, Greg KH <greg@kroah.com> wrote:
>> On Sun, Oct 31, 2010 at 07:04:30AM -0700, Laszlo Papp wrote:
>>> Hi,
>>>
>>> You can check the code out more in-depth in the following with the
>>> produced output. This is the compilation command I used for testing:
>>> gcc -Wall -o test -ggdb -ludev main.c.
>>>
>>> I just would like to get the real input devices.. so VID/PID: (null)
>>> (null) and related device node entries are undesired.
>>
>> But those are "real" input devices, why do you think otherwise?
>>
>> If you don't want them, then filter them out by ignoring the event
>> types, but note that they are needed by your system to work properly
>> (i.e. x.org uses them.)
>>
>> So your code is working as designed, I just don't think that you
>> realized there are all of these input devices present :)
>>
>> thanks,
>>
>> greg k-h
>>
>
> root /home/djszapi # cat main.c
> #include <libudev.h>
> #include <stdio.h>
>
> int main()
> {
> struct udev *udev;
> struct udev_enumerate *enumerate;
> struct udev_list_entry *devices;
> struct udev_list_entry *dev_list_entry;
> struct udev_device *dev;
>
> udev = udev_new();
> if (!udev) {
> printf("Cannot create udev\n");
> return -1;
> }
>
> enumerate = udev_enumerate_new(udev);
> udev_enumerate_add_match_subsystem(enumerate, "input");
> udev_enumerate_scan_devices(enumerate);
> devices = udev_enumerate_get_list_entry(enumerate);
>
> udev_list_entry_foreach(dev_list_entry, devices) {
> const char *path;
> path = udev_list_entry_get_name(dev_list_entry);
> dev = udev_device_new_from_syspath(udev, path);
> dev = udev_device_get_parent_with_subsystem_devtype(dev, "input", 0);
> if (dev = 0)
> continue;
>
> printf("Device Node Path: %s, Name: %s\r\n", path,
> udev_device_get_sysattr_value(dev, "name"));
> printf("VID/PID: %s %s\r\n",
> udev_device_get_sysattr_value(dev,"id/vendor"),
> udev_device_get_sysattr_value(dev, "id/product"));
> udev_device_unref(dev);
> }
>
> udev_enumerate_unref(enumerate);
> udev_unref(udev);
>
> return 0;
> }
> root /home/djszapi # ./test
> Device Node Path:
> /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3, Name: Power
> Button
> VID/PID: 0000 0001
> Device Node Path:
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2/event2,
> Name: Power Button
> VID/PID: 0000 0001
> Device Node Path:
> /sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5/event5,
> Name: Logitech USB Optical Mouse
> VID/PID: 046d c00c
> Device Node Path:
> /sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5/mouse1,
> Name: Logitech USB Optical Mouse
> VID/PID: 046d c00c
> Device Node Path:
> /sys/devices/pci0000:00/0000:00:09.0/input/input6/event6, Name: HDA
> Digital PCBeep
> VID/PID: 10ec 0662
> Device Node Path:
> /sys/devices/platform/i8042/serio0/input/input1/event1, Name: AT
> Translated Set 2 keyboard
> VID/PID: 0001 0001
> Device Node Path: /sys/devices/platform/pcspkr/input/input4/event4,
> Name: PC Speaker
> VID/PID: 001f 0001
> Device Node Path: /sys/devices/virtual/input/input0/event0, Name:
> Macintosh mouse button emulation
> VID/PID: 0001 0001
> Device Node Path: /sys/devices/virtual/input/input0/mouse0, Name:
> Macintosh mouse button emulation
> VID/PID: 0001 0001
> root /home/djszapi #
>
> Better, but every device occurs two times o_O
>
> Best Regards,
> Laszlo Papp
>
root /sys/devices/platform/i8042/serio0/input/input1 # cd /home/djszapi/
root /home/djszapi # cat main.c
#include <libudev.h>
#include <stdio.h>
int main()
{
struct udev *udev;
struct udev_enumerate *enumerate;
struct udev_list_entry *devices;
struct udev_list_entry *dev_list_entry;
struct udev_device *dev;
struct udev_device *parent_dev;
udev = udev_new();
if (!udev) {
printf("Cannot create udev\n");
return -1;
}
enumerate = udev_enumerate_new(udev);
udev_enumerate_add_match_subsystem(enumerate, "input");
udev_enumerate_scan_devices(enumerate);
devices = udev_enumerate_get_list_entry(enumerate);
udev_list_entry_foreach(dev_list_entry, devices) {
const char *path;
path = udev_list_entry_get_name(dev_list_entry);
dev = udev_device_new_from_syspath(udev, path);
parent_dev udev_device_get_parent_with_subsystem_devtype(dev, "input", 0);
if (parent_dev) {
udev_device_unref(parent_dev);
continue;
}
printf("Device Node Path: %s, Name: %s\r\n", path,
udev_device_get_sysattr_value(dev, "name"));
printf("VID/PID: %s %s\r\n",
udev_device_get_sysattr_value(dev,"id/vendor"),
udev_device_get_sysattr_value(dev, "id/product"));
udev_device_unref(dev);
}
udev_enumerate_unref(enumerate);
udev_unref(udev);
return 0;
}
root /home/djszapi # gcc -Wall -o test -ggdb -ludev main.c
root /home/djszapi # ./test
Device Node Path: /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3,
Name: Power Button
VID/PID: 0000 0001
Device Node Path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2, Name:
Power Button
VID/PID: 0000 0001
Device Node Path:
/sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5,
Name: Logitech USB Optical Mouse
VID/PID: 046d c00c
Device Node Path: /sys/devices/pci0000:00/0000:00:09.0/input/input6,
Name: HDA Digital PCBeep
VID/PID: 10ec 0662
Device Node Path: /sys/devices/platform/i8042/serio0/input/input1,
Name: AT Translated Set 2 keyboard
VID/PID: 0001 0001
Device Node Path: /sys/devices/platform/pcspkr/input/input4, Name: PC Speaker
VID/PID: 001f 0001
Device Node Path: /sys/devices/virtual/input/input0, Name: Macintosh
mouse button emulation
VID/PID: 0001 0001
Device Node Path: /sys/devices/virtual/input/mice, Name: (null)
VID/PID: (null) (null)
root /home/djszapi #
OK, seems to work, but please fix me, if this is not the way to do it.
Best Regards,
Laszlo Papp
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Laszlo Papp @ 2010-10-31 14:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
On Sun, Oct 31, 2010 at 7:23 AM, Greg KH <greg@kroah.com> wrote:
> On Sun, Oct 31, 2010 at 07:04:30AM -0700, Laszlo Papp wrote:
>> Hi,
>>
>> You can check the code out more in-depth in the following with the
>> produced output. This is the compilation command I used for testing:
>> gcc -Wall -o test -ggdb -ludev main.c.
>>
>> I just would like to get the real input devices.. so VID/PID: (null)
>> (null) and related device node entries are undesired.
>
> But those are "real" input devices, why do you think otherwise?
>
> If you don't want them, then filter them out by ignoring the event
> types, but note that they are needed by your system to work properly
> (i.e. x.org uses them.)
>
> So your code is working as designed, I just don't think that you
> realized there are all of these input devices present :)
>
> thanks,
>
> greg k-h
>
root /home/djszapi # cat main.c
#include <libudev.h>
#include <stdio.h>
int main()
{
struct udev *udev;
struct udev_enumerate *enumerate;
struct udev_list_entry *devices;
struct udev_list_entry *dev_list_entry;
struct udev_device *dev;
udev = udev_new();
if (!udev) {
printf("Cannot create udev\n");
return -1;
}
enumerate = udev_enumerate_new(udev);
udev_enumerate_add_match_subsystem(enumerate, "input");
udev_enumerate_scan_devices(enumerate);
devices = udev_enumerate_get_list_entry(enumerate);
udev_list_entry_foreach(dev_list_entry, devices) {
const char *path;
path = udev_list_entry_get_name(dev_list_entry);
dev = udev_device_new_from_syspath(udev, path);
dev = udev_device_get_parent_with_subsystem_devtype(dev, "input", 0);
if (dev = 0)
continue;
printf("Device Node Path: %s, Name: %s\r\n", path,
udev_device_get_sysattr_value(dev, "name"));
printf("VID/PID: %s %s\r\n",
udev_device_get_sysattr_value(dev,"id/vendor"),
udev_device_get_sysattr_value(dev, "id/product"));
udev_device_unref(dev);
}
udev_enumerate_unref(enumerate);
udev_unref(udev);
return 0;
}
root /home/djszapi # ./test
Device Node Path:
/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3, Name: Power
Button
VID/PID: 0000 0001
Device Node Path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2/event2,
Name: Power Button
VID/PID: 0000 0001
Device Node Path:
/sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5/event5,
Name: Logitech USB Optical Mouse
VID/PID: 046d c00c
Device Node Path:
/sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5/mouse1,
Name: Logitech USB Optical Mouse
VID/PID: 046d c00c
Device Node Path:
/sys/devices/pci0000:00/0000:00:09.0/input/input6/event6, Name: HDA
Digital PCBeep
VID/PID: 10ec 0662
Device Node Path:
/sys/devices/platform/i8042/serio0/input/input1/event1, Name: AT
Translated Set 2 keyboard
VID/PID: 0001 0001
Device Node Path: /sys/devices/platform/pcspkr/input/input4/event4,
Name: PC Speaker
VID/PID: 001f 0001
Device Node Path: /sys/devices/virtual/input/input0/event0, Name:
Macintosh mouse button emulation
VID/PID: 0001 0001
Device Node Path: /sys/devices/virtual/input/input0/mouse0, Name:
Macintosh mouse button emulation
VID/PID: 0001 0001
root /home/djszapi #
Better, but every device occurs two times o_O
Best Regards,
Laszlo Papp
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Greg KH @ 2010-10-31 14:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
On Sun, Oct 31, 2010 at 07:04:30AM -0700, Laszlo Papp wrote:
> Hi,
>
> You can check the code out more in-depth in the following with the
> produced output. This is the compilation command I used for testing:
> gcc -Wall -o test -ggdb -ludev main.c.
>
> I just would like to get the real input devices.. so VID/PID: (null)
> (null) and related device node entries are undesired.
But those are "real" input devices, why do you think otherwise?
If you don't want them, then filter them out by ignoring the event
types, but note that they are needed by your system to work properly
(i.e. x.org uses them.)
So your code is working as designed, I just don't think that you
realized there are all of these input devices present :)
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox