evdev mouse fails on hardy: cannot open input pEvdev

[Mikael Nilsson]

Binary package hint: xserver-xorg-input-evdev

I have a Logitech MX revolution mouse, and the only way to get all buttons to work is by adding the following to xorg.conf:

Section "InputDevice"
        Identifier "Configured Mouse"
        Driver "evdev"
        Option "evBits" "+1-2"
        Option "keyBits" "~272-287"
        Option "relBits" "~0-2 ~6 ~8"
EndSection

(as per the evdev manpage and README)

This worked well in Gutsy. I just upgraded to hardy, and my mouse no longer works. I get the following in the log:

(EE) Configured Mouse: cannot open input pEvdev
(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "Configured Mouse"

[Mikael Nilsson (mini)]

I think the bug in Debian is the same.

[Timo Aaltonen (tjaalton)]

Yep, upstream seems to think that input-hotplug is the only proper way to use evdev. That's going to happen later in the hardy timeframe.

[Mikael Nilsson (mini)]

On tis, 2007-12-04 at 08:22 +0000, Timo Aaltonen wrote:
> Yep, upstream seems to think that input-hotplug is the only proper way
> to use evdev. That's going to happen later in the hardy timeframe.

Yes, evdev is awkward to configure manually. What component is missing
in Hardy for hotplug to work?

/Mikael

[Timo Aaltonen (tjaalton)]

You can test it by copying /usr/share/doc/hal/examples/10-x11-input.fdi to /etc/hal/fdi/policy.

What's missing is a way to make it use the correct keymap automatically without editing any fdi file or such.

btw, this bug apparently is just due to misconfiguration with the new evdev. The problem is that there is no documentation for doing it the right way.

[Mikael Nilsson (mini)]

On mån, 2007-12-24 at 08:23 +0000, Timo Aaltonen wrote:
> You can test it by copying /usr/share/doc/hal/examples/10-x11-input.fdi
> to /etc/hal/fdi/policy.

Nice! Works well here.

I had my buttons configured manually anyway, using xbindkey, and adding
that file and re-plugging the mouse made all of them work as before!

/Mikael

>
> What's missing is a way to make it use the correct keymap automatically
> without editing any fdi file or such.
>
> btw, this bug apparently is just due to misconfiguration with the new
> evdev. The problem is that there is no documentation for doing it the
> right way.
>
--
<email address hidden>

Plus ça change, plus c'est la même chose

[kiev1 (sys-sys-admin)]

I have the same bug!!!

[kiev1 (sys-sys-admin)]

copying /usr/share/doc/hal/examples/10-x11-input.fdi to /etc/hal/fdi/policy not work

[Mikael Nilsson (mini)]

You also need to remove the evdev section in xorg.conf

/Mikael

tor 2008-01-31 klockan 16:36 +0000 skrev kiev1:
> copying /usr/share/doc/hal/examples/10-x11-input.fdi to
> /etc/hal/fdi/policy not work
>
--
<email address hidden>

Plus ça change, plus c'est la même chose
>

[kiev1 (sys-sys-admin)]

I fully deleted the section:
Section "InputDevice"
        Identifier "Configured Mouse"
        Driver "evdev"
...

and deleted the string - InputDevice "Configured Mouse" "CorePointer" from Section "ServerLayout"

however and not works, show please example of working xorg.conf

[kiev1 (sys-sys-admin)]

Yes - work (...I forgot to install xvkbd):
Section "InputDevice"
        Identifier "Configured Mouse"
# Driver "evdev"
Option "Protocol" "Auto"
Driver "mouse"
        Option "SendCoreEvents"
        Option "CorePointer"
        Option "Name" "A4Tech PS/2+USB Mouse"
        Option "Resolution" "1000"
Option "Buttons" "9"
EndSection

and:

$ cat /etc/hal/fdi/policy/10-x11-input.fdi

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <!-- FIXME: Support tablets too. -->
    <match key="info.capabilities" contains="input.mouse">
      <merge key="input.x11_driver" type="string">mouse</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.x11_driver" type="string">evdev</merge>
      </match>
    </match>
  </device>
</deviceinfo>

work

[Benjamin Kudria (bkudria)]

I was able to get it working with this workaround, however, a number of buttons for my mouse (Logitech MX Revolution) have stopped showing up in xev. specifically, it does not detect wheel left and wheel right, secondary wheel scroll up or down, and secondary wheel click. Is there any way to get these working again?

[Oli (oli)]

Just because nobody has mentioned it, I thought I would:

btnx is an amazing replacement for all this nonsensical evdev tomfoolery. It's easy to configure via gui, live (no restarts) and has profile management.

[laga (laga)]

I was also caught by this "bug" and i managed to make it work by copying the .fdi to /etc/hal/fdi/policy and changing the "Driver "evdev"" entries back to "kbd" or "mouse". It's a shame that there's no backwards compatibility, though. It's a bit annoying not to be able to login in kdm because they keyboard is dead.

[laga (laga)]

Okay, the above solution didn't work well with my multiseat setup. After enabling the second X server in /etc/kde3/kdm/kdmrc, the mouse pointer and the keyboard were frozen again in :0. Finally, I found out that just removing the .fdi file and removing all InputDevice entries in xorg.conf works just fine. Before that, both X servers were trying to access the same devices.

Of course, my current solution only works for people who don't need input devices on their second X server. In my case, that's fine because it's just my TV on an additional VGA card.

Is it possible to prevent X from grabbing input devices which are already in use? Is it possible to assign input devices to X servers *and* have input hotplugging? Right now, it seems a bit limited and the lack of documentation (man evdev is outdated, for example) is not exactly helping.

[laga (laga)]

I've found that it's still possible to tell the evdev driver which device he should use. This entry works for me:

Section "InputDevice"
    Identifier "dmouse"
    Driver "evdev"
    Option "Device" "/dev/input/by-id/usb-04d9_1400-event-mouse"
EndSection

Regards,

Michael

[Rotbart van Dainig (rotbart-van-dainig)]

So basically, upstream went nuts and threw away most of the configuration options that made evdev so interesting.

Great.

[Paulo J. S. Silva (pjssilva)]

Is there anyone here being able to use evdev to control two independent sets of keyboard+mouse (for a multi-seat setup)?

I have a 2 seat setup that has been working for a year now. Since I have two video-cards I basicully run two X sessions. I used evdev to control the input devices. Now, I could manage to get evdev controlling the devices by copying the 10-x11-input.fdi to the right location. Now, with the attached xorg.conf file I can manage to get the two X sessions up, but both keyboards and mouse are attached to just one of them (even though the xorg.conf file make it explicitly that this should not be the case). Note that if I run only one session a time then only the correct set of keyboard and mouse can control the correct xsession.

Looking at the /var/log/Xorg.?.log I can see messages like this:

(II) Mouse.0: Unable to grab pEvdev (Device or resource busy). Cowardly refusing to check use as keyboard.

So it looks like the first evdev driver is not being able to read to each device independently. Wasn't it supposed to be able to do just that? Note that I am using the Device option described by Michael to make sure that evdev can see each device.

Is there a work around?

[Michael Tinsay (tinsami1)]

I have several machines with 2- or 3-seat configuration. I've posted how I managed to do this in Gutsy at http://www.michaeltinsay.com/?q=Multiseat-Gutsy-Xephyr

HTH

--- mike t.

----- Original Message ----
> From: Paulo J. S. Silva <email address hidden>
> To: <email address hidden>
> Sent: Sunday, March 23, 2008 11:28:46
> Subject: [Bug 173833] Re: evdev mouse fails on hardy: cannot open input pEvdev
>
> Is there anyone here being able to use evdev to control two independent
> sets of keyboard+mouse (for a multi-seat setup)?
>

[Paulo J. S. Silva (pjssilva)]

Mike... I had multiseat working in Gutsy too. But it stopped working in hardy with the new evdev.

I have found a solution to mine problem (for a 2 seat configuration at least):

1) I had to add the line

        Option "AutoAddDevices" "no"

