<div dir="ltr"><div>Hi,<br></div><div>Per previous email ...</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On 13 November 2014 07:35, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 12 Nov 2014 12:06:16 -0800<br>
Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> The important point is that in both your and my case the client that has<br>
> just received focus sees the 'd' as being held down. The 'd' is on in<br>
> the key-down array attached to the focus-in event!!!!<br>
<br>
</span>Correct. Apparently X apps interpret a "key already down" the same way<br>
as a "key goes down" event. That is not a Wayland issue at all.</blockquote><div><br></div><div>No, X _apps_ don't - XWayland does.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Apparently if Ctrl+D was a "compositor shortcut" to close a window, then<br>
> this patch will cause the 'd' to not be there. But since Ctrl+D is<br>
> handled by a client to close the window, the client with the new focus<br>
> *does* see it. WHY IS THIS DIFFERENT??????<br>
<br>
</span>Because when you hit a compositor hotkey, that final key-press in the<br>
combination must not be sent to any client at all. Otherwise there<br>
would be two consumers of the same event: the compositor and a client.<br>
This would lead to duplicate action, which is not wanted for obvious<br>
reasons.<br>
<br>
If a key combination is not a compositor hotkey, also the final<br>
key-press event is directed to exactly the one client with the keyboard<br>
focus.</blockquote><div><br></div><div>Agreed. This is why we need to be clear about the differences between key and enter. On key, you update state and run any actions. On enter, you just update your state and don't do anything which would have a direct effect, since the key has already been consumed by someone else.</div><div><br></div><div>I really need to update the documentation to be clear here. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> IMHO they should not be different, therefore this patch is wrong. There<br>
> are two possible solutions:<br>
><br>
> 1. Revert it. The actual bug is that a client that already has focus<br>
> before a "compositor shortcut" will not get any changes to the keymap.<br>
> Add something to fix this instead. I recommend a redundant focus-in event.<br>
><br>
> 2. Always send a blank key-down array in the focus-in event, since it is<br>
> possible that any key held down was the "shortcut" that caused the<br>
> focus-in event.<br>
<br>
</span>No, we are not going to break the Wayland core protocol. Also, I do not<br>
see a problem with the current behaviour.<br>
<br>
We are not going to screw up Wayland just so that X apps in Xwayland<br>
would work "better" for some cornercases.<br>
<br>
Instead, we fixed Weston to act consistently, which corrected the<br>
original problem.<br></blockquote><div><br></div><div>I think the fix makes Weston act _less_ consistently, especially when you consider how it behaves when it's nested. If Weston nested under Wayland behaves differently to DRM, that's proof that our model is broken.</div><div><br></div><div>Again, sorry for letting this sit for way too long.</div><div><br></div><div>Cheers,</div><div>Daniel</div></div></div></div>