Review Request 124954: Add support for modifier only shortcuts on Wayland

[Thomas Lübking]

> On Sept. 7, 2015, 2:59 nachm., Thomas Lübking wrote:
> > Hold it.
> > 
> > Implementationwise, this looks wonky - if it's possible to get unbalanced input events (ie. releases w/o ever a press or vv.) from the system since the counter will run out of sync.
> > 
> > => Are such unbalanced events prevented by libinput for sure or can one eg. create synthetic release events (w/o a synthetic press event)?
> 
> Martin Gräßlin wrote:
>     libinput does not (to my knowledge) allow synthetic release events. Though there might be a danger with vt switching (that probably needs more testing)
> 
> Thomas Lübking wrote:
>     i'd also worry about event compression, eg. when releasing key & modifier "simultanously" one might get only one release event?
>     
>     better safe than sorry and go for a midifier comparism and kill flag?
> 
> Martin Gräßlin wrote:
>     No libinput doesn't do that, but I agree on the better safe than sorry aspect. Will update.
> 
> Martin Gräßlin wrote:
>     Actually it doesn't matter. If we get unbalanced input events we have a bigger problem with xkb_state_update_key which is documented with a warning that missed input events can result in stuck modifiers. As that call is just above, we either have a huge issue anyway or it works.
> 
> Martin Gräßlin wrote:
>     Just did some testing with vt switching and it looks like this doesn't get xkb into an inconsistent state -> all fine I assume

I assume states are globally cleared on VT changes.

Well, I'll remind you when we end up with stuck keys everywhere :-P


Eventually, one might require an IPC access to clear states, ie. count called ups and downs for every xkb_keycode_t and rewind them (to a certain level, ie. ensure shift is considered pressed #1) - if we get trouble here, we can hardly suggest to restart kwin to clear this.
And at least on the hardware level, things can fail easily (ie. a hanging key which generated no release event - you need to press-release it to get rid of that, ie. have -likely- seen one press too much. Thanks to wireless keyboards)


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/#review84959
-----------------------------------------------------------


On Aug. 27, 2015, 4:04 nachm., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124954/
> -----------------------------------------------------------
> 
> (Updated Aug. 27, 2015, 4:04 nachm.)
> 
> 
> Review request for kwin, Plasma and Hans Chen.
> 
> 
> Repository: kwin
> 
> 
> Description
> -------
> 
> On popular demand!
> 
> This change tracks how modifiers are used and detects a modifier only
> key press/release. That is:
> * no other key is pressed when the modifier gets pressed
> * no other key gets pressed before the modifier gets released
> 
> If such a press/release is detected, we call a configurable dbus call.
> The possible shortcuts can be configured in kwinrc, group
> "ModifierOnlyShortcuts". The following keys are supported:
> * Shift
> * Control
> * Alt
> * Meta
> 
> As value it takes a QStringList (comma seperated string) with
> service,path,interface,method,additionalargs
> 
> E.g. to invoke Desktop Grid effect on Meta key:
> 
> [ModifierOnlyShortcuts]
> Meta=org.kde.kglobalaccel,/component/kwin/,org.kde.kglobalaccel.Component,invokeShortcut,ShowDesktopGrid
> 
> I do not intend to add a config interface for it. Let's keep it a hidden
> way.
> 
> 
> Diffs
> -----
> 
>   input.h cfb693dc06a18ea9ca7cffb99b9a1318ee443e3a 
>   input.cpp 92724d7b7559dd460a8f5fbe17deb3c72024eed6 
>   options.h 07c5193e3bd205c5c8c22a305f4c1d87e16d175f 
>   options.cpp 64269d64bc49640bf2e4e925ce1969f2a5d6b96b 
> 
> Diff: https://git.reviewboard.kde.org/r/124954/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150909/f1936593/attachment.html>