Attached is a new input driver for linux input devices. The linux kernel input layer is a new generic interface to all kinds of input devices, and is the canonical way of accessing input devices on linux. This driver is a generic driver that works for keyboards and mice, and it should be possible to implement touch screen support pretty easily too. Also this driver has the unique feature that it is possible to use only one of several attached keyboards, where the standard driver allways reads input from all attached keyboards.
Created attachment 556 [details] The input driver sources Untar in toplevel xc directory, apply patch.
Patches, currently used by gentoo: http://dev.gentoo.org/~spyderous/xorg-x11/patchsets/6.8.1/patch-0.1/
Juliusz Chroboczek had some objections to our patches, saying they didn't take advantage of some of the primary features of the event interface, such as checking the times of input etc. Anyhow, we got them from Debian; the author is Zephaniah E. Hull <warp AT debian.org>. I tried to find Juliusz's post about that, but the archives are a little difficult to search.
I did read through the patches used by gentoo before writing this driver. The driver I've written differs from the gentoo patches in two ways: 1) The evdev driver I've written is a standalone, generic evdev driver. Standalone in the sense that it isn't another protocol for the "mouse" and "keyboard" drivers, it's a new driver, "evdev". Generic in the sense that it works for both keyboard and mice and the evdev ioctl probing is shared between the two parts. The probing works by asking the evdev device what types of events it can generate and the add the corresponding input classes to the X input device. I think adding evdev as a new protocol to the "mouse" and "keyboard" drivers as the gentoo patches does, is also a valid decision, but the new-driver-approch allows us to drop the entire mouse and keyboard legacy code (serial io, mouse protocol auto-detection, etc) for a driver that's smaller that the gentoo patch. 2) My driver deliberately does not handle input device hotplugging, where the gentoo patches hardcodes an adhoc discovery mechanism which uses an simple protocol over a socket in /tmp/.X11-uinx and is specific to evdev devices and linux. Of the two, 2) is really my biggest beef with the gentoo patches. I'd like to see a hotplugging solution that works for all devices, drivers and platforms, and where the discovery mechanism is outside the server. The external hotplug mechanism should be able to tell the server to add a new device, loading a new driver if necessary. This will work with the existing range of drivers (notably wacom and synaptics). Also, it can work for buses that don't generate hotplug events (i.e. if you plug in a serial wacom tablet), by explicitly running a program that adds the device. See bug #971 for a prototype of this idea.
Whoa, very cool. I'd be looking forward for this.
Do we also have a xkb/keycodes/evdev file, to map numeric event values to <FBAR>-style XF86 keycodes?
(In reply to comment #6) > Do we also have a xkb/keycodes/evdev file, to map numeric event values to > <FBAR>-style XF86 keycodes? No, right now the keyboard part of the driver doesn't work very well with xkb, but it's just a matter of creating the keycodes file, as you mention. I didn't do this yet, but it's one of the first things I'll look into when I pick up work on this again. Unless you want to give it a try :)
Created attachment 986 [details] Another Linux event input interface driver Hello, I have written an xfree86 4.4.0 driver that uses the Linux event interface, but is limited to mice. It sort of resembles the implementation of the existing 'evdev' patch. I just didn't look at the bugs database before I decided to write the driver on my own. The main differences between my patch and the 'evdev' one are: - Limited to mice - written without deep unterstanding of X internals + more verbose log messages. A look at the startup log gives a good hint if something goes wrong. + button mapping: 1,2,3 left, middle, right 4-7 mouse wheel 8+ others As far as I can see, the evdev implementation maps extended buttons into the range of the mouse wheel. + precise movement/button reporting consider someone moves the mouse and simultaneously presses a button. The generated events are MovX,MovY,Btn, SYN, MovX,MovY the 'evdev' driver reports to the Xserver Btn,MovX,MovY whereas my driver reports MovX,MovY,Btn,MovX,MovY the mouse pointer would reach the same pixel, BUT the original relation of button press to movement is lost. Nothing serious for office use, but a die-hard quaker would sure notice it :-) Installation: - untar in <path_to_x_source>/programs/Xserver/hw/xfree86/input, or whatever is appropriate for the current X version. - add 'linuxevdev' to the list of drivers that should be compiled. I am subscribed to the xorg mailinglist.
Created attachment 987 [details] Forgot the Imakefile [nt]
(In reply to comment #9) > Created an attachment (id=987) [edit] > Forgot the Imakefile [nt] > I love the idea to have two detached keyboards. I tried the patch and it does not seem to work (it works for mouse). I get the following: Config: Section "InputDevice" Identifier "USBKeyboard" Driver "evdev" # today my usb keyboard is here Option "Device" "/dev/input/event2" EndSection Section "ServerLayout" ... InputDevice "USBKeyboard" ... EndSection Log at init: (**) Option "AlwaysCore" "off" (**) USBKeyboard: Device: "/dev/input/event2" ... (II) XINPUT: Adding extended input device "USBKeyboard" (type: MOUSE) ... (II) USBKeyboard: fd=7 (II) USBKeyboard: No button events available result of "xinput list": ... "USBKeyboard" id=0 [XExtensionDevice] Num_keys is 129 Min_keycode is 8 Max_keycode is 136 ... But when I run "xinput test USBKeyboard", each time I type on a key I get (in Xorg.0.log): LookupDeviceIntRec id=0x8 not found and xinput report no key events. Anyway I guess that to get two detached keyboards I need to have 2 USB keyboards using the evdev driver (one core keyboard and an "Extension" keyboard)? In other words, I've a laptop with a keyboard and I want to plug an USB keyboard which will not generate core key events but only XInput extended key events. Is this (potentially) possible with your evdev driver? Or should I patch the linux kernel too? Thanks, Olivier
<ajax> krh: weird issue with evdev(4). if you try to configure an event device bound to a mouse as your keyboard, the server segfaults. <krh> ajax, as I remember you'd just say "use /dev/input/event2 with the evdev driver" and the driver would automatically figure out if it is a mouse of a keyboard <ajax> krh: right, but you still need to specify a core keyboard and core pointer in the ServerLayout section http://freedesktop.org/~ajax/evdev-crash-fix-1.patch We should probably just initialize pInfo->flags to 0 and set the bits corresponding to the probed capabilities instead.
With a couple of changes, I've got both drivers building against kernel 2.6.x and the xorg sdk. Building evdev_drv against kernel 2.6.x without an xorg source tree needs the xorg sdk installed and the following simple patches: http://personal.nbnet.nb.ca/strawman/evdev-Imakefile-SDK.patch and http://personal.nbnet.nb.ca/strawman/evdev-kernel26-fix-1.patch In my xorg.conf I've got: Section "InputDevice" Identifier "Mouse0" Driver "evdev" Option "Device" "/dev/input/event4" Option "Protocol" "Auto" Option "ZAxisMapping" "4 5" Option "Buttons" "10" Option "Emulate3Buttons" "no" EndSection /proc/bus/input/devices (mice) I: Bus=0011 Vendor=0002 Product=0001 Version=0000 N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 H: Handlers=mouse0 event1 B: EV=7 B: KEY=70000 0 0 0 0 0 0 0 0 B: REL=3 I've got one mouse connected, and I assume the above is a result of a particular option regarding usb mice in my bios. USB Mouse Support I: Bus=0003 Vendor=046d Product=c01d Version=2100 N: Name="Logitech USB-PS/2 Optical Mouse" P: Phys=usb-0000:00:02.0-2/input0 H: Handlers=mouse2 event4 B: EV=f B: KEY=ff0000 0 0 0 0 0 0 0 0 B: REL=103 B: ABS=300 0 Unfortunately, Xorg.0.log shows me: (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) Mouse0: fd=5 (II) Mouse0: No key events available (II) Mouse0: missing x or y absolute axes As well, LookupDeviceIntRec id=0x8 not found is also printed a lot. The mouse ends up working well enough, and xmodmap -pp claims: There are 32 pointer buttons defined. However, the buttons get mappped undesirably for me. On this Logitech MX510, the two side buttons become 4 and 5 along with the wheel. The top button gets 6, and the "cruise control" buttons get 4 and 5 as well (as expected). The foremost "cruise control" button also produces an extraneous ButtonRelease event. Button 4 is expected, but an event for button 7 also appears as described here: http://bugzilla.kernel.org/show_bug.cgi?id=1786 While i was able to get the second driver, linuxevdev_drv, to build against the xorg sdk, i had to copy several headers from the xorg tree to the linuxevdev directory. While it did build successfully, trying to use it wedges my box forcing me to ctrl-alt-del or reset.
Created attachment 1671 [details] evdev driver with autotool funkyness Here's an update of the evdev driver. I've repackaged it as a autotooled package in the hope that this is how it will be distributed eventually, once we modularize the monolithic tree. Also, I've incorporated ajax's fixes from comment #11 and made the log messages less alarming when it discovers that a mouse is not a keyboard. The README file describes how to configure and install it.
Okidokey, this driver is now comitted on HEAD.
Created attachment 1685 [details] [review] hwheel.diff Seeing as this evdev bug is still open... The primary toolkits on Linux, GTK and QT, have mapped buttons 6 and 7 to left and right wheel action for a very long time now. Pressing a mouse button that maps to 6 or 7 will move any horizontal scrollbars underneath the cursor (unless intercepted by the WM). I'd suggest with the evdev interface that we make it policy that buttons 6 and 7 are for the horizontal wheel and all the extra buttons are mapped to 8 and above. Simple patch attached.
(In reply to comment #15) > Created an attachment (id=1685) [edit] > hwheel.diff > > Seeing as this evdev bug is still open... > > The primary toolkits on Linux, GTK and QT, have mapped buttons 6 and 7 to left > and right wheel action for a very long time now. Pressing a mouse button that > maps to 6 or 7 will move any horizontal scrollbars underneath the cursor > (unless intercepted by the WM). > > I'd suggest with the evdev interface that we make it policy that buttons 6 and > 7 are for the horizontal wheel and all the extra buttons are mapped to 8 and > above. > > Simple patch attached. Seems like just the right thing to do. I've applied this to the in-tree version of the driver, if anybody wants a tarball, I'll make one. Thanks, Kristian
Created attachment 1745 [details] updated tarball as of Jan. 25
Tested the last tarball on Logitech MX 1000. Actually it seems there is a problem on the lower level - kernel evdev reports this device as having KEY_UNKNOWN - so X evdev driver is trying to initialize it as a keyboard. As a small request - can KEY_UNKNOWN be ignored when walking through the key_bitmask: for (i = 0; i < BTN_MISC; i++) if (i != KEY_UNKNOWN && TestBit(i, key_bitmask)) { xf86Msg(X_INFO, "%s: Found key %d\n", pInfo->name, i); break; } All the rest of problems is on the kernel level, so I'll report it to other people:)
MX1000 support should be fixed in 2.6.11-rc3. There still is the issue of the mouse reporting both button and wheel events for horizontal scrolling and up/down buttons, but that's not necessarily a bug.
Okay, here's a question from the back row :-) In response to comment #4: Point 1 is well-taken, particularly as I have a Logitech Elite keyboard with a scroll wheel - i.e. it generates both mouse-like and keyboard-like events ... For Point 2, though: That will be wonderful to see, but for the moment your driver plays very poorly with hotplugging (in fact the only way I can see to do it is to write some custom udev rules to symlink the /dev/input/event? files appropriately, which is inelegant to say the least). The Gentoo driver's discovery mechanism works quite well. For example, the Logitech Elite keyboard creates two event devices - one (on my machine event3) for normal keyboard stuff and the other (event4) for the scroll wheel as well as all extra keys (including the function keys when F-Lock is off). In xorg.conf, I have a keyboard entry with "Dev Name" = "Logitech Logitech USB Keyboard" (sic) and "Dev Phys" = "*input0", another with the same "Dev Name" but with "Dev Phys" = "*input1", and a mouse entry with that same "Dev Name" and "Dev Phys" = "*input1". Now, no matter in what order things get plugged in, Gentoo's evdev driver finds the correct "event?". All it's doing is leveraging the information given to it by the kernel-side evdev driver. And besides, it seems like the discovery/specification part of the task is orthogonal to the driver proper; why not obey the "Device" flag when given, or use Gentoo's search-with-globs when "Dev Name" and "Dev Phys" are given? That way, hot-plugging works now, and it can get pretty when hot-plugging in X gets pretty. (I think I feel a well-then-why-don't-you-code-it-yourself coming :-) I might be able to slap together something with the best of both drivers, but I'd be just getting my feet wet, so it could take me a bit to come up with something usable.)
Hrm ... I just realized you're probably referring in comment #4 to an older version of Gentoo's driver, since the current one uses ioctls to find the proper event? device. I only see sockets used in evdevControl() and friends. (At any rate, I can still try merging Gentoo's discovery code with the driver if anyone's interested.)
Created attachment 2219 [details] evdev.man Simple man page. Doesn't cover quite all the common options, but those belong in xorg.conf.5x anyway (ZAxisMapping etc.)
Created attachment 2646 [details] [review] evdev-should-grab-1.patch the gentoo/debian patch properly does EVIOCGRAB on DEVICE_ON/DEVICE_OFF. the current evdev driver doesn't, which means keyboards will still send events through the kernel's kbd hander (meaning your keystrokes still go through to the console, so ^C will kill startx!) there's an issue here, EVIOCGRAB only exists in 2.6, so i added the #define for it. should we even attempt to build evdev on pre-2.6 since we know it won't work right?
(In reply to comment #20) > Okay, here's a question from the back row :-) > > In response to comment #4: Point 1 is well-taken, particularly as I have a > Logitech Elite keyboard with a scroll wheel - i.e. it generates both mouse-like > and keyboard-like events ... > > For Point 2, though: That will be wonderful to see, but for the moment your > driver plays very poorly with hotplugging (in fact the only way I can see to do > it is to write some custom udev rules to symlink the /dev/input/event? files > appropriately, which is inelegant to say the least). The Gentoo driver's > discovery mechanism works quite well. I see it the other way around - putting device discovery in the mouse and keyboard driver is inelegant since it doesn't belong there and second guesses whatever discovery system you OS uses. On the other hand, using udev to discover and consistently name devices is precisely what udev was made for. The full hotplug functionality may not be right around the corner, but udev is here today and complements the evdev driver quite nicely.
(In reply to comment #23) > Created an attachment (id=2646) [edit] > evdev-should-grab-1.patch > > the gentoo/debian patch properly does EVIOCGRAB on DEVICE_ON/DEVICE_OFF. the > current evdev driver doesn't, which means keyboards will still send events > through the kernel's kbd hander (meaning your keystrokes still go through to > the console, so ^C will kill startx!) Haha, that's cool... I did notice the keystrokes going to the vt as well, but I usually run the X server on a new vt so I never saw this one. > there's an issue here, EVIOCGRAB only exists in 2.6, so i added the #define for > it. should we even attempt to build evdev on pre-2.6 since we know it won't > work right? We'll have to drop 2.4 support then, this is a pretty important fix.
(In reply to comment #25) > Haha, that's cool... I did notice the keystrokes going to the vt as well, but I > usually run the X server on a new vt so I never saw this one. The multiseat patches in bug #2216 make this much easier to trigger. When you start a server with -noswitchvts you need to pull its keyboard out of the common pool so your keystrokes don't keep going to the console, otherwise you can stomp another user's session. > We'll have to drop 2.4 support then, this is a pretty important fix. Fine with me, I think this driver has broken the build on 2.2 since its introduction and there's no reason to break that. I'll figure out the imakery to only build evdev on 2.6. This also lets us drop the #ifndef EV_RST hack.
(In reply to comment #26) > (In reply to comment #25) > > Haha, that's cool... I did notice the keystrokes going to the vt as well, but I > > usually run the X server on a new vt so I never saw this one. > > The multiseat patches in bug #2216 make this much easier to trigger. When you > start a server with -noswitchvts you need to pull its keyboard out of the common > pool so your keystrokes don't keep going to the console, otherwise you can stomp > another user's session. Ah, yeah, that wont work without the grab ioctl. I reproduced it using Xorg vt0 from vt0. > > We'll have to drop 2.4 support then, this is a pretty important fix. > > Fine with me, I think this driver has broken the build on 2.2 since its > introduction and there's no reason to break that. I'll figure out the imakery > to only build evdev on 2.6. This also lets us drop the #ifndef EV_RST hack. Good stuff.
Created attachment 2655 [details] [review] evdev-should-grab-2.patch i was wrong, evdev doesn't try to build before 2.4 because HasLinuxInput won't be defined. this patch adds EVIOCGRAB, changes EV_RST to EV_SYN, and only adds evdev to OSXInputDrivers2 when the kernel version is >= 2.6. i'll commit this shortly.
I've recently noticed some oddness from xmodmap -pp There are 32 pointer buttons defined. Physical Button Button Code 1 1 2 3 3 2 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 148 Note the last line. I'm still seeing an extra event for a mouse button. I'm curious as to what "...but that's not necessarily a bug." means in Comment #19. ButtonPress event, serial 30, synthetic NO, window 0x2400001, root 0xd4, subw 0x2400002, time 2855105, (51,44), root:(55,695), state 0x0, button 4, same_screen YES ButtonRelease event, serial 30, synthetic NO, window 0x2400001, root 0xd4, subw 0x2400002, time 2855105, (51,44), root:(55,695), state 0x800, button 4, same_screen YES LeaveNotify event, serial 30, synthetic NO, window 0x2400001, root 0xd4, subw 0x0, time 2855105, (51,44), root:(55,695), mode NotifyUngrab, detail NotifyInferior, same_screen YES, focus YES, state 0 ButtonRelease event, serial 30, synthetic NO, window 0x2400001, root 0xd4, subw 0x2400002, time 2855281, (51,44), root:(55,695), state 0x0, button 11, same_screen YES
(In reply to comment #28) > i'll commit this shortly. committed. (In reply to comment #29) > I've recently noticed some oddness from xmodmap -pp > > There are 32 pointer buttons defined. And there shouldn't be, see the /* FIXME */ around line 440. I think I know how to properly account for buttons and relative axes, which should make this go away.
for people stuck on 6.8.2 there's a patch to add this driver here: http://people.freedesktop.org/~ajax/evdev-for-6.8.2-1.patch
Ok, here's what i do to use evdev_drv with a Logitech MX 510 mouse: http://personal.nbnet.nb.ca/strawman/evdev-ten-button-hack.patch heh. Anyway, obviously this caps the number of buttons at 10 from 32. This eliminates the extraneous press/release event linked to "cruise control" button 4, and this mouse has ten buttons anyway. I've created a udev rule that (i think) will adjust a symlink (/dev/mouse) to follow whatever usb port you've plugged your mouse into. Adjust to suit, and it may suck: http://personal.nbnet.nb.ca/strawman/20-local.rules Lastly, I'm using ~/.Xmodmap to remap some buttons. It contains: pointer = 1 3 2 4 5 8 9 6 7 10 or you can: xmodmap -e "pointer = 1 3 2 4 5 8 9 6 7 10" Mozilla/Firefox and other apps seem to expect the two side button to show up as events 6 & 7. This also takes care of the the last button getting set to a random value.
It seems my udev rule sucks. Please ignore, or better come up with a better rule.
Created attachment 2708 [details] [review] evdev-for-6.8.2-2.patch I had to modify the patch a little to get it to work. This does require that 'evdev' be added to the end of '#define XInputDrivers keyboard mouse evdev' for it to compile
adding myself CC
I've been using the following udev rule for the past week or so: cat /etc/udev/rules.d/20-evdev.rules KERNEL="event*", SYSFS{product}="*Mouse", NAME="input/%k", SYMLINK="mouse" This attempt has yet to give me any trouble.
One more try at a genric udev rule, dropping NAME= since i just want a symlink. # Mouse KERNEL="event*", BUS="usb", SYSFS{product}="*Mouse*", SYMLINK="mouse"
I have one problem with this driver.. Using the Keyboard from the logitech MX3100 combo, I can't access some keys.. When I run "showkeys" in a console, they have keycodes > 256.. My temporary hack is to do a "if (ev.code>256) ev.code = 256-ev.code%256;" in the evdev driver just before its passed to xf86PostKeyboardEvent.. The nasty part is that they could easily mapped to legal X codes since there are big holes in the keycode space.. Maybe extend Xkb to accept 16bit codes in input and convert them ...
(In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=1685) [edit] [edit] > > hwheel.diff > > > > Seeing as this evdev bug is still open... > > > > The primary toolkits on Linux, GTK and QT, have mapped buttons 6 and 7 to left > > and right wheel action for a very long time now. Pressing a mouse button that > > maps to 6 or 7 will move any horizontal scrollbars underneath the cursor > > (unless intercepted by the WM). > > > > I'd suggest with the evdev interface that we make it policy that buttons 6 and > > 7 are for the horizontal wheel and all the extra buttons are mapped to 8 and > > above. > > > > Simple patch attached. > > Seems like just the right thing to do. I've applied this to the in-tree version > of the driver, if anybody wants a tarball, I'll make one. > > Thanks, > Kristian > I own an Logitech MX510. The MX510 doesn't have an hwheel. So I have mapped button 6 and 7 to my two thumb buttons. In browsers the buttons 6 and 7 are used to "go back one page" and "go forward one page". I had to modify the xmodmap pointer to get it working. xmodmap -e "pointer = 1 3 2 4 5 8 9 6 7 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32" I think it should be set by default to get rid of the xmodmap pointer. Some mice have only 1 thumb button which is the "go back one page" button then. How-To: http://www.linux-gamers.net/modules/wfsection/article.php?articleid=46
so it turns out that there's far too many people running 2.6 kernels with 2.4 headers, and evdev will fail to build on that configuration. guess we have to re-add the SYN/RST hack and soft-define EVIOCGRAB now. joy. i think i can detect when we're running on a 2.4 kernel based on the return value from the EVIOCGRAB ioctl (should be EINVAL i think). don't know whether we want to warn or die when someone tries to use evdev for a keyboard in 2.4; i think i prefer die. should still work as a mouse driver though.
(In reply to comment #40) > so it turns out that there's far too many people running 2.6 kernels with 2.4 > headers, and evdev will fail to build on that configuration. guess we have to > re-add the SYN/RST hack and soft-define EVIOCGRAB now. joy. > > i think i can detect when we're running on a 2.4 kernel based on the return > value from the EVIOCGRAB ioctl (should be EINVAL i think). don't know whether > we want to warn or die when someone tries to use evdev for a keyboard in 2.4; i > think i prefer die. should still work as a mouse driver though. Yeah, I think Fedora Core for one is guilty of this. That's the reason I originally added the workaround.
Created attachment 2985 [details] [review] remove cairo_matrix_compute_eigenvalues slightly saner 2.4 compat. check if EVIOCGRAB works during preinit, and if not assume we're on 2.4. ignore keyboards on 2.4, and only try to grab/ungrab on DEVICE_{ON,OFF} if !2.4.
Created attachment 2986 [details] [review] Patch from Alex Larsson re: comment #30, count the buttons the kernel advertises, and only set those up. pretty sure map is being set up wrong though. either it's a 1-based array, which is why we're never initializing map[32], or it's not and the 2/3 swap is busted.
*** Bug 3636 has been marked as a duplicate of this bug. ***
I'm using the driver with a Logitech MX-510 with 10 buttons, two of which are intended to produce the same event as the wheel (up and down). I've packaged evdev_drv for Fedora Core 4 using the tarball attached above, a diff against the most recent cvs, and the the two patches attached above. Here are the patches i'm applying: evdev-latest-CVS-1.5.patch evdev-Xfuncproto-is-stale.patch evdev-24-compat-1.patch evdev-count-buttons-properly-1.patch xmodmap -pp gives me: [strawman@max SOURCES]$ xmodmap -pp There are 8 pointer buttons defined. Physical Button Button Code 1 1 2 3 3 2 4 4 5 5 6 6 7 7 8 30 [strawman@max SOURCES]$ It seems the extraneous button event I've described in Comment #12 and elsewhere is gone. This is probably because evdev_drv isn't allocating 32 possible buttons as of the evdev-count-buttons-properly-1.patch. All my silly little patches and a src.rpm are here: http://straw.sh.nu/evdev_drv/
(In reply to comment #45) > It seems the extraneous button event I've described in Comment #12 and elsewhere > is gone. This is probably because evdev_drv isn't allocating 32 possible > buttons as of the evdev-count-buttons-properly-1.patch. > > All my silly little patches and a src.rpm are here: > > http://straw.sh.nu/evdev_drv/ If you want to use the last two buttons, you have to disable cruise control. See http://www.linux-gamers.net/modules/wfsection/article.php?articleid=47
Just wanted to throw in that I'd like the EVIOCGRAB fix to only be used on keyboard devices, if it's needed to stop CTRL-C from getting to the terminal; we're using evdevs independent of the X server in a project I'm working on (http://icculus.org/manymouse/), and this causes us trouble...without grabbing, multiple processes can all function fine reading from the same evdevs. Which, of course, I recognize as being part of the problem. :) --ryan.
(In reply to comment #42) > Created an attachment (id=2985) [edit] > evdev-24-compat-1.patch > > slightly saner 2.4 compat. check if EVIOCGRAB works during preinit, and if not > assume we're on 2.4. ignore keyboards on 2.4, and only try to grab/ungrab on > DEVICE_{ON,OFF} if !2.4. applied, along with a cleanup to config/cf/linux.cf to build it by default when a 2.4 kernel is running. i can see the case for allowing the mouse to be used ungrabbed, or even the keyboard really. i'll spin up a patch to add an option for that.
(In reply to comment #46) > (In reply to comment #45) > > It seems the extraneous button event I've described in Comment #12 and elsewhere > > is gone. This is probably because evdev_drv isn't allocating 32 possible > > buttons as of the evdev-count-buttons-properly-1.patch. > > > > All my silly little patches and a src.rpm are here: > > > > http://straw.sh.nu/evdev_drv/ > > If you want to use the last two buttons, you have to disable cruise control. > > See http://www.linux-gamers.net/modules/wfsection/article.php?articleid=47 That tutorial is using mouse_drv, rather than evdev_drv. I did play with lmctl last year, and there are some kernel params (psmouse.smartscroll and others). Using the evdev driver with the smartscroll function disabled, there is no change in the number of buttons enumerated with the evdev-count-buttons-properly-1.patch applied.
Regarding comments 10 and 12, you need to add "SendCoreEvents" to the keyboards in XServerLayout. So, Olivier, your config should read: Section "ServerLayout" ... InputDevice "USBKeyboard" "SendCoreEvents" ... EndSection
I noticed BTN_TASK isn't handled, which results in one of my buttons not working, i opened a new bug with an attached patch for this at bug #3859
component shift
enable smart scrolling via lmctl (http://straw.sh.nu/evdev_drv/lmctl_0.3.2.tar.gz) [lmctl --smss] now they should be working, toke me over 2 days to find that out ;) mfg Benjamin Loschke PS: cause i don't know, how to make i righteous bug-report, anyone who fells like it, can modify it...
I got tired of using "1 3 2 ..." in my xmodmaps for evdev. evdev presses buttons in "event" order, the secondary (#2) being the right button and the tertiary button (#3) the middle button while X and programmes compiled to use the mouse expect "button" order, the order of buttons along the top of the mouse (middle=#2). So, evdev puts in its own mapping to swap the incorrectly mapped buttons (and if one uses an xmodmap of one's own, one must remember to duplicate this). Why not simply "press" the buttons in "button" (instead of "event") order? /* Don't use event order for the secondary (right) and * and tertiary (middle) buttons, but "press" the buttons * in the geomtric "button" order - middle is #2 */ case BTN_LEFT: xf86PostButtonEvent(pInfo->dev, 0, 1, value, 0, 0); break; case BTN_MIDDLE: xf86PostButtonEvent(pInfo->dev, 0, 2, value, 0, 0); break; case BTN_RIGHT: xf86PostButtonEvent(pInfo->dev, 0, 3, value, 0, 0); break; /* Break for button presses 4 5 6 and 7 - * the vertical and horizontal scroll wheels */ case BTN_SIDE: case BTN_EXTRA: case BTN_FORWARD: case BTN_BACK: case BTN_TASK: xf86PostButtonEvent(pInfo->dev, 0, ev.code - BTN_LEFT + 5, value, 0, 0); break; /* The original used an xmodmap swap: * map[2] = 3; * map[3] = 2; */ (In reply to comment #51) > enable smart scrolling via lmctl > (http://straw.sh.nu/evdev_drv/lmctl_0.3.2.tar.gz) [lmctl --smss] now they > should be working, toke me over 2 days to find that out ;) > mfg Benjamin Loschke > > PS: cause i don't know, how to make i righteous bug-report, anyone who fells > like it, can modify it...
(In reply to comment #29) > I've recently noticed some oddness from xmodmap -pp > > There are 32 pointer buttons defined. > > Physical Button > Button Code > 1 1 > 32 148 > > Note the last line. That appears to be a one byte buffer overflow when you set an xmodmap. It appears that if you want 32 buttons, the CARD8 map[] array should have size 33. The loop: for (i = 0; i < ArrayLength(map); i++) map[i] = i; then sets the entries (buttons are indexed from 1 to 32) for the 32 buttons. However, you have to tell the system that it uses arrays of 32 buttons (33 entries for a C array indexed from zero) if (!InitButtonClassDeviceStruct(device, ArrayLength(map)-1, map)) return !Success; "ArrayLength(map)-1" instead of "ArrayLength(map)" (it appears that ButtonClass structure's creation function expects the number of buttons and that the bad value for button 32 you saw above was an overflow - setting an xmodmap entry after the last button - which as #31) ("
(In reply to comment #37) > One more try at a genric udev rule, dropping NAME= since i just want a symlink. > > # Mouse > KERNEL="event*", BUS="usb", SYSFS{product}="*Mouse*", SYMLINK="mouse" What if one is not using udev? My system sets up userland device info in /udev/ (not /dev) (my entry in xorg.conf would reference /udev/input/...) but on boot does not handle event0 (which is the event number used by the mouse when connected directly to the computer - if I use a hub, the number can vary on each boot). I suppose I could run udevstart on each boot - which is rather slow. I decided to do it the old fashioned way, with a couple of lines in /etc/rc.local (I hope the long line does not wrap) mydevice="Logitech USB-PS\/2 Optical Mouse" mylink="mx310" x="`cat /proc/bus/input/devices | sed -n \"/${mydevice}/,/^H:/{/^H:/s/.*\(event[0-9]*\).*/\1/p}\"`" chmod 644 /dev/input/${x} ln -f -s /dev/input/${x} /dev/input/${mylink} Here, I use the device name which appears for my Logitech MX310 mouse in cat /proc/bus/input/devices (as it appears in a "sed" script line, I had to escape the "/" in "PS/2") and set up a link, /dev/input/mx310, pointing to the event# device it uses. The sed command acts silently (-n: only output lines for which a "p", print command, is explicitly given); restricts to the section from the device name (as in $mydevice) through the next line starting with "H:", which for me is "H: Handlers=mouse0 event[varies]" and in that section, for the line starting with "H:", just keep the "event#" ("\1") and output ("p") that (the restriction on the lines to check is so that it does not print out results for every line starting with "H:" that it finds). Any stale link is removed (-f) in creating a symbolic link called "mx310" in /dev/input pointing to that event# device.
Created attachment 3317 [details] [review] evdev-for-6.8.2-3.patch By this patch, you can change your console by Ctrl+Alt+Fn1~12, and shutdown X11 by Ctrl+Alt+Backspace. Changed: 1. Chvt and Shutdown functions. 2. On changing consoles, the file descriptor is closed. (Without this, the driver will catch all events event when you are on virtual terminals) Notes: 1. I've tested this only on Fedora Core 4. 2. Action key bindings are currently hardcoded on the sourcecode.
Created attachment 3318 [details] [review] evdev-for-6.8.2-4.patch 1. Fix the button code produced by 32nd button to be 32. 2. Added "Buttons" options to limit number of buttons. To try it, put it in xorg.conf.
Ryo, could you make a diff against just evdev.c from cvs head? I'd like to try this patch, but i'm using the tarball attached to this bug diffed against cvs head's version.
Created attachment 3335 [details] [review] diff-with-cvs-head.patch Here you are. This is the diff with cvs-head.
Created attachment 3336 [details] [review] diff-with-cvs-head.patch I'm sorry. I've made a mistake in the last patch. Please use the newer one.
Thanks very much, Ryo. I'm testing your patch, and it's working fine so far. I've been begging for the inclusion of Option "Buttons" for this driver for some time. It works well, and I'm happy to finally drop my silly ten button limit hack. One problem remains, however. Without a Buttons statement in xorg.conf, the 32nd button still gets matched with a garbage value. I've tried changing the CARD8 map[] map value to 33 as comment #53 seemed to suggest, but i just end up with 33 possible buttons and a garbage value mapped to button 33.
Created attachment 3345 [details] [review] diff-with-cvs-head.patch I'm sorry, but I haven't noticed that. But I think it's not that serious problem. You can fix that problem just by taking 33 cells for maps and telling X there is 32 buttons, instead of 33. Take a look at my newest patch.
I've tried out the diff-with-cvs-head patch, and I while I think it's user error, I can not find the solution. When I try to compile, I am recieving an error message about not having 'dgaproc.h' available. I've found that file under 'programs/Xserver/Xext/' but how do I have evdev recognize that it is there during the compile? The actual error message: evdev.c:54:21: dgaproc.h: no such file or directory
Do you run "make clean" before applying the patch? I think your Makefile on the directory, which is created automatically before the first build, might wrong. So how about cleanup the build directories, and then apply "diff-with-cvs-head.patch" again?
Created attachment 3672 [details] [review] evdev-zaxis.patch I found that with the Mighty Mouse under linux, the side scrolling wasn't working with the latest off the CVS tree. I found a evtest app that showed side scrolling was from the Z axis (REL_Z). I tried to simply add it as a case to the HWheel, but found it was backwards. I am submitting the above patch which sets the Z axis to be somewhat equivilent to the HWheel axis, but swapped.
(In reply to comment #64) I found someone else has done the same for the MM as well (It seems I'm blind, and can't read a list... :S), anyhow, the patch would be obsoleted as they do the same thing. Perhaps having a 'ZAxisMapping' would be the next logical step, since some mice use the Z axis as a vertical scroll and not horizontal. I'll look into that.
Created attachment 3679 [details] [review] evdev-configure.patch One thing thats always bothered me about this driver is the general lack of configureability. I have added a patch that takes my pre-existing code for the Z axis, and adds xorg.conf configurability to that axis, as well as the Wheel and HWheel axis. Some companies *cough*apple*cough* like to play with standards and change the axis of these to do strange things, so this puts it back into your hands (as this is Open Source). I have left the 4-7 reservation, but theoreticly you can have your axis emulate button 1 or 2. I don't know alot about X, so I mostly took code from the Mouse driver and added it to evdev, but it should be extensible enough that you can use it for other options. Tell me what you think, and if I'm a total idiot... :)
I wonder if evdev really works with keyboard usage, does it? I tried to compile Xorg 7.0 tarball release with evdev included and dirver works just fine for mouse, but I can't force him to work with keyboard. I'm starting X from console and it works but some cursor keys do not, moreover I can't switch keyboard to other layout than international. And there is one thing when I'm trying to shut Xserver down the system is halt dramatically. Why? Is there are some additionals in keyboard usage? Here is the part of my xorg.conf dentifier "Keyboard1" # Driver "kbd" Driver "evdev" Option "Device" "/dev/input/event0" #here is my ps/2 keyboard at the moment Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" Did I miss someting?
Created attachment 4301 [details] Slightly edited version of ajax's manpage
(In reply to comment #67) Please don't change state on bugs unless you know what you're doing. In particular, NEEDINFO is for when we need more information from the reporter to correctly evaluate a bug. > dentifier "Keyboard1" > # Driver "kbd" > Driver "evdev" > Option "Device" "/dev/input/event0" #here is my ps/2 keyboard at the moment > Option "AutoRepeat" "500 30" > Option "XkbRules" "xorg" > Option "XkbModel" "pc105" > Option "XkbLayout" "us" evdev has no xkb support yet. It should work fine for keyboard use otherwise. If this is not the case for you please open a new bug for the issue and set it to block this one.
(In reply to comment #69) > (In reply to comment #67) > > Please don't change state on bugs unless you know what you're doing. In > particular, NEEDINFO is for when we need more information from the reporter to > correctly evaluate a bug. I'm sorry to make a fuss. I'm just a newbe in Bug reports, but I thought that the case when the driver doesn't work correctly is a bug. My case is cursor keys not works, even when I'm turning off xkb options in xorg.conf. And my USB keyboard (wich has two events: multimedia keys - /dev/input/event3 and standart keys - /dev/input/event4) no works totally Kde starts but hangs the video so I can only blind reboot system by pressing Alt+ctrl+F2 and "reboot". Please tell me is it bug? If yes where I have to post it?
Created attachment 4303 [details] [review] Configureation Patch I have made a few changes to my previous configure patch. One thing that bothered me about xmodmap, is that it only seems to map all mice, and not each individually. In this latet iteration, I add a new option: "ButtonMapping" "a=b,b=c". This allows each device to be mapped independently. As well, I have also ensured each axis is reversable, and that all axis are mapped with their own independant Options. I would really apreciate some input a to what you all think.
In our distro there is little integration of X.org and hotplug (hotplug can re- write xorg.conf but that is not ok - i have keyboard languages layout setting there and don't want them to be lost). In X6.9 i had both touchpad(driver: synaptic, alas not in X distribution) and usb mouse reading data from /dev/input/mice In X7 mouse lost its wheel, even xev shown nothing. Strange, while scroll in synaptic still works. I switched mouse to EvDev, whell started to work, but USB mouse needs real HotPlug support, and seems we don't have it. One time i even did not unplugged mouse, but it changed form event2 to event5 misterically :( Are there tools for X.org modules, like insmod/rmmmod/modprobe for kernel modules ? Something i could use from xterm to enable mouse.
Reassign to the new evdev maintainer.
Great so now we have a new evdev maintainer. Welcome :P I have updated my Xorg-6.9 tree with the new evdev driver from the modular Xorg. I also use the XKB support patches. I have two problems: The xkb layout options are incomplete. I can't for example assign group modifiers like "compose:rwin,grp:alts_toggle" Second problem I described in : https://bugs.freedesktop.org/show_bug.cgi?id=5696#c45 That is now marked as resolved, but I am still seeing the same behaviour. Should I redescribe it here, or do I reopen that bug? Thanks for your wonderful work everyone.
(In reply to comment #74) > Great so now we have a new evdev maintainer. Welcome :P > > I have updated my Xorg-6.9 tree with the new evdev driver from the modular Xorg. > I also use the XKB support patches. > > I have two problems: The xkb layout options are incomplete. I can't for example > assign group modifiers like "compose:rwin,grp:alts_toggle" If you could open a new bug with this one, I'll reassign it to someone who knows more about xkb layouts then I do. > > Second problem I described in : > > https://bugs.freedesktop.org/show_bug.cgi?id=5696#c45 > > That is now marked as resolved, but I am still seeing the same behaviour. Should > I redescribe it here, or do I reopen that bug? > > Thanks for your wonderful work everyone. Might as well do a bug dedicated to this one as well, a fresh copy of your xorg.conf and your log file would be useful, along with the contents of /proc/bus/input/devices. Thank you.
Here is the bug related to the PS/2 mice wheels: https://bugs.freedesktop.org/show_bug.cgi?id=5914
Thanks for fixing that bug. Here's another one to keep you busy :P https://bugs.freedesktop.org/show_bug.cgi?id=5950
I get build errors when making evdev. I think errno.h is missing. evdev.c: In function `EvdevReadInput': evdev.c:96: error: `errno' undeclared (first use in this function) evdev.c:96: error: (Each undeclared identifier is reported only once evdev.c:96: error: for each function it appears in.) evdev.c: In function `EvdevProc': evdev.c:178: error: `errno' undeclared (first use in this function) evdev.c: In function `EvdevNew': evdev.c:289: error: `errno' undeclared (first use in this function) make[2]: *** [evdev.lo] Error 1
Created attachment 4701 [details] [review] Edev Errno Patch
Now the only remaining basic problem is the xkb layout options. I can define them in Xorg.conf but they won't show up KDE/GNOME interface. Most probably their own bug.
Given that this was applied ages ago, and has since been superceeded with another version, I'm going to close it so it stops collecting reports that should be their own bugs. :)
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.