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 12:26:53 -0400
User-agent: mu4e 1.6.10; emacs 29.0.50

Po Lu <luangruo@yahoo.com> writes:

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

        It seems to me that part of our disagreement stems from having
approached this problem from two different directions: you are looking
at it from the perspective of an X client, and trying to use the
information available to you in that context to design a feature. I have
been looking at it from the perspective of someone who makes input
devices, and looking at what is possible from that end.

        Unfortunately, in the middle we seem to have hit a snag in terms
of expectations around device naming.

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

        These are fair points. I do not have a way to resolve them
within the scope of a pure X client.

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

        Please do not resort to ad hominem. You do not know my
history. I, too, remember a time of hand coding XF86Config in the 90s,
and I am thankful to be long past that. And, frankly, recollections of how
things worked a quarter century ago are not particularly relevant in the
face of contradictory evidence of how things work now.

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

        It may have been long-standing in the past, but it does not
stand today. No one uses MIT X11 anymore. Almost no one uses
XFree86. Sun Microsystems has been gone for over a decade, and ceased to
be a particularly relevant X environment many years before that. XQuartz
borrows heavily from X.Org. Like it or not, X.Org is the de facto
standard.

        If you are using Emacs under X, the odds are very much in favor
of that being on a Linux kernel, using evdev, libinput, and X.Org.

        I am, by no means, suggesting abandoning support for other
platforms, I am stating that you cannot ignore the behavior of the
platform that is most in use because of a perceived bug on your part.

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

        I have never claimed to have a solution. At previous points I
have said that I don’t think this is a thing that Emacs can solve by
itself, and that device names are acceptable to me as a “good enough”
solution, provided it is end-user configuration that determines their
event mappings. My issues in this thread are two-fold:

        1) Device names cannot be counted on to be unique, and any
design in Emacs that uses device names must take that into account, and,
        2) Users should be informed that if they have multiple devices
of the same type, then workarounds for various platforms may be
necessary, such as udev rules on Linux.

-bjc



reply via email to

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