Libinput: Halfkey/Mirrorboard implementation

[Kieran Bingham]

Hi Bill

On 19 August 2015 at 19:03, Bill Spitzak <spitzak at gmail.com> wrote:
> On Tue, Aug 18, 2015 at 11:20 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
>>
>>
>> > My difficulties with xkb are in creating a mapping where by the space
>> > bar
>> > acts as both a modifier *and* a space bar.
>>
>> right. I don't think xkb will let you do this, at least not as a either/or
>> case depending on e.g. how long you press. you'll need to designate a
>> separate key for it.
>
>
> He does not want "how long you press". What is wanted is that if the key is
> pressed and then released without any other keys being pressed, it produces
> the keysym (on the up event). It acts as a modifier in all cases (the client
> will see the modifier flag turn on/off).


Absolutely correct.

> 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?


> 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?

--
Regards

Kieran