This looks to be a completely different issue: 
   (II) event9: opening input device '/dev/input/event9' failed (No such device).

First, we can't use your patch though because that would side-step logind and will break any such setup. That's... less than ideal ;)

What libinput does in the path interface is: take the path, create a udev device for it, then use the devnode provided by udev to open it. This is a bit roundabout but an effect of the path interface being the secondary interface after the udev interface used by wayland compositors.

That's where it falls apart in xf86-..libinput because the Option Device node is different to the udev-returned node. The correct fix here would be to resemble what libinput does: in PreInit, create a udev device from the device path, get the device node from the udev device and store that in the pInfo->options under some _libinput prefix. Then look up both the Device option and the special option we just stored for matching during open_restricted().

Alas, this is a lot of effort for no real gain. In your case, you can achieve the same result by changing your config to:

Section "InputClass"
  Identifier  "keyboard0"
  Driver      "libinput"
  MatchProduct "GASIA PS2toUSB Adapter"
  ...
EndSection

With the advantage that this also works when you hotplug the device. These days, any Section InputDevice is usually a bug in waiting, there are very few use-cases where it still makes sense. And by "these days" I mean since roughly 2008, so we're definitely not bleeding edge here.

> ps. the bug was also independently discovered here, in 2009:
> https://forums.gentoo.org/viewtopic-t-725843-start-0.html

That would predate libinput by 4 years, I doubt it's the same bug ;)


I'm closing this bug because it's a niche use-case and can be fixed with a config option adjustment so it's not worth the effort of putting extra bits into the driver. And that config option is an improvement over the legacy option as well. Please re-open if that's not suitable or cannot work for some reason, then we can discuss it further.

For the archives, this is now noted in the man page

commit 0d4b50fd6e200cb8b720ee0b917b882d2d03542b
Author: Peter Hutterer <>
Date:   Mon Mar 19 10:00:59 2018 +1000

     man: note that we don't do /dev/input/by-id or /dev/input/by-path

Hello Peter,
I did it as you suggested - I've created a "InputClass" section instead of "InputDevice" but it doesn't work:

The error was:
"Undefined InputDevice "keyboard0" referenced by ServerLayout "Default Layout""

Then I disabled the lines in [ServerLayout]:
InputDevice "keyboard0" "CoreKeyboard" and
InputDevice "mouse0" "CorePointer"

and X starts, but without any pointer and keyboard :(

Please keep in mind that I have:
    Option "AutoAddGPU" "false"
    Option "AutoAddDevices" "false"

I need this becasue I am running two Xorg instances at the same time and I need to specify manually which devices belongs to which Xorg instance - therefore I was doing it with "InputDevice" sections. Will it work with "InputClass" instead?

oh, right. If you have Option "AutoAddDevices" "false", then this cannot work because the InputClass code is never triggered. I'd suggest to use the MatchSeat directive and assign the udev property ID_SEAT to the device. You'll also have to start X with the -seat option but from a quick skim of the code this should mean you can get rid of the AutoAdd* options and thus get the benefits of hotplugging. Provided the drm device also has the ID_SEAT tag assigned correctly. Note: I haven't done this myself but the code is there, so presumably it works ;)