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

[Jason Ekstrand]

On Thu, Sep 26, 2013 at 5:46 PM, Wander Lairson Costa <
wander.lairson at gmail.com> wrote:

> 2013/9/26 Ran Benita <ran234 at gmail.com>:
> > 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.
>
> I fail to see success on this approach. Today you can run kde
> applications under gnome
> (and vice versa). What about if, with wayland, KDE does server side
> decoration and gnome chooses
> client side decoration, what would a kde application running under
> gnome look like?
>

This question comes up all the time.  The simple answer here is that the
negotiation protocol hasn't been written yet.  Why hasn't it been written?
Primarily because it hasn't become an issue yet.  The only people really
pushing for server-side are the KWin people.  However, they are still
working on porting to Qt 5 and QtQuick 2.  Once they get to implementing
the Wayland bits and *if* they still want to do server-side decorations at
that point, one of them will probably start working on such a protocol.


> > 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.
> >
>
> Yes, because Blender does not use any toolkit.
>

For now, just draw decorations when not fullscreen.  Once a negotiation
protocol gets developed, you can implement it.


>
> > 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.
>
> I hope compositors agree on following the same path for "undefined
> behaviors",
> otherwise toolkits and applications will have a hard time to come.
>

Looking at weston's input.c, I am not seeing any evidence that it sends any
key events due to an enter.  It does resend the modifiers, but that's
different.  It doesn't make sense to me that you would send the currently
depressed keys as an array and then send them again one-at-a-time.


> >
> >>
> >> > 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).
> >
>
> Not a problem, I will do that.
>

In theory, a client should not be able to notice that more than one
keyboard is plugged into a seat.  I'm not sure that that is correctly
implemented in weston right now, but I seem to remember it being the case.
A better person to ask about that would be Daniel Stone.

Thanks,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130926/935ea689/attachment-0001.html>