to the first first ServerLayout section. This precludes this server to grab all devices in advance. Note that this options was not necessary under feisty, it is only needed in hardy. You may also add

        Option "AutoEnableDevices" "no"

but it doesn't change anything.

2) When the second server kicks in it fails to configure its keyboard and mouse even though the configuration file looks right to me (the configuration file is attached). The log shows:

(**) Option "CoreKeyboard"
(**) Keyboard.1: always reports core events
(EE) Keyboard.1: cannot open input pEvdev
(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "Keyboard.1"
(**) Option "CorePointer"
(**) Mouse.1: always reports core events
(EE) Mouse.1: cannot open input pEvdev
(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "Mouse.1"

So it seems that the first server has some exclusive access to the evdev device (which shouldn't happen).

3) But, as my second server tries to automatically add devices (I doesn't have the option AutoAddDevices set to no), it can get access to the second keyboard and mouse.

4) The only problem, is that the second keyboard is not being added from the configuration file, so the system doesn't know the correct options to handle a ABNT2 (Brazilian) keyboard. I had to edit the 10-x11-input.fdi file to make hal pass the correct options to the auto-configuration system. The edited file is attached in the next message for reference.

The behavior descried by 2, 3 and 4 above doesn't seem right. I would expected that the second server should get its keyboard and mouse just like the first one, including reading the keyboard options from the xorg.conf file. This looks like a bug in the new evdev to me. Should I file a bug report?

[Paulo J. S. Silva (pjssilva)]

You can find attached the 10-x11-input.fdi file edited to load the options for a Brazilian keyboard as cited above.

[Michael Tinsay (tinsami1)]

Hello Paulo,

In the PC's I have set up multiseat, I used udev rules to fix the /dev/input/event[0-9]+ names of the keyboards and mice. Have you tried doing this? The error '(EE) PreInit returned NULL for "xxxx"' can be caused by not using the assigned event names or by using symlinks (e.g. /dev/input/by-path/<symlinks>).

--- mike t.

----- Original Message ----
> From: Paulo J. S. Silva <email address hidden>
> To: <email address hidden>
> Sent: Monday, March 24, 2008 21:58:20
> Subject: [Bug 173833] Re: evdev mouse fails on hardy: cannot open input pEvdev
>
> Mike... I had multiseat working in Gutsy too. But it stopped working in
> hardy with the new evdev.
>
> I have found a solution to mine problem (for a 2 seat configuration at
> least):
>
> 1) I had to add the line
>
> Option "AutoAddDevices" "no"
>
> to the first first ServerLayout section. This precludes this server to
> grab all devices in advance. Note that this options was not necessary
> under feisty, it is only needed in hardy. You may also add
>
> Option "AutoEnableDevices" "no"
>
> but it doesn't change anything.
>
> 2) When the second server kicks in it fails to configure its keyboard
> and mouse even though the configuration file looks right to me (the
> configuration file is attached). The log shows:
>
> (**) Option "CoreKeyboard"
> (**) Keyboard.1: always reports core events
> (EE) Keyboard.1: cannot open input pEvdev
> (II) UnloadModule: "evdev"
> (EE) PreInit returned NULL for "Keyboard.1"
> (**) Option "CorePointer"
> (**) Mouse.1: always reports core events
> (EE) Mouse.1: cannot open input pEvdev
> (II) UnloadModule: "evdev"
> (EE) PreInit returned NULL for "Mouse.1"
>
> So it seems that the first server has some exclusive access to the evdev
> device (which shouldn't happen).
>
> 3) But, as my second server tries to automatically add devices (I
> doesn't have the option AutoAddDevices set to no), it can get access to
> the second keyboard and mouse.
>
> 4) The only problem, is that the second keyboard is not being added from
> the configuration file, so the system doesn't know the correct options
> to handle a ABNT2 (Brazilian) keyboard. I had to edit the
> 10-x11-input.fdi file to make hal pass the correct options to the auto-
> configuration system. The edited file is attached in the next message
> for reference.
>
> The behavior descried by 2, 3 and 4 above doesn't seem right. I would
> expected that the second server should get its keyboard and mouse just
> like the first one, including reading the keyboard options from the
> xorg.conf file. This looks like a bug in the new evdev to me. Should I
> file a bug report?
>
>
> ** Attachment added: "xorg.conf"
> http://launchpadlibrarian.net/12839640/xorg.conf
>
> --
> evdev mouse fails on hardy: cannot open input pEvdev
> https://bugs.launchpad.net/bugs/173833
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Paulo J. S. Silva (pjssilva)]

