Keysym event in the text protocol

[Bill Spitzak]

I think the question is why both the client, the input method, and 
probably the compositor all have to do the decoding from keys to keysyms.

Contrast this to all the work being done with libinput to translate 
actions on touchpads to a more useful shared form before anybody looks 
at it. Why is this not being done by clients, with them getting raw 
events and a touchpad-description file? Possibly because nobody thinks 
that is a good idea?

I am pretty certain that it would be possible to move the shared part 
(basically what libxkbcommon does) into libinput, so everybody gets 
keysyms. It would always produce events even if there is a failure to 
translate, and the keycode would be in the event, so no information is 
ever lost, and clients could OPTIONALLY decode the stuff themselves.

The current scheme I think is going to have horrendous annoying bugs 
when the clients, compositor, and input method get out of sync and 
disagree about how the keyboard works and what shift state it is in. It 
also makes it pretty impossible to make a remote wayland to another 
system using a keyboard that is not installed on the local machine.

On 07/25/2014 06:06 AM, Pekka Paalanen wrote:
> On Wed, 23 Jul 2014 09:46:16 +0700
> Trung Ngo <ndtrung4419 at gmail.com> wrote:
>
>> Hi guys,
>>
>> In the text protocol, there is a `keysym` event (and a corresponding
>> `keysym` request in the input-method protocol). In the spec, it is used
>> to 'notify when a key event was sent.' If I understand correctly then
>> the whole point of this request/event pair is to fake a key press from
>> the input method. If so, shouldn't it make more sense to intercept the
>> keysym request at the compositor and send a key press event to the text
>> application instead of passing the keysym event to the text application
>> (no more keysym event in the text protocol)?
>>
>> In the current design, the text application has to listen to the keysym
>> event (for fake keys) and implement the key handler (for 'normal' keys)
>> at the same time, potentially duplicating code and opening up the
>> posibility that some applications forget to implement the keysym event
>> handler.
>
> I'm no expert on input, but that is all deliberate.
>
> "Normal keys" are direct user actions, a person pressing a key on a
> keyboard. These originate from a real physical action, specifically a
> key press/release. These use key codes, which in the clients are
> interpreted through libxkbcommon to take account the keymap and
> whatnot. If a keymap does not provide some keysym, you cannot input it,
> AFAIU.
>
> Input methods however use whatever (even complicated) UI that lets the
> user to choose which symbol to enter. For instance, it can be a virtual
> keyboard with all kinds of exotic symbols, poked with a finger. There
> are no physical keys to press. Or it could be just the "compose key"
> mechanism. Or a machine vision system interpreting sign language.
>
> These are fundamentally very different kinds of input. We have a strict
> separation in the protocol design between actual physical user actions
> (e.g. poking a button) and "fake" events, and we intend to keep these
> two separated all the way. For example, wl_pointer.motion is sent only
> when the user moves the pointer, not when e.g. the window moves under
> the pointer or the pointer gets warped programmatically.
>
> The burden of implementation is in toolkits, not applications.
>
>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>