Hi, On 18 August 2014 13:14, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Mon, 18 Aug 2014 14:57:37 +0300 > Giulio Camuffo <giuliocamu...@gmail.com> wrote: > > 2014-08-18 14:35 GMT+03:00 Pekka Paalanen <ppaala...@gmail.com>: > > > had these patches which I'd like to see going in: > > > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012589.html > > This one looks pretty simple, and I can confirm the problem with > CapsLock, so yes, I'd like to take this. Could you rebase it? > This is a good start, yes. It's either that or go through the keymap state trying to work out the modifier state to accompany the LEDs, which is doable but a bit fiddly. > > > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012590.html > > > http://lists.freedesktop.org/archives/wayland-devel/2013-December/012591.html > > Of these two, the first needs the second to be used at all, right? The > follow-up comment is true, I would not want NumLock be on by default on > my laptop, so I think this needs more work, like you have identified. > Yes, definitely not on by default please. As for the second patch, I'm a little hesitant to add it to X11 in particular: why should we be telling the host server what the modifier state for the entire session (which is larger than the nested compositor) should be? evdev requires LEDs to be driven because in that situation, we are the lowest-level input consumer, and thus calculate our own state (i.e. call xkb_state_update_key). In nested environments (compositor-{x11,wayland}), we never calculate our own state, but receive the state from the host display server. If the host display server isn't keeping the state sent to its clients in sync with the state of its input devices, then that's a bug. (tl;dr: NAK) Cheers, Daniel
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
