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

[Brian Cully]

Po Lu <luangruo@yahoo.com> writes:

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

        In my context, and the context of many other people, “Input
driver” is very related to the Linux kernel, evdev, and
libinput. Because that is exactly the stack that is in use for
delivering input information to X. I do not think it is useful, in this
discussion, to discuss input drivers in the abstract, because no one
actually uses an abstract input driver. If there are a substantial
number of people with actual driver stacks that don’t match your
expectations, then that cannot be handwaved with “bug”, particularly
when there’s no evidence that the behavior exhibited is contrary to any
specifications.

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

        I can only speak to the behavior I am witnessing today, because
it has only been the last few days since I started looking into the
issue. Whether or not X had a particular behavior in the 90s does not,
in-and-of itself, mean it will continue to have that behavior today. The
computing landscape is immensely different, as you point out. One major
difference is that most input devices in the mid 90s, and before, were
not self-describing, but expected to be configured by users.

        In that context, especially because users were also responsible
for *naming* devices, using a name makes more sense.

        But that context is long gone for most of us. Even embedded
host devices query USB devices for their capabilities.

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

        libinput classifies devices based on these tables (by way of
evdev, by way of the kernel). X uses them for simple classification. But
X also doesn’t apparently expose joysticks, either (my Steam Controller
has a joystick interface that failed to show up in ‘xinput list’). Does
that mean Emacs shouldn’t use them? If Emacs is required to use only the
information delivered by way of X, then there are large swathes of
devices it cannot use.

        I am aware of the joystick driver, but have not used it. From
what I can tell it converts joystick movement into mouse movement, which
explicitly defeats using it properly as a joystick by
applications. That’s why it’s not included by default in most Linux
distributions.

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

        It does have the event device path, however, which can be used
to query capabilities.

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

        I contend that my input driver stack, from the kernel, through
evdev, through libinput, and into X is not buggy, but in fact,
normative. Yet this stack will, trivially, produce identical device
names for separate physical devices.

        Furthermore, I contend that this is completely acceptable. That
nothing in this stack has any problem with this situation, and that
nothing, even X itself, has any problem disambiguating events from any
device, no matter how they are named.

        If there are applications that use device names under the
expectation that they be unique, then I contend that is a bug in those
applications, because there is nothing I have found, in spite of a great
deal of searching, that appears to make this claim, and you have also
provided none when directly asked.

        There is no code that I can find that would accommodate this
feature.

        And, furthermore, there is no reason for this feature to exist
in the modern era -- and I define modern pretty loosely here, X has had
USB support longer than it hasn’t, at this point in time.

        Devices are designed to describe their abilities with enough
clarity that they can be used, as expected, with no user intervention
what-so-ever, with no care at all given to any possible identifiers,
including, but not limited to: model, manufacturer, VID, PID, device ID,
serial number, and name (barring, of course, vendor-specific
extensions). This modern sensibility is reflected in the driver stack.

        A user is, of course, allowed to customize their device based on
any feature of it they want; it’s their computer after all. They can
even use the output of /dev/random if they so desire. But it is *not* a
feature of X that they may expect the device name to be a unique
identifier, and it should not be communicated to them as such.

        I have done all I can to show that X does not guarantee unique
device names, from abstract rational argument to trawling the actual
code in use, to creating custom devices, to finding duplicate,
mass-manufactured devices. And while absence of evidence is not evidence
of absence, I believe there is enough weight behind my research to show
my claim to be correct. The onus is on you to prove the opposite, which
is far easier, in that it is at least logically possible: that X has a
guarantee of unique device names. Please show me where that claim is
made in official documentation, and I will cede that the current
behavior is a bug.

-bjc