Synergy-core: Neo keyboard layout layer 3 and 4 is broken

[nbolton]

https://neo-layout.org/index_en.html

Imported issue:

• Author: Mathias Baumann
• Date: 2012-08-07 23:33:15
• Legacy ID: 3329

Steps to reproduce:

1. Install a version later than 1.3.8 on both (windows 7, 64bit) client and (arch linux, 64bit) server
2. Start server, start client
3. Try to use layer three or four of the neo layout on the client, e.g. numbers, movement keys, question mark, "_"-character, etc

Expected: Movement of the cursor or the normal action according to the key (combination) pressed.

Actual: completely ignores the key-presses or writes the layer 1 character of that key instead of the layer 3/4 character.

Versions and operating systems:

1.4.10 on windows 7 as client, 64bit

1.4.10 on arch linux as server, 64bit

Temporary workarounds:

Install version 1.3.8

Additional comments:

Note that the server had the neo layout activated while the client had the normal German qwertz layout activated.

To activate layer four, I have to press the AltGr button plus any normal button on the keyboard.
For example, the keys (in neo) LIAE + AltGr (which is ESDF in qwertz) should act as if you would press the arrow keys. This worked in 1.3.8.

To activate layer three, I have to press capslock or the key left of Return. capslock + (qwertz) H should result in the questionmark. I think it instead writes the "" which isn't even the neo layer one character of qwertz "H" (neo layer one character would be S). is the layer one character of the questiomark key in qwertz. Something is totally odd here.
See also: http://neo-layout.org/

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-03 00:59:56

I was looking a bit at the code. The log for two cases is particular interesting:

This is the log for pressing the left arrow key:

DEBUG1: event: KeyPress code=114, state=0x0000
DEBUG1: event: preKeySym: ff53
DEBUG1: event: KeySym: ef53)
DEBUG1: onKeyDown id=61267 mask=0x0000 button=0x0072
DEBUG1: send key down to "Toliop" id=61267, mask=0x0000, button=0x0072

and this is the log for pressing the left neo arrow key (enabled using AltGr+F)

DEBUG1: event: KeyPress code=41, state=0x0020
DEBUG1: event: preKeySym: ff53
DEBUG1: event: KeySym: ef53)
DEBUG1: onKeyDown id=61267 mask=0x0040 button=0x0029
DEBUG1: send key down to "Toliop" id=61267, mask=0x0040, button=0x0029

(preKeySym and KeySym were added by me)
As you can see, they are nearly identical. Only the button parameter differs.

Now, if you do the same with xev, you get the following:

First the normal left arrow:

KeyPress event, serial 27, synthetic NO, window 0x2200001,
    root 0x13f, subw 0x0, time 12683577, (945,237), root:(948,259),
    state 0x0, keycode 114 (keysym 0xff53, Right), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

And then the neo left arrow:

KeyPress event, serial 30, synthetic NO, window 0x2200001,
    root 0x13f, subw 0x0, time 12350758, (1010,222), root:(1013,244),
    state 0x20, keycode 41 (keysym 0xff53, Right), same_screen YES,
    XKeysymToKeycode returns keycode: 114
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

appart from the obviously different keycodes, the only other interesting change here is

XKeysymToKeycode returns keycode: 114

So apparently synergys uses directly the keycode to send a key event to the client without somehow checking back with the xlib (for example using XKeysymToKeycode in CXWindowsScreen.cpp:1475 (the line number might be off a tiny bit) for the keycode parameter)

I didn't test using XKeysymToKeycode myself at instead of directly the keycode there yet as I don't know where I would get all the parameters from and I don't have more time right now, but maybe this helps you to write a small patch that I can test?

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-03 10:45:47

I just noticed a small typo: It was the right arrow key of course.

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-03 19:37:52

So, further investigation revealed: Even if I get it to have the same button (as in, keycode) value as the real right-arrow, it doesn't work. The only difference left was the mask (being 0x40). Maybe the whole thing is a client issue. Which means I have to get the windows code to compile. Arg. Horror.

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-03 19:40:36

Interestingly, AltGr (causing state mask 0x40) and the normal arrow keys together also cause it to not work anymore. Maybe this is the real issue?

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-03 19:55:46

