Bug 5696

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.