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: Eli Zaretskii
Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp
Date: Sun, 10 Apr 2022 11:28:52 +0300

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  monnier@iro.umontreal.ca,  rms@gnu.org,
>   emacs-devel@gnu.org
> Date: Sun, 10 Apr 2022 15:31:50 +0800
> 
> > 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.

My point is: Emacs should use the information about the device where
it generates the Lispy event.  At that point, we should generate a
different Lispy event for a device whose events we want to handle
differently.  On the higher levels, the device information should not
be necessary for processing those Lispy events.

How does my point above contradict the data you show about these two
devices?

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

I hope my response above explains why I think the need to know the
device info can and should stop at the level where we produce the
Lispy event objects.



reply via email to

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