Libinput: Halfkey/Mirrorboard implementation

[Kieran Bingham]

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.



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

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