Libinput: Halfkey/Mirrorboard implementation

Sun Aug 23 11:32:51 PDT 2015

On 19 August 2015 at 07:20, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Tue, Aug 18, 2015 at 05:47:43PM +0100, Kieran Bingham wrote:
>> Hi Peter,
>>
>> Sorry for the late reply here, I've moved back from South America to England
>> and had to look in to some of my assumptions!
>>
>> On 27 July 2015 at 06:07, Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> >
>> > Hi Kieran,
>> >
>> > On Fri, Jul 24, 2015 at 04:28:04PM -0500, Kieran Bingham wrote:
>> > > Hi Guys,
>> > >
>> > > I've been working on a personal project to implement one-handed touch
>> > > typing as an accessibility feature.
>> > >
>> > > There are software solutions for this available for Win/MacOS
>> > > http://www.onehandkeyboard.org, and an (expensive)
>> > > hardware solution available. There is also a solution which uses xkb
>> > > mappings to utilise the caps-lock as a modifier,
>> > > but this didn't meet my needs; along with a couple of outdated other linux
>> > > alternatives mentioned at
>> > > http://www.onehandkeyboard.org/linux-one-handed-keyboards/
>> >
>> > so first of all, I appreciate your work. the first question I have here is
>> > why the current solutions are insufficient, especially the xkb one.
>>
>>
>> The xkb solution is the only real alternate contender here for me.
>>  (Hardware = cost, windows/mac != linux, other solutions = old+broken)
>>
>> 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.

As I feared, - the really big power in this feature is that the
keyboard acts normally
until the space bar is held down. And it needs to be a central
modifier so that both
the left and right hand can both access it with ease. (Using the thumb
to flip is very
easy)

>> > > I had originally started this using XLib hooks to capture all keyboard
>> > > input and re-introduce keys through XTest.
>> > > This wasn't the best solution however, and while reading up on wayland, I
>> > > discovered libinput provides a good
>> > > location for this work. And using the xf86-input-libinput wrapper for X I'm
>> > > now using it on my laptop.
>> > >
>> > > Anyway, I thought I had got to a stage where I could share some code
>> > > (although this is still a work in progress)
>> > >
>> > > I'd love to hear your feedback as to whether this is something that you
>> > > would like to integrate, or for me to continue working on.
>> > > (I'll continue to use it for personal use, but if its desired, I can work
>> > > on improvements to upstream it)
>> >
>> > I'm wondering if libinput is the right position in the stack to handle this.
>> > libinput is a hw abstraction that makes the hw easier to deal with, more
>> > complex things should go into the higher layers.
>>
>> Exactly - I had assumed (which now I think may be wrong) that libinput was
>> effectively passing up the equivalent to scancodes which are then modified
>> by X to perform the keyboard mappings.
>
> That's correct, libinput passes evdev codes (see the KEY_* defines in
> linux/input.h) to the xf86-input-libinput driver which simply adds 8
> (historical reasons) and passes that on. in that it's no different to e.g. evdev.
>
>> I was hoping to be able to generate
>> a solution which will act 'under' the keyboard layouts so that it doesn't matter
>> what the key is ... it is being mirrored as if it was a hardware mirror.
>
> that is possible, but only while you're assuming that the HW is mostly
> identical, and this is where the difficulty lies. take your normal PC
> keyboard and it won't matter if the layout up-top is us or fr. take a laptop
> keyboard and it starts to matter, since the keys are suddenly all over the
> place.
>

For the most part, I'd expect only the main row keys to be mirrored,
So I would expect limitations. Do you know of any keyboards that don't have
the usual main rows? - i.e. A-Z and numbers albeit in a localised layout?

Ideally there would be a way for users to customise, perhaps with a
configuration
file, or GUI ... but I'm getting ahead of myself here if its not feasible :)

--
Regards

Kieran

> Cheers,
>    Peter
>
>> I'd (foolisly) hoped for a single solution that would map on to french azerty
>> keyboards, just the same as it would map to a us/en qwerty by simply mirroring
>> under the layout definitions. Now that I've dug deeper into xkb - I see that it
>> would of course be more complicated than that anyway.
>>
>>
>> >
>> > Flipping keyboard layouts is semantically more complicated than what
>> > libinput knows about the keyboard (e.g. we don't handle keyboard layouts) so
>> > you'll likely run into a number of issues here when the keyboard layouts
>> > differ from the us default. That's a nonissue for a local installation, but
>> > a bigger issue when we'd try to merge this as a generic solution for all
>> > keyboards.
>> >
>>
>> Understood.
>>
>>
>> >
>> > having this in xkb is also more discoverable for clients than in libinput
>> > where it's more or less hidden and done magically.
>>
>> This is an important point.
>> It certainly would need a switch.
>> The design goal is that the keyboard functions 'normally' except when a modifier
>> is held at the same time as a key. However, in my testing, I have
>> noted that a fast
>> typist (like me) occasionally holds the space down longer, which would give them
>> a surprise mirrored key.
>>
>>
>> >
>> >
>> > funnily enough, I can also imagine this as a daemon emulating a uinput
>> > device that does the mapping on demand to emulate a virtual hardware device.
>> > In that case everthing would be truly hidden and we'd pretend this is a
>> > custom hardware device with this functionality by default, so it'd sit below
>> > libinput.
>>
>>
>> This is sort of what my earlier solution did with XLib/XTest.
>> Disconnected the input source, and re-injected after modification.
>>
>>
>> >
>> >
>> > long term though I think the xkb solution would be the best, so again: why
>> > wasn't xkb sufficient?
>> >
>>
>>
>> In summary, I haven't been able to map the space bar to act as a modifier to
>> flip the keyboard, and a space bar when pressed on its own.
>>
>> However, I agree with your responses, and have spent a lot of today sinking my
>> head back into xkb mappings. Now that my head hurts, I've signed up to the
>> xkb mailinglist over at
>> https://groups.google.com/a/listserv.bat.ru/forum/#!forum/xkb
>> and will beg for assistance there :)
>>
>> It may be that I need to extend the compat actions to support a modifier/action
>> key somehow - but I haven't got my head round it yet.
>>
>> Regards
>>
>> Kieran