emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Brian Cully
Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp
Date: Mon, 11 Apr 2022 00:11:48 -0400
User-agent: mu4e 1.6.10; emacs 29.0.50

Po Lu <luangruo@yahoo.com> writes:

> libinput in most cases gets its information from evdev.  What the kernel
> driver exposing the evdev device does is outside its scope.

        From what I can tell it seems like in all cases it gets its
information from evdev, which in turn gets its information from an ioctl
call.

>>      I am at a loss, then. I do not know why libinput would choose to
>> give your devices unique names but not mine. Does the “Device” line of
>> ‘libinput list-devices’ also show unique names?
>
> It does not.

        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.

> That's a bug in the input driver.  If the input driver works correctly,
> then that will be possible.  If not (like in your case), you lose,
> sorry, but there is no way to fix that problem.  IOW, the devices are
> uniquely named, but from the point of view of Emacs the input driver is
> reporting two devices as a single device.

        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.

> And as I already explained, devices are nowhere close to self-describing
> in their capabilities.  Joysticks send motion events, foot pedals send
> keyboard events, and so on and so forth.

        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.

        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?

        I think names can be useful, but names are not, by themselves,
an adequate solution. I can, seemingly without effort, create name
collisions on a standard Manjaro install. At this point I’m pretty
certain I could do it on any popular Linux distribution.

> It's the only reliable way to do that.  What else would you suggest?

        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.

>> prefix the device name with 'pointer:' or 'keyboard:' as appropriate.
>
> This message sort of demonstrates my point.  It is OK for there to be a
> pointer and a keyboard extension device with the same name, because they
> are the same device sending both motion and keyboard events.  But it is
> not correct for there to be more than one physical device with the same
> name.

        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.

-bjc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]