Good call Michael!

Using your trick of creating special udev rules works well. Hence, it seems that the new evdev does not plays nice with symbolic links as suggested by Iaga in comment 15 above and my other posts I saw on the internet. In my case it worked with the serial keyboard and mouse (that were used by the first xserver), but failed with the usb set.

Thanks.

[Jeremy Nickurak (nickurak)]

Don't suppose there's any way to get thu ButtonMapping option from evdev working, either with an fdi file or an xorg.conf entry pointing at a udev-generated device file?

[Pär Lindfors (paran)]

This bug is caused by an configuration change that is undocumented, the man page contains options that are no longer valid. This is made worse by the fact that the error message is very unclear.

Both problems are resolved in upstream git (freedesktop.org, not debian).

The Debian package is also mainained in git, which makes me a bit unsure of how to submit a patch for this. I guess I should do it the "git way" and not submit a normal debdiff here?

My proposed solution is to simply cherry pick 7f1e8146d4b13929a86a4b80f783a720c1b5573a and 11cf9c92c0d31d1058ec6c013b7126bd8909beba from freedesktop. Those two commits contain improved error messages, and an updated man page.

This is how I did this locally:
git clone git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-input-evdev
git remote add xorg git://anongit.freedesktop.org/git/xorg/driver/xf86-input-evdev
git fetch xorg
git-cherry-pick 7f1e8146d4b13929a86a4b80f783a720c1b5573a
git-cherry-pick 11cf9c92c0d31d1058ec6c013b7126bd8909beba