But so does the other neo modifier (the <> key next to the left shift key.. in qwertz, that is)

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-04 02:20:00

So, after getting the client to compile, first the client side log for neo-right arrow key and normal right arrow key:

neo right-arrow (AltGr/Mod4 + (qwerty) f)

        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,606
2013-01-04T03:13:46 DEBUG1: recv key down id=0x0000ef53, mask=0x0040, button=0x0029
        ..\..\..\..\src\lib\client\CServerProxy.cpp,609
2013-01-04T03:13:46 DEBUG1: mapKey ef53 (61267) with mask 0040, start state: 2000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,264
2013-01-04T03:13:46 DEBUG1: find best:  2000 0040
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,615
2013-01-04T03:13:46 DEBUG1: best key index 0 of 1 (exact)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,696
2013-01-04T03:13:46 DEBUG1: found key in group 0
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,621
2013-01-04T03:13:46 DEBUG1: state: 2000,0000,0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,788
2013-01-04T03:13:46 DEBUG1: flip: 0000 (2000 vs 0000 in 0000 - 0000)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,881
2013-01-04T03:13:46 DEBUG1: desired state: 0040 2000,0000,0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,800
2013-01-04T03:13:46 DEBUG1: flip: 0040 (2000 vs 0040 in ffff - 6020)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,881
2013-01-04T03:13:46 DEBUG1: no key for modifier 0040
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,906
2013-01-04T03:13:46 DEBUG1: unable to match desired modifier state (0040,ffff) for key 333
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,806
2013-01-04T03:13:46 DEBUG1: can't map key
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,649

right-arrow

        ..\..\..\..\src\lib\client\CServerProxy.cpp,355
2013-01-04T03:11:26 DEBUG1: recv key down id=0x0000ef53, mask=0x0000, button=0x0072
        ..\..\..\..\src\lib\client\CServerProxy.cpp,609
2013-01-04T03:11:26 DEBUG1: mapKey ef53 (61267) with mask 0000, start state: 2000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,264
2013-01-04T03:11:26 DEBUG1: find best:  2000 0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,615
2013-01-04T03:11:26 DEBUG1: best key index 0 of 1 (exact)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,696
2013-01-04T03:11:26 DEBUG1: found key in group 0
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,621
2013-01-04T03:11:26 DEBUG1: state: 2000,0000,0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,788
2013-01-04T03:11:26 DEBUG1: flip: 0000 (2000 vs 0000 in 0000 - 0000)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,881
2013-01-04T03:11:26 DEBUG1: desired state: 0000 2000,0000,0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,800
2013-01-04T03:11:26 DEBUG1: flip: 0000 (2000 vs 0000 in ffff - 6020)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,881
2013-01-04T03:11:26 DEBUG1: mapped to 14d, new state 2000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,326
2013-01-04T03:11:26 DEBUG1: keystrokes:
        ..\..\..\..\src\lib\synergy\CKeyState.cpp,830
2013-01-04T03:11:26 DEBUG1:   14d (00000027) down
        ..\..\..\..\src\lib\platform\CMSWindowsKeyState.cpp,1248

and this is the normal right arrow with altgr pressed, having the same behavior/problem as neo-right-arrow (where altGr/mod4 is also pressed)

        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,606
2013-01-04T03:18:00 DEBUG1: recv key down id=0x0000ef53, mask=0x0040, button=0x0072
        ..\..\..\..\src\lib\client\CServerProxy.cpp,609
2013-01-04T03:18:00 DEBUG1: mapKey ef53 (61267) with mask 0040, start state: 2000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,264
2013-01-04T03:18:00 DEBUG1: find best:  2000 0040
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,615
2013-01-04T03:18:00 DEBUG1: best key index 0 of 1 (exact)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,696
2013-01-04T03:18:00 DEBUG1: found key in group 0
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,621
2013-01-04T03:18:00 DEBUG1: state: 2000,0000,0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,788
2013-01-04T03:18:00 DEBUG1: flip: 0000 (2000 vs 0000 in 0000 - 0000)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,881
2013-01-04T03:18:00 DEBUG1: desired state: 0040 2000,0000,0000
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,800
2013-01-04T03:18:00 DEBUG1: flip: 0040 (2000 vs 0040 in ffff - 6020)
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,881
2013-01-04T03:18:00 DEBUG1: no key for modifier 0040
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,906
2013-01-04T03:18:00 DEBUG1: unable to match desired modifier state (0040,ffff) for key 333
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,806
2013-01-04T03:18:00 DEBUG1: can't map key
        ..\..\..\..\src\lib\synergy\CKeyMap.cpp,649

