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

[Ran Benita]

On Thu, Sep 26, 2013 at 06:27:39PM -0300, Wander Lairson Costa wrote:
> 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)

I'm not a Wayland developer, so I can't say with confidence. But I think
this choice is deferred to the toolkit layer. In this case both
behaviors (server of client side decorations) are potentially useful, so
the protocol shouldn't *require* one or the other. Though I guess for the
issue you mentioned, maybe there should be some protocol to tell the
client whether it should draw decorations or not.

But this is not the case for the key-replay behavior. There's nothing to
be gained by letting different compositors do different things in this
case. Both behaviors are fine IMO, so should just require whatever
Weston does currently.

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

No, that should work seamlessly. I meant the replay of the key press
events (after you manage to implement your stuff in a real world
application like Blender).

Ran