Plover sends wrong keysyms with non-qwerty layouts after a {#Return}

[Cat-Ion]

I use dvorak on my default keyboard, and using it in NKRO mode is not an issue.

Today I assembled and started using my new Stenoboard, and have found a strange bug (both in NKRO and Gemini PR mode): Some stroke combinations make plover send the wrong keysyms subsequently, until I've hit any key on a non-stenoboard keyboard.

An example: If I stroke HEL/HRO/RB/WORLD, I get "Jdppsw ,soph" which is what you'd get when using a dvorak keyboard like it's qwerty.

I'm unsure about the conditions under which it does so, but right now I can reproduce this by just hitting R-R: TPHOL/TPHOL/TPHOL/R-R/TPHOL will write "Normal normal normal / Lsomap"

[morinted]

Can you piece out the relevant pieces of your Plover log file to see what it is saying?

Also, please check, when it happens, what the window and global settings are for keyboard layout. Do you also switch to qwerty and have it in your layout list?

Cheers, Ted On Jan 31, 2016 11:26 AM, "Valentin Ochs" notifications@github.com wrote:

I use dvorak on my default keyboard, and using it in NKRO mode is not an issue

Today I assembled and started using my new Stenoboard, and have found a strange bug (both in NKRO and Gemini PR mode): Some stroke combinations make plover send the wrong keysyms subsequently, until I've hit any key on a non-stenoboard keyboard

An example: If I stroke HEL/HRO/RB/WORLD, I get "Jdppsw ,soph" which is what you'd get when using a dvorak keyboard like it's qwerty

I'm unsure about the conditions under which it does so, but right now I can reproduce this by just hitting R-R

— Reply to this email directly or view it on GitHub https://github.com/openstenoproject/plover/issues/331.

[stenoknight]

I think this is a Stenoboard issue, not a Dvorak layout or Plover issue. I've seen the qwerty equivalent happen many times with the Stenoboard both with Plover and with StenoKeyboard on Android, but I've never been sure quite how to reproduce it. It's like for some reason it just stops working as a steno machine and starts emulating a regular keyboard. On Jan 31, 2016 11:39 AM, "Ted Morin" notifications@github.com wrote:

Can you piece out the relevant pieces of your Plover log file to see what it is saying?

Also, please check, when it happens, what the window and global settings are for keyboard layout. Do you also switch to qwerty and have it in your layout list?

Cheers, Ted On Jan 31, 2016 11:26 AM, "Valentin Ochs" notifications@github.com wrote:

I use dvorak on my default keyboard, and using it in NKRO mode is not an issue

Today I assembled and started using my new Stenoboard, and have found a strange bug (both in NKRO and Gemini PR mode): Some stroke combinations make plover send the wrong keysyms subsequently, until I've hit any key on a non-stenoboard keyboard

An example: If I stroke HEL/HRO/RB/WORLD, I get "Jdppsw ,soph" which is what you'd get when using a dvorak keyboard like it's qwerty

I'm unsure about the conditions under which it does so, but right now I can reproduce this by just hitting R-R

— Reply to this email directly or view it on GitHub https://github.com/openstenoproject/plover/issues/331.

— Reply to this email directly or view it on GitHub https://github.com/openstenoproject/plover/issues/331#issuecomment-177545778 .

[Cat-Ion]

@morinted: Here's the relevant strokes.log, after a fresh start:

2016-01-31 17:50:22,265 Stroke(P-)
2016-01-31 17:50:22,266 Translation(('P',) : about)
2016-01-31 17:50:24,870 Stroke(R- -R)
2016-01-31 17:50:24,871 Translation(('R-R',) : {^}{#Return}{^}{-|})
2016-01-31 17:50:27,022 Stroke(P-)
2016-01-31 17:50:27,022 Translation(('P',) : about)

It prints

about
Ansfk

I only have global settings, and they are always set to dvorak. I can switch to qwerty by holding both shift keys at once, but that changes all keyboards - and the normal keyboard is unaffected here.

@stenoknight: That's what I thought at first, but I don't see how a stenoboard in serial mode could affect my keyboard layout, and when plover is not running it does not change the layout when pressing R-R. If anything, it has to be some weird interaction between the two.

[Cat-Ion]

One more update: Completely removing the option to switch keyboard layouts by pressing shift-shift does not change this behaviour.

[morinted]

Ah, and what operating system and version are you using? On Jan 31, 2016 12:01 PM, "Valentin Ochs" notifications@github.com wrote:

One more update: Completely removing the option to switch keyboard layouts by pressing shift-shift does not change this behaviour.

— Reply to this email directly or view it on GitHub https://github.com/openstenoproject/plover/issues/331#issuecomment-177551080 .

[Cat-Ion]

I'm using Gentoo Linux, and Plover's current HEAD, revision 47d6e4a.

[Cat-Ion]

Adding new strokes for R-R's definition ({^}{#Return}{^}{-|}) gives the same result. Going to try figuring out which exact combination it is.

[Cat-Ion]

Anything with {#Return} in it...

And adding a stroke for "Hello,{#Return}world" prints "Hello{#Return},rpne" :)

[morinted]

All right. @Benoit-Pierre has done some great stuff with Linux keyboard handling, but it may be affecting you. You could try a git bisect, first try to see whether returning to bb3d718a fixes your problem. On Jan 31, 2016 12:36 PM, "Valentin Ochs" notifications@github.com wrote:

Anything with {#Return} in it...

— Reply to this email directly or view it on GitHub https://github.com/openstenoproject/plover/issues/331#issuecomment-177558849 .

[Cat-Ion]

It does not seem to fix it. What I did was

git checkout bb3d718
sudo python setup.py install
cd ~/.local/share/plover
plover

instead of just running ./launch.py.

Results are the same.

Do you have another revision that might have caused this?

[Cat-Ion]

I've checked back as far as revision cd12a14, at which point I get errors due to missing modules, and the behaviour always stays the same. Either I'm messing something up with my installs, or it's always been broken like this.

[Cat-Ion]

If I set my keyboard to qwerty so plover works correctly, writing {#Return} will still trigger the bug, and when I hit a key on the normal keyboard it will be back to dvorak again... even if that's not the next keyboard in the rotation.Weird.

[Cat-Ion]

Using NKRO mode, triggering the bug, and disabling plover still leaves the stenoboard in qwerty mode. Hitting another key fixes it, as before.

[stenoknight]

Do you have an Android phone and a USB-OTG adapter? Curious to see what happens with StenoKeyboard rather than Plover.

On Sun, Jan 31, 2016 at 2:57 PM, Valentin Ochs notifications@github.com wrote:

Using NKRO mode, triggering the bug, and disabling plover still leaves the stenoboard in qwerty mode. Hitting another key fixes it, as before.

— Reply to this email directly or view it on GitHub https://github.com/openstenoproject/plover/issues/331#issuecomment-177597418 .

Mirabai Knight, CRC, RDR StenoKnight CART Services 917 576 4989 mkk@stenoknight.com http://stenoknight.com

[Cat-Ion]

I have an Android phone, but no adapter. I'll ask my roommate if he's got one when I get home.

[Cat-Ion]

Apparently not. I've ordered one from Amazon, and hope that we'll be able to resolve this before Tuesday anyway. ;)

[Cat-Ion]

Same results if I use qwertz (Germany's qwerty), unsurprisingly. The differences are just smaller - non-alphanumerics and y<->z, mostly.

[Cat-Ion]

Anything that uses send_key_combination(), i.e. dictionary entries with {#Stuff} seems to trigger this. The difference to the normal execution path is that this function uses xtest.fake_input() to send key events, while usually it goes through send_key_event() to target_window.send_event().

[Cat-Ion]

https://p.0au.de/4acaaea9/xinput.py and here's a test program that works as a test case for me.

[Cat-Ion]

in xev you can see a MappingNotify event just before the first xtest event. Jasper in #xorg-devel guesses, that the xkb layout is not being applied to the xtest subdevice. So it does not look much like a Plover bug anymore, unless it just needs to handle that MappingNotify event.

[Cat-Ion]

For those who also run into this, setxkbmap <layout> will fix this until X is restarted. The reason is probably that xtest devices do not use NewInputDeviceRequest when initializing, but as this is a rather niche use and has a workaround it's unlikely to be fixed any time soon.