[xkbcommon] How to distinguish left-shift and right-shift

[Wander Lairson Costa]

2013/9/26 Ran Benita <ran234 at gmail.com>:
> On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote:
>> 2013/9/26 Ran Benita <ran234 at gmail.com>:
>>
>> [snip]
>>
>> >
>> > The information you need, if you want to use the key-down approach
>> > (which is the only one I can think of), is whether e.g. the Left Shift
>> > key is down at any given moment. This keys-state information is kept on
>> > the compositor, but now you need to reconstruct it on the client. The
>> > way to do it is as I outlined above, i.e. wl_keyboard.enter event, which
>> > gives you a wl_array of all the keys which are pressed +
>> > wl_keyboard.key events, which allow you to keep this array in sync.
>> >
>>
>> This is what I was thinking about.
>>
>> > (Though by a quick look at the Weston code, it might be that it sends
>> > key-down events for all the keys which are down when the focus is
>> > changed, that is, it replays what happened to get to the current state.
>> > So maybe you don't need the information in the wl_keyboard.enter after
>> > all, only the key events with an initial empty array. It should be easy
>> > to check which way is it).
>> >
>>
>> But this is an weston implementation detail, I guess, other
>> compositors may not have the same behavior.
>
> Good point, I can't find it specified either. I think whatever the
> current behavior is, it should be specified in wayland.xml, so people can
> rely on it. In some cases, such "undefined behavior" can be a real
> hinderance, for example if you want to keep a 'press-count' for a key
> (there can be cases like two keyboards in the same seat, so *two* Left
> Shift keys can be down at the same time, etc). And since Wayland will
> have many compositors, you don't have a de facto standard like X server,
> and they *will* do it differently, I expect...
>

This kind of "undefined behavior" does not happen only on this case.

For example, I have been wondering about window decoration. AFAIK,
Wayland leaves to the compositor thr decision if window decoration should be
client side or server side. In weston, it is client side, KWin will be
server side, how an application would know if it has to decorate its
own window or not?
(This is a more general question that may deserve its own thread)

> So if you see what happens exactly, it'd be nice if you open a bug, or
> post back, or send a patch :)

Do you mean about the behavior when we have more than one keyboard
attached to a seat?


-- 
Best Regards,
Wander Lairson Costa