> > The actual sequence: > > > > [2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1) > > [2134421.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1) > > [2134422.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0) > > [2134423.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0) > > > > The correct sequence - after applying this patch: > > > > [2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1) > > [2134423.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0)
> Sorry I completely cannot figure out any reason the client can't do this filtering. it can't. because of the release 3. it is actually not the last time that key released. only compositor knows it's still held. it's also the protocol I disagree with and needs to be fixed too "physical state of a key which provoked the key event" but it says "key is not pressed" obviously the possibility of multiple devices was not clearly explained here. the wl_keyboard was meant to provide an abstraction of single device please note that the compositor itself needs filtered keys for the purpose of constructing the keys stack, calculating the modifiers, key bindings and for grabs. constructing the keys stack is necessary because it has to deliver already held keys on surface enter. It is constructing this stack even before any client comes to play. the proposal is to simply extend this existing `filtering` to delivered events. mainly to clear those early releases. it's simply a side effect it clears also other stuff. > And I suspect there are clients who would want to see the multiple events. if they are going to detect the multiple presses that way, it will be completely incorrect. they simply aren't supposed to do that. the wl_keyboard is supposed to look like single device from the client's side. if the user needs to distinguish multiple physical keyboards she needs: - assign them to multiple wl_seat - create a new api wl_keyboards(?), where key() involve a counter how many times is key held. this counter will be a "replacement" for enum key_state _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