I then verified that the package still builds ok, the man-page is updated, and when using an old xorg.conf Xorg.0.log now contains "No Device specified." instead of "cannot open input pEvdev".

[Dana Goyette (danagoyette)]

Do the /dev/input/by-id symlinks still work? If so, a better message would be the following:

"$IDENTIFIER: The 'Name' option has been removed in the transition to Input Hotplug; please use 'Device' instead."

($IDENTIFIER is from xorg.conf.)

[Mario Limonciello (superm1)]

This is *very* bad for me that the configuration option for by "Name" is gone. w/ an Apple BT mouse, I don't have a nice symlink created for me ever. I'm not sure how I'll ever be able to give it a 'Device' name.

[Michael Tinsay (tinsami1)]

----- Original Message ----
> From: Mario Limonciello <email address hidden>
> To: <email address hidden>
> Sent: Sunday, March 30, 2008 4:11:13
> Subject: [Bug 173833] Re: evdev mouse fails on hardy: cannot open input pEvdev
>
> This is *very* bad for me that the configuration option for by "Name" is
> gone. w/ an Apple BT mouse, I don't have a nice symlink created for me
> ever. I'm not sure how I'll ever be able to give it a 'Device' name.
>

Use udev rules to create your own device names for evdev to use. My notes can be read from http://www.michaeltinsay.com/index.php?q=udev-Xephyr-evdev

[sibidiba (sibidiba)]

The device names are not the only problem. It seems evdev support is broken in the current X.org:
Even if I get my mouse working with evdev, it is also recognized by the xorg-input infrastructure, so all events are received double. And the xorg-input drivers do not recognize a couple of buttons correctly.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xserver-xorg-input-evdev - 1:1.2.0-1ubuntu1

---------------
xserver-xorg-input-evdev (1:1.2.0-1ubuntu1) hardy; urgency=low

  * 100_fix_b_map_data:
    Initialise b_map_data to correct size. (fdo: #13991)
  * 101_fix_error_message.diff:
    More accurate error messages on device open fail.
  * 102_update_manpage.diff:
    Updated manpage to reflect current state (LP: #173833)
  * 103_default_xkb_rule.diff:
    Fix the default XKB rules to be "base" instead of "xfree86".
  * 104_force_xkb_model.diff:
    Force xkb_model to be "evdev". Things can only break if something else
    is used.

 -- Timo Aaltonen <email address hidden> Sun, 30 Mar 2008 18:32:41 +0300

[Jeremy Nickurak (nickurak)]

Gabor: The problem you're describing seems to be a different bug than what this report discusses. I'd suggest you file it seperately.

[Michael Monreal (mimox)]

Can someone please paste a working sample for a evdev mouse section in xorg.conf? I still get this:

**) Mouse1: always reports core events
(II) Mouse1: Found 3 relative axes.
(II) Mouse1: Configuring as pointer.
(II) Mouse1: Found 8 mouse buttons
(II) Mouse1: Configured 11 mouse buttons.
(WW) <default pointer>: No Device specified, looking for one...
(II) <default pointer>: Setting Device option to "/dev/input/mice"
(--) <default pointer>: Device: "/dev/input/mice"
(==) <default pointer>: Protocol: "Auto"
(**) Option "CorePointer"
(**) <default pointer>: always reports core events
(==) <default pointer>: Emulate3Buttons, Emulate3Timeout: 50
(**) <default pointer>: ZAxisMapping: buttons 4 and 5
(**) <default pointer>: Buttons: 9
(**) <default pointer>: Sensitivity: 1
(**) Option "CoreKeyboard"
(**) Keyboard0: always reports core events
(**) Option "Protocol" "standard"
(**) Keyboard0: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Keyboard0: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) Keyboard0: XkbModel: "pc105"
(**) Option "XkbLayout" "de"
(**) Keyboard0: XkbLayout: "de"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(II) evaluating device (Keyboard0)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(II) evaluating device (<default pointer>)
(II) XINPUT: Adding extended input device "<default pointer>" (type: MOUSE)
(II) evaluating device (Mouse1)
(II) XINPUT: Adding extended input device "Mouse1" (type: MOUSE)
(II) evaluating device (Keyboard0)
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(**) Mouse1: 2 valuators.
(**) Mouse1: Configuring in Absolute mode.
(**) Mouse1: Registering 11 buttons.
(II) Mouse1: Init
(--) <default pointer>: PnP-detected protocol: "ExplorerPS/2"
(II) <default pointer>: ps2EnableDataReporting: succeeded
(II) Mouse1: On

