Attached is a (mostly) rewrite of the evdev driver, done after some talking with ajax. This should close bugs #5658, #5625, #5617, #5256, #3912. And partially fix #5578. The keyboard side is not tested much at the moment, and there are some obvious things to work on for it, however it drasticly improves device matching, handles hotplug devices, handles multiple devices for the same device entry, and should be much cleaner to extend to handle other types of input devices. Comments are welcome, as are bug reports. Feature addition requests are also welcome, though my ability to write code for hardware that I don't _have_ is limited. There's probably more, but..
Created attachment 4444 [details] [review] evdev rewrite patch (take 1)
Created attachment 4446 [details] [review] xkb data files for evdev driver. Shamelessly stolen from #3912, the evdev drive supports xkb just fine, but it does need the data files, and the submitter of #3912 did the hard work of writing those.
Created attachment 4447 [details] [review] Updated driver. This is an update, with a few bugs polished off and with a slight redesign for the rel driver. ZAxisMapping no longer exists as an option, and I'm not _entirely_ happy with the replacement of Axis<n>Buttons and Axis<n>Map, the <n> is always two digits, and it is the axis number, 0 for x, 1 for y, 2 for z, 6 for hwheel, 8 for wheel. Ideally we should support a named interface for those, but I'm horrible with names. This allows completely arbitrary remapping of axies to other axies and to buttons. (An appearently often requested feature of evdev.)
Created attachment 4448 [details] [review] Minor update. Whoops, accidently got the button order on axis remaps, fixed. No other changes to previous.
Created attachment 4481 [details] [review] Rewrite patch. This is another update of the code, updating the manpage, changing some of the options, and updating the manpage to be vaguely current. Though there is still improvement, at this point I'd say that it is in better shape then the driver currently in tree, and so it should probably be considered for inclusion. Thank you.
Does specifying Dev Phys and Dev Name in xorg.conf now work in a way that Device doesn't need to be specified anymore? This would be very good for multiseat setups.
As it's a separate driver now, it's Name and Phys, not Dev Name and Dev Phys, but yeah, otherwise the device specification is the same as in my old code that was in Debian and Gentoo.
Created attachment 4483 [details] [review] evdev rewrite patch Minor bug fix to the patch. And, er, the xkb data file patch is still needed, not sure how that got marked obsolete.
Can it still specify devices via /dev/input/event-* entries? I have devices that are named identically (it's actually a single keyboard with mouse features that shows up as different devices), and I've written up udev rules to split it out.
Yes it can, the Device option still exists and still works, though it now has globbing support like the rest of the device specification options.
You woldn't consider porting this patch to modular xorg?
(In reply to comment #11) > You woldn't consider porting this patch to modular xorg? Ought to be trivial, since the original source code is the same -- just go to the src dir of the evdev driver and apply it; if there are any new source files, stick 'em in Makefile.am.
On my laptop, unplugging the mouse (Logitech MX510) and inserting it again makes it get a new incrememented /dev/input/eventX number, thus evdev fails to link against it again. Making a restart of X and fiddling with the xorg.conf necessary to be able to use the mouse again. Is this possible to solve with evdev or is it more of an udev issue? This is in any case something that needs to be addressed.
Created attachment 4524 [details] [review] evdev rewrite patch Minor bug fix, there was a maybe crash bug in the case of devices that generate SYN events but have no rel axes, now fixed.
(In reply to comment #13) > On my laptop, unplugging the mouse (Logitech MX510) and inserting it again makes > it get a new incrememented /dev/input/eventX number, thus evdev fails to link > against it again. Making a restart of X and fiddling with the xorg.conf > necessary to be able to use the mouse again. Is this possible to solve with > evdev or is it more of an udev issue? > > This is in any case something that needs to be addressed. This patch solves the problem, don't use the Device specification, instead use Name or Phys (or both) to indicate what device you want, hotplug then works. If more then one device that matches the supplied Name and/or Phys, or additional matching devices are plugged in later, they are _all_ properly supported. (Yes, this gives a basic form of input hotplug support that previously did not exist in X.)
(In reply to comment #9) > Can it still specify devices via /dev/input/event-* entries? I have devices that > are named identically (it's actually a single keyboard with mouse features that > shows up as different devices), and I've written up udev rules to split it out. Actually, scratch my previous reply. I had forgotten that in some of the redesign I had partly lost that feature. Specificly, you can specify by Device, Name, or Phys, or any mixture of the above, however we only check that against the /dev/input/event<n> devices, with n being from 0 to 31. It might be possible to change the code to handle the corner case of non-globbed Device entries that do not match that pattern, but it would be a fair bit of work given that we should be able to handle even the strange cases with the mixture of phys and name. If you need that support I'll find a way to add it, but I'd very much like to see the udev rule and the output of 'cat /proc/bus/input/devices'. Thanks.
The two relevant devices, one for the "keyboard" component, one for the "mouse" component. Note that the Phys property is unstable, that is, the precise definition will vary depending on which port on which root/hub device the keyboard is plugged into: > I: Bus=0003 Vendor=046d Product=c30a Version=1500 > N: Name="Logitech Logitech USB Keyboard" > P: Phys=usb-0000:00:07.2-1/input0 > S: Sysfs=/class/input/input1 > H: Handlers=kbd event1 > B: EV=120003 > B: KEY=10000 7 ff800000 7ff febeffdf ffefffff ffffffff fffffffe > B: LED=1f > > I: Bus=0003 Vendor=046d Product=c30a Version=1500 > N: Name="Logitech Logitech USB Keyboard" > P: Phys=usb-0000:00:07.2-1/input1 > S: Sysfs=/class/input/input2 > H: Handlers=kbd mouse0 event2 > B: EV=7 > B: KEY=ffffffff ffffffff f80 40000 601878 d801d108 1e0000 0 0 0 > B: REL=103 Even udev has a hard time dealing with these seperately, as the only sysfs info that differentiates them is the bInterfaceNumber value, which is in a seperate sysfs file than the product/vendor information. Atm I'm using a relatively awkward udev rule/script combination to work around udev rules' inability to match on more than one sysfs section: ./022_logitech.rules:KERNEL="event*", PROGRAM="/etc/udev/scripts/my_events.sh event %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}" ./022_logitech.rules:KERNEL="mouse*", PROGRAM="/etc/udev/scripts/my_events.sh mouse %k", SYMLINK+="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}" coupled with: http://bg.rifetech.com/my_events.sh.txt (The relavent udevinfo output is at http://bg.rifetech.com/event-mouse and http://bg.rifetech.com/event-kbd ) Ugly, I know, but if someone has a better suggestion as to how to tell the two devices apart in an evdev context, I'm all ears.
(In reply to comment #17) > The two relevant devices, one for the "keyboard" component, one for the "mouse" > component. Note that the Phys property is unstable, that is, the precise > definition will vary depending on which port on which root/hub device the > keyboard is plugged into: Correction, _some_ of it is unstable, that's why there is globbing support. Your keyboard side is: > > P: Phys=usb-0000:00:07.2-1/input0 So: Option "phys" "*/input0" And your mouse is: > > P: Phys=usb-0000:00:07.2-1/input1 So: Option "phys" "*/input1" For both you'll want to give a name of 'Logitech Logitech USB Keyboard'. So you're looking at something like: Option "Name" "Logitech Logitech USB Keyboard" Option "Phys" "*/input0" For the keyboard, and input1 for the mouse. Let me know if that doesn't work? Thanks.
How would this patchset interact together with bug #971? https://bugs.freedesktop.org/show_bug.cgi?id=971 Would it ease up the struggling with udev?
Thx for THE GREAT WORK!!! this issue should also replase #320 #5559 #968?
(In reply to comment #20) > Thx for THE GREAT WORK!!! this issue should also replase #320 #5559 #968? Though it is not heavily tested (please feel free to test the keyboard side), this should fix 320 and 5559. And this is basicly a replacement for 968, but as 968 is in the CVS tree already this is on top of it.
(In reply to comment #19) > How would this patchset interact together with bug #971? > https://bugs.freedesktop.org/show_bug.cgi?id=971 Poorly, if 971 is looking like it's going to be appplied to the X.org tree I'll need to make some noticable changes to avoid serious issues when attempting to remove evdev devices. The current design is roughly as follows: The preinit is called, asking us to create a device entry with the configuration options passed along; this is not actually done. Instead the preinit parses the options and tells the evdev brain (which polls USB[0] events for added/removed devices) to start watching for devices which match the given specifications, and to use the given options for any found. Purely as a conveience to allow evdev to be used as a core pointer/keyboard does the preinit return something other then NULL. Specificly, during the preinit we tell the brain to scan for devices that match, and if any are found the first one in the list is returned. When a device is found, either at preinit time or at run time, a new input device is created with the options given to the preinit that specified that we should be looking for that device. (With the Name, Phys, and Device entries.) When a device is unplugged we just call the Proc for the associated input device with DEVICE_OFF and arrange for it to respond negitively on further DEVICE_OPEN calls, saving it (and any user changes to it) for the case of it being plugged back in. Making it vanish entirely is an option as well, however it would cause problems in some cases, for example if the core keyboard is plugged into a USB hub that's not on the UPS with the computer, and the power fails briefly. What this boils down to is that removing just one matching device is _quite_ impratical due to the hotplug code, and that there might not be a device at all for something that the brain is watching for, yet has no devices for at the time. Creating a dummy device by the actual name for the purpose of easy removal might be an option, but interaction with an automated 'oh, new input device, add an X input device' script should be watched carefully. > > Would it ease up the struggling with udev? Could you be more specific on the issue in question with udev? I'm not seeing comments about it on #971. 0: Yes, we watch /proc/bus/usb/devices instead of /proc/bus/input/devices, the reason is quite simple really, you _can_ reasonably have X do a select on the former, you can't on the latter, it's a kernel issue that even if fixed could not be relied on due to people running older kernels. Using HAL instead of the poll would be nice, but I didn't think that it would be appreciated to link against it in a X driver. Zephaniah E. Hull
> So you're looking at something like: > > Option "Name" "Logitech Logitech USB Keyboard" > Option "Phys" "*/input0" Interesting. I don't recall conjective specifiers working the last time i tried it. I'll give this a shot once I get the new driver installed. Still, it seems odd that the Device specifier would only work with #'d nodes. The #'d nodes are almost completely unreliable. If you're going to have support for a "Device" entry, it really should support arbitrary node specifiers, otherwise this'll become a nasty FAQ pretty quick. BTW: What happens if I have two similar devices on the system? The "Name" for my device is pretty vague, and if I was trying to use hardware like this on a multi-user box it would seem to present serious headaches.
(In reply to comment #23) > > So you're looking at something like: > > > > Option "Name" "Logitech Logitech USB Keyboard" > > Option "Phys" "*/input0" > > Interesting. I don't recall conjective specifiers working the last time i tried > it. I'll give this a shot once I get the new driver installed. > > Still, it seems odd that the Device specifier would only work with #'d nodes. > The #'d nodes are almost completely unreliable. If you're going to have support > for a "Device" entry, it really should support arbitrary node specifiers, > otherwise this'll become a nasty FAQ pretty quick. It's there because I used to support it. However it quickly became less doable to support with the hotplug rewrite. I could do some hacks to support arbitrary node specifiers without globbing, but it would be fairly evil for little actual gain. > > BTW: What happens if I have two similar devices on the system? The "Name" for my > device is pretty vague, and if I was trying to use hardware like this on a > multi-user box it would seem to present serious headaches. The name either has to be unique, or you have to use the phys as well. For a multi-user system it is considerably more reasonable to state that you have to plug the devices into the right ports or it won't work. There's really not a lot more we can _do_, adding support for the vendor and product ID numbers would help a little bit, but for the case of two identical devices, or close enough to have the same information, there's really not a lot available to us. We can get the device node (useless), the device name, the device phys, and if we really want to we can get the device vendor and product numbers. As best I can tell, nobody in gentoo or Debian really missed the ability to specify a device node before the switch over, mostly because doing so involves writing a udev script that... Has exactly the same limits on what information you can obtain as you have in the X configuration, though it is sometimes in a different form.
Cant solve the problem. Som cursor keys and Insert-Delete-End-Home-PgUp-PgDwn group not works. Is there a reason why their support disabled? Using 2 layouts the same problem in both. Thx in advance.
(In reply to comment #25) > Cant solve the problem. Som cursor keys and Insert-Delete-End-Home-PgUp-PgDwn > group not works. Is there a reason why their support disabled? Using 2 layouts > the same problem in both. Thx in advance. Please verify that that this is with the latest version of the patch applied, including the xkb data files part. Then I'm going to need the output of 'cat /proc/bus/input/devices', and your /etc/X11/xorg.conf, put them both as attachments please.
eugene@main:~$ cat /proc/bus/input/devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/class/input/input0 H: Handlers=kbd evbug event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0004 Version=0000 N: Name="GenPS/2 Genius <NULL>" P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input1 H: Handlers=mouse0 evbug event1 B: EV=7 B: KEY=1f0000 0 0 0 0 0 0 0 0 B: REL=103 I: Bus=0003 Vendor=1241 Product=0022 Version=0390 N: Name="Chicony USB Keyboard" P: Phys=usb-0000:00:10.1-2.1/input0 S: Sysfs=/class/input/input2 H: Handlers=kbd evbug event2 B: EV=120003 B: KEY=10000 7 ff800000 7ff febeffdf f3cfffff ffffffff fffffffe B: LED=7 I: Bus=0003 Vendor=1241 Product=0022 Version=0390 N: Name="Chicony USB Keyboard" P: Phys=usb-0000:00:10.1-2.1/input1 S: Sysfs=/class/input/input3 H: Handlers=kbd evbug event3 B: EV=3 B: KEY=780 40000 603878 d801d7a9 1e0000 0 0 0 I: Bus=0003 Vendor=09da Product=000a Version=0001 N: Name="A4Tech PS/2+USB Mouse" P: Phys=usb-0000:00:10.1-2.2/input0 S: Sysfs=/class/input/input4 H: Handlers=mouse1 evbug event4 B: EV=7 B: KEY=ff0000 0 0 0 0 0 0 0 0 B: REL=303 I: Bus=0001 Vendor=5456 Product=7135 Version=0001 N: Name="saa7134 IR (GoTView 7135 PCI)" P: Phys=pci-0000:00:0a.0/ir0 S: Sysfs=/class/input/input5 H: Handlers=kbd evbug event5 B: EV=100003 B: KEY=40c0300 2100000 0 0 0 0 2048007 80000180 80000003 9e0000 7bb80 0 0 cat /etc/X11/xorg.conf Section "InputDevice" Identifier "Keyboard1" Driver "evdev" Option "AutoRepeat" "500 30" Option "Device" "/dev/keyboard_one" Option "Name" "AT Translated Set 2 keyboard" Option "Phys" "*/input0" Option "XkbModel" "pc104" Option "XkbLayout" "us,ru" Option "XkbOptions" "grp:ctrl_shift_toggle" Option "XkbVariant" ",winkeys" Sorry for long message. Im having 2 keyboards (first ps/2 second usb). The usb ones consist of two devices merget physically in one. The usb keyboard acts exactly the same as ps/2.below is the part of keyboard the second xorg.xonf Identifier "Keyboard2" Driver "evdev" Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "Name" "Chicony USB Keyboard" Option "Phys" "*/input0" #using this because *input1 is multimedia Option "XkbModel" "pc102" # buttons Option "XkbLayout" "us,ru" Option "XkbOptions" "grp:ctrl_shift_toggle" Option "XkbVariant" ",winkeys" ps 4524 is the last attachmend? I used this one. Strange but after full X.org6.9 installation i can't find evdev man page.
(In reply to comment #27) > eugene@main:~$ cat /proc/bus/input/devices > I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 I had to attach these files, sorry. Can I remove my previous message (it huge)?
(In reply to comment #27) > Identifier "Keyboard2" > Driver "evdev" > Option "XkbModel" "pc102" This should be evdev, not pc102. Fix that, it should solve the problem for you. One note, I have had varied success with the second keyboard having vastly different settings from the first, if problems persist see what happens if you swap Keyboard1 and Keyboard2. And sorry, I don't know how to remove a comment, but I'll ask around.
(In reply to comment #28) Such a stupid mistake I made!!! Option "XkbModel" "pc102" should be Option "XkbModel" "evdev". But the problem still exist. One key still not answering - it is from the same cursor group - "up arrow". "xev" reports on pressing up arrow (after short hanging system): FocusOut event, serial 31, synthetic NO, window 0x2a00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 31, synthetic NO, window 0x2a00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 31, synthetic NO, window 0x0, keys: 4294967185 0 0 0 0 0 0 0 0 0 0 0 0 4294967168 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 31, synthetic NO, window 0x2a00001, root 0x3c, subw 0x0, time 415210, (78,-12), root:(82,633), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: Did I miss something again? ps. Sorry once more.
(In reply to comment #30) > But the problem still exist. One key still not > answering - it is from the same cursor group - "up arrow". "xev" reports on > pressing up arrow (after short hanging system): > FocusOut event, serial 31, synthetic NO, window 0x2a00001, > mode NotifyGrab, detail NotifyAncestor > FocusIn event, serial 31, synthetic NO, window 0x2a00001, > mode NotifyUngrab, detail NotifyAncestor > KeymapNotify event, serial 31, synthetic NO, window 0x0, > keys: 4294967185 0 0 0 0 0 0 0 0 0 0 0 0 4294967168 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > KeyRelease event, serial 31, synthetic NO, window 0x2a00001, > root 0x3c, subw 0x0, time 415210, (78,-12), root:(82,633), > state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, > XLookupString gives 0 bytes: > Did I miss something again? > ps. Sorry once more. Does it do that every time you hit up, or only the first time? As the key _is_ generating a xkb event, with the proper keysym, what exactly is going wrong after the first press?
(In reply to comment #12) > (In reply to comment #11) > > You woldn't consider porting this patch to modular xorg? > > Ought to be trivial, since the original source code is the same -- just go to > the src dir of the evdev driver and apply it; if there are any new source files, > stick 'em in Makefile.am. Well porting for xkbdata was not hard, however the makefile for evdev is not quite as nice and as I know glose to nothing about Makefiles I don't know where to edit...
(In reply to comment #31) > (In reply to comment #30) > Does it do that every time you hit up, or only the first time? > > As the key _is_ generating a xkb event, with the proper keysym, what exactly is > going wrong after the first press? Any time I press "Up" the system is "thinking" for a very short while and... Do nothing. below is xev answer upon pressing "down" KeyPress event, serial 31, synthetic NO, window 0x2a00001, root 0x3c, subw 0x0, time 572244, (26,-19), root:(77,53), state 0x0, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x2a00001, root 0x3c, subw 0x0, time 572396, (26,-19), root:(77,53), state 0x0, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: And it's differ from the answer upon pressing "up" (see comment #30). My KDE menager acts this way: going to control center/Regional & Acessibility/Keyboard shortcuts - and trying to change state for a event (ex: close window) - pressing "UP" and Kde assign "UP" to the event! And it works! But after returning the normal state "UP" still not work. Hmmm. starnge.
(In reply to comment #33) > (In reply to comment #31) > > (In reply to comment #30) Here I am again. After returning the normal state in KDE (no shorcuts action for "UP"), it starting to exibit its normal functionality, after restarting KDE "Up" still not works so I have to every start KDE change shortcut for "up" and returning it back for normal functionality, also starting Xorg and xterm only, some times kill normal functionality on "UP" function, will see. Still didnt find te root of evel. Thx in advice, my problem possibly because pc102 usage, that was rough mistake.
(In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #31) > > > (In reply to comment #30) Ok that was KDE mistake. I killed all KDE config files and started from the ground state. Now averything works just fine. thx for letting writing me all my stuff :^).
Also I am with this problem in environment KDE with event "UP", see more details in https://bugs.freedesktop.org/show_bug.cgi?id=5787 and I am using a keyboard abnt2.
Created attachment 4575 [details] [review] evdev patch for xkb abnt2
Friends, I am adding for all one patch that, joining my ideas and of the launched friend Ander and the others patchs, decides the problem with Brazilian keyboards ABNT2. With this patch, is necessary only the "evdev rewrite patch", therefore the "xkb data files" already is incorporated in this patch. I added a new model of keyboard, that can So far be configured in the control panel of the Gnome or Kde, is the best compatible way with xkb for keyboards Brazilian ABNT2. My xorg.conf (Keyboard) Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "phys" "*/serio0/input0" Option "XkbModel" "evdev_abnt2" Option "XkbLayout" "br" EndSection Marcelo E. Geyer
Created attachment 4576 [details] [review] evdev patch for xkb abnt2
(In reply to comment #24) > As best I can tell, nobody in gentoo or Debian really missed the ability to > specify a device node before the switch over, mostly because doing so involves > writing a udev script that... Has exactly the same limits on what information > you can obtain as you have in the X configuration, though it is sometimes in a > different form. we made use of this ability in the (now neglected to the point of almost being removed) ubuntu multiseat setup, in order to do arbitrary device management from a userspace setup, outside of X. this dealt with situations where you had four keyboards of the same model which might be hotplugged into different ports, e.g.
(In reply to comment #39) > Created an attachment (id=4576) [edit] > evdev patch for xkb abnt2 > I don't see a reason not to do this for the moment, however I believe that you need to file a bug against the linux kernel, because it's generally responsable for turning the hardware's scancodes into the proper symbols, which are well defined.
(In reply to comment #41) > (In reply to comment #39) > I don't see a reason not to do this for the moment, however I believe that you > need to file a bug against the linux kernel, because it's generally responsable > for turning the hardware's scancodes into the proper symbols, which are well > defined. > > The reality is that until the moment this driver it does not have has supported to xkb, since driver possess only one model xkb (evdev basic), correct? I believe that we go to have that to create models so that it has supported the most varied keyboard mappings or to add another option in xorg. My initial idea age to give the name of "evdev(abnt2)", however I remembered that the not accepted command setxkbmodel. I know that this gives to perfect, is alone the beginning, we go to argue the case. I am testing here and is functioning perfectly.
(In reply to comment #42) > (In reply to comment #41) > The reality is that until the moment this driver it does not have has > > supported > to xkb, since driver possess only one model xkb (evdev basic), correct? I > believe that we go to have that to create models so that it has supported the > most varied keyboard mappings or to add another option in xorg. My initial idea > age to give the name of "evdev(abnt2)", however I remembered that the not > accepted command setxkbmodel. I know that this gives to perfect, is alone the > beginning, we go to argue the case. I am testing here and is functioning perfectly. > The main issue is that unlike other X keyboard interfaces, it is not the job of a evdev client to map from the key codes we receive to actual key symbols based on the keyboard connected. The kernel itself has the job of converting the scancodes for the keyboard in question to the proper symbols, giving us quite well defined symbol codes for most keys. (Though with space for keys that don't have symbols as well.) This obviously has some limitations, it can't know that I moved my keycaps around for Dvorak instead of Qwerty, but we should never have the case of needing a different model for evdev for the standard keycodes, it just shouldn't happen without a kernel bug. However the difference between theory and practice is that we actually have to deal with practice, so we should probably use this patch for the moment, and someone should poke at the kernel people to make sure that I'm not missing anything.
I am trying driver evdev with mouse PS/2, recognized for kernel as "ImPS/2 Generic Wheel Mouse", however I am with difficulties to make scroll to work. In log, it appears: ... evdev_btn.c (95): Registering 5 buttons. Mouse-isa0060/serio1/input0: Init ... My xorg.conf ... Section "InputDevice" Identifier "Mouse0" Driver "evdev" Option "Phys" "isa0060/serio1/input0" Option "XRelativeAxisMap" "0" Option "YRelativeAxisMap" "1" Option "HWHELLRelativeAxisMap" "2" Option "WHEELRelativeAxisMap" "3" Option "WHELLRelativeAxisButtons" "4 5" EndSection Some idea?
Now that keyboards are working more or less perfectly with evdev, mice stopped working properly. I have two simple mice one ps/2 and one usb. Each has three buttons and a wheel. When I use evdev driver with them, the buttons are messed up. The evdev driver picks up 3 buttons, but inverts the right click and middle click. I can fix this with : xmodmap -e "pointer = 1 2 3" The wheel doesn't work and I can't map the events ( it is not detected ) and xev won't show anything. I found patches for adding configurability to the evdev buttons, but they won't apply to the rewrite. Can these be used ? https://bugs.freedesktop.org/show_bug.cgi?id=5620#c1 https://bugs.freedesktop.org/show_bug.cgi?id=968#c71 here's the log for the PS/2 mouse and keyboard: (II) evdev brain: Rescanning devices (1). (EE) evdev.c (227): New device. (**) Option "CoreKeyboard" (**) Keyboard1-isa0060/serio0/input0: Core Keyboard (**) Keyboard1-isa0060/serio0/input0: XkbRules: "xorg" (**) Option "XkbModel" "evdev" (**) Keyboard1-isa0060/serio0/input0: XkbModel: "evdev" (**) Option "XkbLayout" "us" (**) Keyboard1-isa0060/serio0/input0: XkbLayout: "us" (**) Option "XkbOptions" "compose:rwin" (**) Keyboard1-isa0060/serio0/input0: XkbOptions: "compose:rwin" (II) evdev brain: Rescanning devices (2). (II) evdev brain: AT Translated Set 2 keyboard 2 -> AT Translated Set 2 keyboard 1. (EE) evdev.c (227): New device. (**) Option "CorePointer" (**) mouse1-isa0060/serio1/input0: Core Pointer (II) mouse1-isa0060/serio1/input0: Found 3 relative axes. (II) mouse1-isa0060/serio1/input0: Configuring as pointer. (**) mouse1-isa0060/serio1/input0: WHEELRelativeAxisButtons: 4 5. (II) mouse1-isa0060/serio1/input0: Found 3 mouse buttons (II) mouse1-isa0060/serio1/input0: Configured 3 mouse buttons (II) XINPUT: Adding extended input device "mouse1-isa0060/serio1/input0" (type: MOUSE) (II) XINPUT: Adding extended input device "Keyboard1-isa0060/serio0/input0" (type: KEYBOARD) (II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (II) XINPUT: Adding extended input device "NVIDIA Event Handler" (type: Other) (II) Keyboard1-isa0060/serio0/input0: Init (EE) evdev_btn.c (95): Registering 3 buttons. (II) mouse1-isa0060/serio1/input0: Init (II) evdev brain: Rescanning devices (3). (II) evdev brain: AT Translated Set 2 keyboard 3 -> AT Translated Set 2 keyboard 2. (II) evdev brain: ImPS/2 Logitech Wheel Mouse 3 -> ImPS/2 Logitech Wheel Mouse 2. (II) Keyboard1-isa0060/serio0/input0: On (II) mouse1-isa0060/serio1/input0: On Here's the output for the USB device : (II) evdev brain: Rescanning devices (1). (EE) evdev.c (227): New device. (**) Option "CoreKeyboard" (**) Keyboard2-usb-0000:00:1d.1-1.1/input0: Core Keyboard (**) Keyboard2-usb-0000:00:1d.1-1.1/input0: XkbRules: "xorg" (**) Option "XkbModel" "evdev" (**) Keyboard2-usb-0000:00:1d.1-1.1/input0: XkbModel: "evdev" (**) Option "XkbLayout" "us" (**) Keyboard2-usb-0000:00:1d.1-1.1/input0: XkbLayout: "us" (**) Option "XkbOptions" "compose:rwin" (**) Keyboard2-usb-0000:00:1d.1-1.1/input0: XkbOptions: "compose:rwin" (II) evdev brain: Rescanning devices (2). (II) evdev brain: Acer Generic USB Hub Keyboard 2 -> Acer Generic USB Hub Keyboard 1. (EE) evdev.c (227): New device. (**) Option "CorePointer" (**) mouse2-usb-0000:00:1d.1-1.3/input0: Core Pointer (II) mouse2-usb-0000:00:1d.1-1.3/input0: Found 3 relative axes. (II) mouse2-usb-0000:00:1d.1-1.3/input0: Configuring as pointer. (**) mouse2-usb-0000:00:1d.1-1.3/input0: WHEELRelativeAxisButtons: 4 5. (II) mouse2-usb-0000:00:1d.1-1.3/input0: Found 3 mouse buttons (II) mouse2-usb-0000:00:1d.1-1.3/input0: Configured 3 mouse buttons (II) XINPUT: Adding extended input device "mouse2-usb-0000:00:1d.1-1.3/input0" (type: MOUSE) (II) XINPUT: Adding extended input device "Keyboard2-usb-0000:00:1d.1-1.1/input0" (type: KEYBOARD) (II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (II) XINPUT: Adding extended input device "NVIDIA Event Handler" (type: Other) (II) Keyboard2-usb-0000:00:1d.1-1.1/input0: Init (EE) evdev_btn.c (95): Registering 3 buttons. (II) mouse2-usb-0000:00:1d.1-1.3/input0: Init (II) evdev brain: Rescanning devices (3). (II) evdev brain: Acer Generic USB Hub Keyboard 3 -> Acer Generic USB Hub Keyboard 2. (II) evdev brain: Logitech Optical USB Mouse 3 -> Logitech Optical USB Mouse 2. (II) Keyboard2-usb-0000:00:1d.1-1.1/input0: On (II) mouse2-usb-0000:00:1d.1-1.3/input0: On
Alright, a slightly updated version of this has been committed to the x.org modular CVS tree, and a new tarball should be out in the next week or two depending on issues that come up. I would appreciate it if anyone who has had problems with this could test the current code, and submit a new bug report if there are any issues. Thank you.
Any chance of seeing this in 6.9.x? Or is that tree dead already?
Reassign to the new evdev maintainer.
(In reply to comment #47) > Any chance of seeing this in 6.9.x? Or is that tree dead already? That tree appears to be dead, however given that it's mostly a matter of copying the files to the right directory and updating the Imakefile I should be able to throw the code in the 6.9.x tree. That said, I may do that once or twice, but further development will be in the modular CVS tree. (Minimal instructions for how to do the copying over yourself will probably be included in the readme when I do the next release though.)
(In reply to comment #49) > (In reply to comment #47) > > Any chance of seeing this in 6.9.x? Or is that tree dead already? > > That tree appears to be dead, however given that it's mostly a matter of copying > the files to the right directory and updating the Imakefile I should be able to > throw the code in the 6.9.x tree. > > That said, I may do that once or twice, but further development will be in the > modular CVS tree. That'll require approval from the 6.9.x release manager.
I'm trying to use this driver to get around a problem where a usb kvm makes the event device node for my Logitech mx1000 mouse "go away" when switched to the other machine. I'm using evdev from xorg CVS HEAD dated today, March 29th, 2006. This is the relevant part of my xorg.conf: Section "InputDevice" Identifier "Mouse" Driver "evdev" Option "Name" "Logitech USB Receiver" Option "Phys" "usb-*/input0" EndSection When the mouse is found, the Xorg.0.log looks like this (I added some debug code): (**) Mouse: name: Logitech USB Receiver, phys: usb-*/input0, device: (null), pass: 0. (II) evdev brain: Rescanning devices (1). (II) Checking /dev/input/event0 (II) dev: /dev/input/event0, name: Logitech Logitech Freedom 2.4, phys: usb-0000:00:02.0-4/input0 (II) Checking /dev/input/event1 (II) dev: /dev/input/event1, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input0 (II) Checking /dev/input/event2 (II) dev: /dev/input/event2, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input1 (II) Checking /dev/input/event3 (II) dev: /dev/input/event3, name: Logitech USB Receiver, phys: usb-0000:00:02.0-1.2/input0 (**) Option "CorePointer" (**) Mouse-usb-0000:00:02.0-1.2/input0: Core Pointer (II) Mouse-usb-0000:00:02.0-1.2/input0: Found 4 relative axes. (II) Mouse-usb-0000:00:02.0-1.2/input0: Configuring as pointer. (**) Mouse-usb-0000:00:02.0-1.2/input0: HWHEELRelativeAxisButtons: 6 7. (**) Mouse-usb-0000:00:02.0-1.2/input0: WHEELRelativeAxisButtons: 4 5. (II) Mouse-usb-0000:00:02.0-1.2/input0: Found 16 mouse buttons (II) Mouse-usb-0000:00:02.0-1.2/input0: Configured 20 mouse buttons (II) Checking /dev/input/event4 (II) dev: /dev/input/event4, name: Saitek Saitek X45 Flight Control Stick , phys: usb-0000:00:02.1-3.3/input0 (II) Checking /dev/input/event5 (II) Checking /dev/input/event6 (II) Checking /dev/input/event7 (II) Checking /dev/input/event8 (II) Checking /dev/input/event9 (II) Checking /dev/input/event10 (II) Checking /dev/input/event11 (II) Checking /dev/input/event12 (II) Checking /dev/input/event13 (II) Checking /dev/input/event14 (II) Checking /dev/input/event15 (II) Checking /dev/input/event16 (II) Checking /dev/input/event17 (II) Checking /dev/input/event18 (II) Checking /dev/input/event19 (II) Checking /dev/input/event20 (II) Checking /dev/input/event21 (II) Checking /dev/input/event22 (II) Checking /dev/input/event23 (II) Checking /dev/input/event24 (II) Checking /dev/input/event25 (II) Checking /dev/input/event26 (II) Checking /dev/input/event27 (II) Checking /dev/input/event28 (II) Checking /dev/input/event29 (II) Checking /dev/input/event30 (II) Checking /dev/input/event31 Then some more normal X log stuff happens, and for whatever reason, another scan from evdev happens: (**) Option "CoreKeyboard" (**) Keyboard: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard: Protocol: standard (**) Option "AutoRepeat" "250 30" (**) Option "XkbRules" "xorg" (**) Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc104" (**) Keyboard: XkbModel: "pc104" (**) Option "XkbLayout" "us" (**) Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard" (type: KEYBOARD) (II) XINPUT: Adding extended input device "Mouse-usb-0000:00:02.0-1.2/input0" (type: MOUSE) (II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain) (II) XINPUT: Adding extended input device "NVIDIA Event Handler" (type: Other) (EE) evdev_btn.c (95): Registering 20 buttons. (II) Mouse-usb-0000:00:02.0-1.2/input0: Init (II) evdev brain: Rescanning devices (2). (II) Checking /dev/input/event0 (II) dev: /dev/input/event0, name: Logitech Logitech Freedom 2.4, phys: usb-0000:00:02.0-4/input0 (II) Device found! Returning true. (II) Checking /dev/input/event1 (II) dev: /dev/input/event1, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input0 (II) Device found! Returning true. (II) Checking /dev/input/event2 (II) dev: /dev/input/event2, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input1 (II) Device found! Returning true. (II) Checking /dev/input/event3 (II) dev: /dev/input/event3, name: Logitech USB Receiver, phys: usb-0000:00:02.0-1.2/input0 (II) Device found! Returning true. (II) Checking /dev/input/event4 (II) dev: /dev/input/event4, name: Saitek Saitek X45 Flight Control Stick , phys: usb-0000:00:02.1-3.3/input0 (II) Device found! Returning true. (II) Checking /dev/input/event5 (II) Checking /dev/input/event6 (II) Checking /dev/input/event7 (II) Checking /dev/input/event8 (II) Checking /dev/input/event9 (II) Checking /dev/input/event10 (II) Checking /dev/input/event11 (II) Checking /dev/input/event12 (II) Checking /dev/input/event13 (II) Checking /dev/input/event14 (II) Checking /dev/input/event15 (II) Checking /dev/input/event16 (II) Checking /dev/input/event17 (II) Checking /dev/input/event18 (II) Checking /dev/input/event19 (II) Checking /dev/input/event20 (II) Checking /dev/input/event21 (II) Checking /dev/input/event22 (II) Checking /dev/input/event23 (II) Checking /dev/input/event24 (II) Checking /dev/input/event25 (II) Checking /dev/input/event26 (II) Checking /dev/input/event27 (II) Checking /dev/input/event28 (II) Checking /dev/input/event29 (II) Checking /dev/input/event30 (II) Checking /dev/input/event31 (II) Mouse-usb-0000:00:02.0-1.2/input0: On So now I switch to the other box using the kvm. This is what shows up in Xorg.0.log: (EE) Read error: Unknown error 999 (19, -1 != 24) (II) evdev brain: Rescanning devices (3). (II) Checking /dev/input/event0 (II) dev: /dev/input/event0, name: Logitech Logitech Freedom 2.4, phys: usb-0000:00:02.0-4/input0 (II) Checking /dev/input/event1 (II) dev: /dev/input/event1, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input0 (II) Checking /dev/input/event2 (II) dev: /dev/input/event2, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input1 (II) Checking /dev/input/event3 (II) Checking /dev/input/event4 (II) dev: /dev/input/event4, name: Saitek Saitek X45 Flight Control Stick , phys: usb-0000:00:02.1-3.3/input0 (II) Checking /dev/input/event5 (II) Checking /dev/input/event6 (II) Checking /dev/input/event7 (II) Checking /dev/input/event8 (II) Checking /dev/input/event9 (II) Checking /dev/input/event10 (II) Checking /dev/input/event11 (II) Checking /dev/input/event12 (II) Checking /dev/input/event13 (II) Checking /dev/input/event14 (II) Checking /dev/input/event15 (II) Checking /dev/input/event16 (II) Checking /dev/input/event17 (II) Checking /dev/input/event18 (II) Checking /dev/input/event19 (II) Checking /dev/input/event20 (II) Checking /dev/input/event21 (II) Checking /dev/input/event22 (II) Checking /dev/input/event23 (II) Checking /dev/input/event24 (II) Checking /dev/input/event25 (II) Checking /dev/input/event26 (II) Checking /dev/input/event27 (II) Checking /dev/input/event28 (II) Checking /dev/input/event29 (II) Checking /dev/input/event30 (II) Checking /dev/input/event31 (II) Mouse-usb-0000:00:02.0-1.2/input0: Off Note /dev/input/event3, the Logitech USB Receiver, if now gone. I switch back: (II) evdev brain: Rescanning devices (4). (II) Checking /dev/input/event0 (II) dev: /dev/input/event0, name: Logitech Logitech Freedom 2.4, phys: usb-0000:00:02.0-4/input0 (II) Device found! Returning true. (II) Checking /dev/input/event1 (II) dev: /dev/input/event1, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input0 (II) Device found! Returning true. (II) Checking /dev/input/event2 (II) dev: /dev/input/event2, name: Microsoft Microsoft Wireless Optical Desktop® 1.00, phys: usb-0000:00:02.0-1.1/input1 (II) Device found! Returning true. (II) Checking /dev/input/event3 (II) Checking /dev/input/event4 (II) dev: /dev/input/event4, name: Saitek Saitek X45 Flight Control Stick , phys: usb-0000:00:02.1-3.3/input0 (II) Device found! Returning true. (II) Checking /dev/input/event5 (II) Checking /dev/input/event6 (II) Checking /dev/input/event7 (II) Checking /dev/input/event8 (II) Checking /dev/input/event9 (II) Checking /dev/input/event10 (II) Checking /dev/input/event11 (II) Checking /dev/input/event12 (II) Checking /dev/input/event13 (II) Checking /dev/input/event14 (II) Checking /dev/input/event15 (II) Checking /dev/input/event16 (II) Checking /dev/input/event17 (II) Checking /dev/input/event18 (II) Checking /dev/input/event19 (II) Checking /dev/input/event20 (II) Checking /dev/input/event21 (II) Checking /dev/input/event22 (II) Checking /dev/input/event23 (II) Checking /dev/input/event24 (II) Checking /dev/input/event25 (II) Checking /dev/input/event26 (II) Checking /dev/input/event27 (II) Checking /dev/input/event28 (II) Checking /dev/input/event29 (II) Checking /dev/input/event30 (II) Checking /dev/input/event31 Note that while the "hotplug" event triggered a new scan, the new device isn't present yet. I added a larger delay (as much as 4 seconds) to the usleep call in evdevReadInput in evdev_brain.c, but, presumably to the asyncronous nature of X, it just blows by the delay, and the device isn't seen. Although, I have seen instances where the delay is observed, and the device is then seen and properly re-acquired. Thoughts?
I've had a bit of difficulty with this code so I dug around a bit. First off, I found that it was leaking file descriptors. Second, the method of doing a select on /proc/bus/usb/devices then sleeping then scanning the event files in /dev/input just didn't work, so I start a conversation in #xorg-devel on freeload, which lead to the suggestion of using inotify. I took the suggestion and ran with it, and created a patch. This patch Works For Me, but it's got maybe 10 minutes of testing on it. I don't know if it leaks memory, or blows up after extended use. The patch as it stands now requires the inotify headers to be in the src directory. I'm hoping someone who knows autoconf well in #xorg-devel will help me add autoconf support for detecting inotify. It also requires inotify support in the kernel. Anyhow, just patch, put inotify.h and inotify-syscalls.h (from http://www.kernel.org/pub/linux/kernel/people/rml/inotify/headers/) in xf86-input-evdev/src and make. This patch also fixes the file descriptor leak. Daniel
Created attachment 5137 [details] [review] inotify patch
Created attachment 5138 [details] [review] file dscriptor leak fix Requested as a standalone patch.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.