On Thu, Sep 26, 2013 at 08:49:24AM -0300, Wander Lairson Costa wrote: > 2013/9/25 Ran Benita <ran...@gmail.com>: > > On Tue, Sep 24, 2013 at 08:02:30PM -0300, Wander Lairson Costa wrote: > >> Hi, > >> > > > > Hi, > > > >> I am working for some time porting Blender to wayland [1] and I am now > >> adding keyboard handing support. For that, I am following weston > >> clients code as reference and using libxkbcommon. > >> > >> To make a long history short, I need to differentiate left-shift and > >> right-shift modifiers, but I didn't figure out how to do that with > >> libxkbcommon. I printed all modifiers names and there is just one > >> "Shift" modifier, there aren't "LShift" and "RShift" like there are > >> for control and alt key modifiers. > > > > I'm afraid we have no way to do that. We currently only expose the 8 old > > X11 modifiers, which only have Shift. There are also what's called > > virtual modifiers, which I have some pending work to expose, but these > > *too* don't have separate RShift and LShift modifiers (as opposed to > > e.g. LControl and RControl) - that's in current xkeyboard-config, which > > is the project where all the keyboard data is maintained. And there was > > some sensible resistence to addings these, for example here: > > https://bugs.freedesktop.org/show_bug.cgi?id=50935#c18 > > > > Of course, X11/XKB is in exactly the same boat here, so I from a quick > > look I found that what the blender X11 backend does (as far as I can > > see), is that it gets the key state with the XQueryKeymap(3) request, > > and then sees if the left/right *keys* are down. That's not entirely > > correct purely speaking, but I guess it works in 99.9999% percent of the > > cases. So I can only suggest you do the same for now for Wayland. > > > > But... xkbcommon doesn't (and prefereably won't) expose an equivalent of > > XQueryKeymap itself, and the Wayland protocol only provides it on the > > wl_keyboard enter event (with the 'keys' field). So unfortunatly what > > you have do is get/reset this array on wl_keyboard enter event, and > > keep it updated manually on the client side on key events. That should > > work... Unless someone has a better idea! > > > > Initially I thought to handle this in the key event (maybe only for > shift key). I just don't which would be the best solution...
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. (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). Ran > > > Sorry! > > Ran > > > >> > >> [1] https://github.com/walac/blender-wayland > >> > >> -- > >> Best Regards, > >> Wander Lairson Costa > >> _______________________________________________ > >> wayland-devel mailing list > >> wayland-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > -- > Best Regards, > Wander Lairson Costa _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
