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

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Who is "we" in this context?  What level of Emacs input processing
> does this "we" allude to?

The input processing at the C level: everything between and including
handle_one_xevent to make_lispy_event.

> My point is that the level on which devices could be important is
> below the code which inserts the events into the main Emacs event
> queue from which we read events as part of our main loop.  If we agree
> on that, we can stop arguing about making Emacs aware of the device
> types, because the only aspect that worries me in your design is that
> the device type should be exposed to, known by, and actively acted
> upon on much higher levels, like the commands bound to respective
> input events.  That is something we should IMO try hard to avoid.

[...]

> I don't yet understand why we _should_ know or care about that.  If a
> device pretends to be a keyboard, but emits events that "normal"
> keyboards cannot, we can still process such a device by pretending
> those additional events are some special function keys.  Like we do
> with several window-system messages already, and even with SIGUSR2
> signal.  Is anything wrong with doing the same for those devices you
> are talking about?  If so, what exactly is wrong and why?  Once again,
> please reply by presenting specific use cases where this paradigm
> cannot work well.

They emit the same events that "normal" keyboards do.  The foot pedal
for example will insert "b" just the same as a "normal" keyboard will.

If you open a text editor window and press the foot pedal, the letter
"b" is inserted.  If you turn on "xinput test-xi2" and press the foot
pedal, you will probably get something like this:

EVENT type 3 (KeyRelease)
    device: 3 (10) <----- this is the device ID of the foot pedal
    detail: 56 <--------- this is the keycode corresponding to the keysym "b"
    flags: 
    root: 996.00/568.00
    event: 136.00/94.00
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x79a event 0x4c00001 child 0x0

And if you press "b" on your keyboard, you get the same thing:

EVENT type 3 (KeyRelease)
    device: 3 (4) <------ this is the device ID of the "normal" keyboard
    detail: 56 <--------- this is the keycode corresponding to the keysym "b"
    flags: 
    root: 996.00/568.00
    event: 136.00/94.00
    buttons:
    modifiers: locked 0 latched 0 base 0 effective: 0
    group: locked 0 latched 0 base 0 effective: 0
    valuators:
    windows: root 0x79a event 0x4c00001 child 0x0

Since device IDs are not in any particular order or guaranteed to always
be the same for each device, we use the name of the device to identify
devices instead.  The relationship is similar to that of file
descriptors and file names.

But presumably the program for which the foot pedal was designed for
presents the user with a dropdown from which the device that is actually
the foot pedal is chosen.  That way, if an input with the character "b"
is registered and comes from the foot pedal, it treats that as a press
of the pedal.  Otherwise, it treats it as the user pressing the
character "b" on the keyboard.

I hope this explanation makes things clearer.

Thanks.