Re: master 3b41141708: Expose the name of an event's input device to Lisp

[Po Lu]

Brian Cully <bjc@spork.org> writes:

>       I do not understand why libinput would show one device name, yet
> X shows another for you. From what I can tell, there is a direct chain
> of unmodified names that goes all the way from the kernel, through
> evdev, through libinput, and up to X.

Well, no.

>       My input driver is bog standard. Why do you claim there is a
> bug? Is it documented somewhere that the kernel, evdev, or libinput will
> present unique names? I have not found such documentation, and I have
> found a number of code paths that make no effort at all at making names
> unique.

"Input driver" is not at all related to the Linux kernel, evdev, or
libinput.  It means a driver for the X server.

The X server must produce unique names for each device.  That task is
delegated to the device-dependent layer (in this case,
xf86-input-libinput.)

The input extension has provided unique names for each device since its
adoption by most X vendors in the early 1990s, before Linux, evdev, HID
devices, Bluetooth and Steam controllers even existed.  It has also
never provided any more information such as serial numbers and
"bluetooth IDs", since they are not reasonably portable, and did not
even exist when the input extension was first designed.  There was once
a separately specified "input class", but that died alongside the X
Consortium, and is no longer present in version 2 of the input
extension.

Hotplugging is also a new feature on X.  Before that, people configured
input devices manually, and the X server did not allow you to have
multiple devices with the same name.

Also, X to this day runs on many kernels other than Linux.  Each with
their own supported devices, each with their own mechanisms for
retrieving information from devices.  This is why it does not expose any
Linux, or Solaris, or MS Windows, or VMS specific concepts related to
"input device" anywhere.

>       We may have different definitions of “self describing” happening
> here. Joysticks and Gamepads have explicit usage IDs in the Generic
> Desktop Page of the HID Usage Tables. While they present relative motion
> like other devices, they are tagged by the USB in order to differentiate
> them.

Please tell me how Emacs can obtain the "explicit usage ID" from the
"Generic Desktop Page" of the "HID Usage Tables" from the X server,
which does not expose any USB or other low-level device information to
Emacs and other clients.

>       Most of the commonly used devices have usage table definitions
> which adequately describe how they function. But of course there is a
> limit to what is even possible to describe automatically without user
> intervention. Foot pedals are a good example; they tend to have unique
> uses based on their users, and as a result their users are expected to
> configure them. It is reasonable for Emacs to do this.
>
>       However, what happens when you plug in two pedals of the same
> make and model and they have the same name? You say this is a bug, and
> that I lose, but I need to see *why* that’s a bug. In the mean time,
> there are other identifiers I might be able to use other than the name,
> like the serial number, or Bluetooth device ID, why should those be off
> limits to my ability to configure them in Emacs?

Because the X server does not provide the serial number, Bluetooth
device ID, it only provides the name, which has always been unique to
each device.

>       I would suggest, if we go this route, that the device comes with
> more information than a name, or can at least be probed, so that I can
> determine which information to use, such as the serial number.

The X server does not provide any of that information.

>       My point is that it is not just okay to have a device named the
> same thing with multiple functions (indeed, that is how a tremendous
> number of devices work), but that it is also okay for them to have the
> same name with the same functions, because the name is meant for human
> consumption and not computer algorithms.

The name is meant for the consumption of any program which needs a way
to permanently refer to a device.  It always has, it always will be, and
if there is a buggy input driver, X clients and users lose.