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>

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?

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.

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.

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.

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.

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?

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

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.

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 *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.

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.

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.

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

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.