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

[Ran Benita]

On Thu, Sep 26, 2013 at 06:46:02PM -0500, Jason Ekstrand wrote:
> > 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>:
> > > 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.

Hi Jason, thanks for looking.

Right, for some reason I misread the loop in notify_keyboard_focus_in()
to send key events. So there's no undefined behavior here; all the
better. The enter + key events like I said initially should work well.

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

Last I tried this was working as intended.

Ran