So the mouse reverts to use the old mouse driver. My current entry (as hinted by the man page):

Section "InputDevice"
        Identifier "Mouse1"
        Driver "evdev"
        Option "Device" "/dev/input/by-path/pci-0000:00:0b.0-usb-0:4:1.0-event-mouse"
EndSection

[Paulo J. S. Silva (pjssilva)]

As already mentioned by Michael above you should not use the /dev/input/by-path link, you are supposed to use the
/dev/input/inputXX special file that is not a link. If you want to make sure that a specific mouse gets a specific name in /dev/input you need to create a udev rule (changing the /etc/udev/rules.d/20-names.rules file). I attach my file for an example, but you can also read more details in Michael post ant the linked page where he explains his multi-seat install.

In my file the first keyboard becomes /dev/input/mskbd0 (from multi-seat keyboard 0). Hence I use:

        Option "Device" "/dev/input/mskbd0"

in the respective keyboard section.

Repeating, don't use the by-path or the by-id link. At least for me, it doesn't work.

[Pär Lindfors (paran)]

> Repeating, don't use the by-path or the by-id link. At least for me, it doesn't work.

Then you should report a separate bug because of course they should work. Here is a part of my xorg.conf that is working in latest Hardy:

Section "InputDevice"
        Identifier "microsoft-kbd"
        Driver "evdev"
        Option "CoreKeyboard"
        Option "Device" "/dev/input/by-id/usb-Microsoft_Comfort_Curve_Keyboard_2000-event-kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "evdev"
        Option "XkbLayout" "se"
EndSection

Section "InputDevice"
        Identifier "Das Keyboard"
        Driver "evdev"
        Option "CoreKeyboard"
        Option "Device" "/dev/input/by-id/usb-046a_Das_Keyboard-event-kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "evdev"
        Option "XkbLayout" "se"
EndSection

Section "InputDevice"
        Identifier "LogitechMouse"
        Driver "evdev"
        Option "CorePointer"
        Option "SendCoreEvents" "true"
        Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse"
EndSection

[Paulo J. S. Silva (pjssilva)]

I have just checked here. With the new xorg packages I can use the /dev/input/by-id entry but not the
/dev/input/by-path entry. (I have a serial keyboard and mouse and another USB set). The error I get in the log file is the same described in comment <a href=https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/173833/comments/19>#19</a> above.

The new manual page uses the /dev/input/by-path entry in the example. So this look like a bug. Can anyone confirm this?

[drewp (drewp)]

Related trouble with evdev and mouse model A4 Tech SWOP-80PU8. I eventually went with this config:

Section "InputDevice"
    Identifier "Mouse0"
    Driver "mouse"
    Option "Buttons" "10"
    Option "Name" "A4 Tech USB Laser Mouse"
    Option "Protocol" "auto"
    Option "Device" "/dev/input/by-id/usb-A4Tech_USB_Optical_Mouse-event-mouse"
EndSection

and used btnx to map the extra buttons to keys. btnx doesn't work very well-- I get some stray button-8 presses along with my various key events, and btnx sometimes sends the keypress/release of the modifiers outside the press/release of the primary key :(.

[Michał Gołębiowski-Owczarek (mgol)]

Using "mouse" driver would be enough for me if it recognized all buttons of my mouse well. I've got Logitech MX310 and it has one special button, in MS Windows used as application changer (a replacement for Alt+Tab). Evdev recognizes it properly, whereas "mouse" driver thinks it's the same as middle button. Therefore I can assign only 5 functions to my 6 buttons.

That is why I tried evdev, but I cannot make it support hotplugging in Ubuntu and it's something critical for me.