Bug 968

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. :)