Libinput: Halfkey/Mirrorboard implementation

[Bill Spitzak]

On Sun, Aug 23, 2015 at 11:38 AM, Kieran Bingham <kieranbingham at gmail.com>
wrote:

>
> > This is a very common request, usually for the opposite reason: to make a
> > modifier also produce a keysym. In particular it would allow Ctrl or
> AltGr
> > to act as a compose prefix, something a lot of plugins for Windows does,
> > while X (which invented the compose key) is forced to dedicate a key.
> > (compose is (I hope) actually done by the input method, which can in
> fact do
> > this handling of Ctrl, the problem is that it can't use the mapping of
> the
> > compose key, it has to actually use Ctrl, and thus it has to have a
> > different configuration file to control what key is the compose prefix
> than
> > the keyboard layout).
> >
> > This can also make Windows style things like Alt moving the focus to the
> > menubar, or the Super key popping up a dialog while still acting like a
> > modifier. I know these work on Linux but they do so because the apps are
> > actually looking at the Alt or Super key to see if they are released. It
> > seems more consistent that these actually produce a "Move to menubar" or
> > "super menu" keysym, thus allowing keyboard layouts to move them around.
>
> Yes - these are perfect examples. I guess you are saying that this is
> not currently
> handled by xkb, but by the desktop manager or UI toolkit?
>

Yes. Currently the toolkit has the information "the Alt modifier moves the
focus to the menubar". Rather than the more consistent "the Alt key has the
MOVE_FOCUS_TO_MENUBAR keysym". This is somewhat annoying because what the
user considers key assignments is done in different places. In reality it
is more of a conceptual problem than practical one, as users rarely change
such assignments.



> > And before you say "rollover" I am well aware of that. The toolkits
> handling
> > the Alt key are already dealing with this, and it is no excuse for
> > completely disabling functionality!. I think xkb could use the event
> > timestamps to detect this. Though it really sounds like that touch
> handling
> > stuff with all the fiddly timing and dependency on hardware details, so
> > maybe (yeah right) we could again consider moving keysym translation to
> > libinput and out of clients.
>
>
> What's 'rollover' in this context?
>

If a user types quickly they may not release the previous key fast enough
and thus the release is after the press for the next key.

In your example a user may just be typing fast, and intending to type a
space and then the letter 'a', but they are going quick enough that the
space is still held down. Your keyboard would then type a semicolon when
the user expected an 'a'.

Yes this is a problem, but it is not a reason to make it impossible for xkb
to do this at all. However I believe that is the excuse being used for this
lack of ability.

(normal solution is to apply complicated timing rules to detect if this is
happening. Certainly xkb could do this, it gets timing information. I
personally feel this is a complexity similar to the touch rules being done
by libinput, therefore the entire decoding should be moved from clients to
libinput, and Wayland clients would get events with the already-decoded
keysyms attached to them. There is considerable dislike for this idea from
the Wayland developers, though I am stumped why. My best guess is that it
makes X11 emulation harder).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150824/3a6b6222/attachment.html>