So the client seems fail the match if the modifier key is pressed..

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-05 19:47:13

I now used git bisect to find the first commit that broke the arrow keys (note that most other neo keys still work).
The first commit to break the neo-arrow keys is this one:

Date:   Wed Feb 1 15:30:35 2012 +0000
    fix for #3089 patch by David Otto    
    git-svn-id: http://synergy-plus.googlecode.com/svn/branches/1.4@1203

[nbolton]

• Author: Mathias Baumann
• Date: 2013-01-09 22:13:26

Another discovery I just made: if you use revision 1203 for the client and the latest release for the server, most characters and layers of neo work. The arrow keys and things like that don't though.

[nbolton]

• Author: Jan Regg
• Date: 2014-07-28 11:28:55

Any updates on this?

[Marenz]

This issue is still not solved and I am quite disappointed that this was closed as "obsolete" given that I voted with 8 votes for this (and not being the only one) and given that it was said that issues being voted on will be done eventually in order of votes.

[nbolton]

Sorry @Marenz my bad! I reopened and prioritized this for you.

[Marenz]

Thank you!

[dumblob]

I second this issue as I'm using very often different layouts with 3rd layer (e.g. https://github.com/dumblob/ULKL) and nearly none of the 3rd layer characters work.

Where can I vote for this issue?

[mathias-baumann-sociomantic]

Where can I vote for this issue?

The voting was from a time before it was on github. You could "buy" votes (10$) and vote on issues you found important. I think it had 11 votes or so.

It's a bit sad that this stays unaddressed for so long. I basically can't use synergy for +2 years now.

[mathias-baumann-sociomantic]

Date: 2012-08-07 23:33:15.. actually.. that's 4 years.

[Marenz]

Just trying another hopeless ping on this ticket

[NebuKatWork]

By the way, there are still more people out here having this problem!
another (hopelfully not hopeless) ping ^_^.

[Marenz]

sigh.

[Marenz]

As the git import seems to have completely scrambled the previous svn history, here is again the commit that broke this whole thing in the first place (or at least the first commit): https://github.com/svn2github/synergy-plus/commit/37903ea95e6c1f43a341cf22101656a15e7d6221?diff=unified

I just installed some old versions of 1.3.8 that I found and everything still works with that. I suppose I'll keep using that.

[mathias-baumann-sociomantic]

Posted a bounty on this: https://www.bountysource.com/issues/5242562-regression-neo-layout-layer-3-4-broken

Yes I am spending money (again) on this issue :/
I invite interested parties to vote up the issue on bountysource and to support it with $$ as well.

[tynsh]

still nothing…

[mathias-baumann-sociomantic]

Another year, another nothing

[nbolton]

Sorry for the delay in replying guys, I'll have a meeting with the development team on Monday to reassess the priority of the neo layout issue.

[mathias-baumann-sociomantic]

bwahahaha. After six years of nothingness, it is closed once again

[mathias-baumann-sociomantic]

Also, there goes my bounty

[Marenz]

I basically have to accept that you don't give a shit about this and just closed it despite several reassurances and paid votes, but could you re-open this issue so that the associated bounty page doesn't list this as closed? There might still be some people out there who care and want to try solving it.

[Marenz]

For the record, this problem still exist in the current version

[Rutix]

@nbolton why is this closed. It's still a valid issue and it's not fixed. Please reopen the issue.

[nbolton]

Please reopen the issue.

Your wish is my command.

[Viatorus]

Still no solution? ...

[Marenz]

Just my annual reminder that this issue still exists

[Marenz]

The bounty for this is now at 55$

[Marenz]

I am considering creating a job posting offering something around 500 Euros to get this fixed. Would anyone be interested? Is the amount reasonable?