> On Sept. 7, 2015, 4:59 p.m., 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 > > Thomas Lübking wrote: > 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)
> Well, I'll remind you when we end up with stuck keys everywhere Please do ;-) - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124954/#review84959 ----------------------------------------------------------- On Aug. 27, 2015, 6:04 p.m., 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, 6:04 p.m.) > > > 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
