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.hutte...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
