Re: Physical keyboard events

[Po Lu <luangruo@yahoo.com>]

Cecilio Pardo <cpardo@imayhem.com> writes:

> +static void
> +x_maybe_send_physical_key_event (struct x_display_info *dpyinfo, XEvent *event)
> +{
> +#ifdef HAVE_XKB

Thank you.  A number of comments: this is simply unacceptable, as Emacs
must not depend on XKB for such a basic feature.

> +  if (event->type != KeyPress && event->type != KeyRelease)
> +    return;
> +  bool keypress = (event->type == KeyPress);
> +  KeySym keysym = XkbKeycodeToKeysym (dpyinfo->display, event->xkey.keycode,
> +				      0, 0 );
> +  Lisp_Object key;
> +  switch (keysym)
> +    {
> +    case XK_Shift_L: key = Qlshift; break;
> +    case XK_Shift_R: key = Qrshift; break;
> +    case XK_Control_L: key = Qlctrl; break;
> +    case XK_Control_R: key = Qrctrl; break;
> +    case XK_Alt_L: key = Qlalt; break;
> +    case XK_Alt_R: key = Qralt; break;
> +    default:
> +      return;
> +    }

??? Code producing such events should not relay modifier keysyms
verbatim, but ought to detect the virtual modifiers to which they are
mapped, and convert them into Emacs modifiers, namely, meta, alt, ctrl,
hyper, super, and shift.  Otherwise, Lisp will find it impossible
reliably to establish a correspondence between "physical key events" and
modifiers.

> +  struct frame *f = x_any_window_to_frame (dpyinfo, event->xkey.window);
> +  if (!f)
> +    return;
> +
> +  struct input_event ie;
> +
> +  EVENT_INIT (ie);
> +  XSETFRAME (ie.frame_or_window, f);
> +  ie.kind = PHYSICAL_KEY_EVENT;
> +  ie.timestamp = event->xkey.time;
> +  ie.arg = list2 (keypress ? Qt : Qnil, key);
> +  kbd_buffer_store_event (&ie);
> +#endif
> +}

Please find some means of generating such events by saving them into the
keyboard event buffer defined in handle_ome_xevent.

>  /* Filter events for the current X input method.
>     DPYINFO is the display this event is for.
>     EVENT is the X event to filter.
> @@ -17859,6 +17896,8 @@ x_filter_event (struct x_display_info *dpyinfo, XEvent *event)
>  
>    struct frame *f1;
>  
> +  x_maybe_send_physical_key_event (dpyinfo, event);
> +
>  #if defined HAVE_XINPUT2 && defined USE_GTK
>    bool xinput_event = false;
>    if (dpyinfo->supports_xi2

x_filter_events is not the proper location for this call.  It is only
invoked to filter an event through the active GTK or X input method
context, and it is not invoked if Emacs is configured not to open input
method contexts, or they are unavailable by happenstance.

This call is properly placed in handle_one_xevent, beneath the labels
for KeyPress, KeyRelease, XI_KeyPress, XI_KeyRelease, and the GTK
keyboard callbacks in gtkutil.c.  Pay attention to the different manners
in which the key codes are converted into keysyms and the keysyms into
modifiers, and imitate them closely or reuse them if possible.

Lastly, you must decide whether to capture modifier key events before
they are filtered by the input method, or after.  Input methods have
complete discretion over disposing of these events and will either
discard them entirely or resend a possibly modified event to Emacs.  In
the latter scenario, you will receive duplicates of one and the same
event, and in principle it is impossible to distinguish between the
duplicates and the originals.  Equally unsatisfactory is the option of
generating these events after they are filtered by the input method,
since none will be generated if the IM takes the other course.

These are the same concerns that led me not to implement raw modifier
key events when this feature was proposed some years ago.