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

[Po Lu]

Brian Cully <bjc@spork.org> writes:

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

But I am not interested in what the Linux kernel, evdev and libinput
expose.  Emacs cannot use their information when running under X.

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

The protocol does not by design allow for there to be multiple devices
of the same use (master pointer, master keyboard, slave pointer, slave
keyboard, floating slave) with the same name.  The behavior you are
witnessing deviates from the established behavior of the X input
extension, that you try to justify it with "that's what Linux does" is
irrelevant.

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

Your Steam Controller's joystick is exposed as extra valuators inside
the pointer device.  The motion is sent as normal Motion extension
events with those valuators changed by the X server.  Emacs knows
nothing about the special-ness of those valuators, unless it knows its
name.

And FTR, Emacs is required to only use information delivered by X, for
the simple fact that there is no information delivered by anything else.

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

The device path is only exposed by the libinput (or evdev) drivers
through driver-specific device properties.  Trying to use those
properties is IMNSHO suicidial: they change at random and are not
guaranteed to be present everywhere.  And what if Emacs is connected to
a remote X server, or the device information cannot be queried due to a
lack of permissions to open that device file, or the device information
is simply incorrect?

If we are going to use those properties, we might as well drop X Windows
support altogether, and make Emacs use libinput directly for input,
because what you are proposing defeats the entire point of X's
client-server architecture.

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

Then this stack is buggy.  I don't care what the Linux kernel does, what
evdev does, etc.  The X input extension is supposed to produce unique
names for each device, that it does not do so points to a bug somewhere
in the stack.

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

Nonsense.  I will not try to argue this with you further, since you
simply don't understand or have never worked with anything other than a
GNU/Linux system running the latest release of the X.Org server.

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

I already told you: the X server(s) never did let you configure devices
manually, in your XF86Config file, with the same names.  And my input
devices show up with different names.

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

X does not support USB at all, or PS/2, or ADB, or any other hardware
interface directly.  It is a network protocol that abstracts above all
of these details.

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

That is simply nonsense.  As I have repeated for many times over and
over again, the X server does not tell us what the model, manufacturer,
VID, PID, serial number are.  Those concepts do not even exist on some
of the systems on which X servers run.  And Emacs supports almost any X
server in existence, from ancient versions of Xsun to the latest release
of X.org, and to other servers written in Java that run as a browser
applet.

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

It is long-standing behavior of the X input extension.

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

The "official" documentation and guarantees died alongside the X
Consortium.  But the assumption is made by many tools, including (as I
previously demonstrated) the xinput tool itself.

Anyway, if you want to incorporate the serial number and USB identifiers
into the classifications and names of input devices in Emacs, show us
the code, and it working with every X server on at least the Unix-like
platforms we currently support.

Otherwise, the discussion ends here.  I will not waste more time
debating the implementation of a feature that cannot be implemented.