Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numlock key is double-registering and therefore not working #74

Open
moghingold opened this issue Feb 25, 2023 · 8 comments
Open

Numlock key is double-registering and therefore not working #74

moghingold opened this issue Feb 25, 2023 · 8 comments

Comments

@moghingold
Copy link

Host: Mac OS with Barrier
Client: Arch Linux with KDE backend

Here is the debug output from waynergy when I hit the numlock key a single time on the host machine's USB keyboard:

405.301278698: [DEBUG] Modifiers: depressed: 10 latched: 0 locked: 10 group: 0
405.301296151: [DEBUG] Keycode: 77, state 1
405.301370172: [DEBUG] Modifiers: depressed: 0 latched: 0 locked: 10 group: 0
405.301375513: [DEBUG] Keycode: 77, state 0
405.369866900: [DEBUG] Modifiers: depressed: 10 latched: 0 locked: 10 group: 0
405.369886718: [DEBUG] Keycode: 77, state 1
405.369951401: [DEBUG] Modifiers: depressed: 0 latched: 0 locked: 0 group: 0
405.369956581: [DEBUG] Keycode: 77, state 0

I'm not sure why this is double-registering or what to do about it. Currently, as you might expect, the numlock key effectively does nothing and I cannot activate it.

@moghingold
Copy link
Author

Current contents of the raw-keymap section of config.ini:

[raw-keymap]
54 = 9
19 = 10
20 = 11
21 = 12
22 = 13
24 = 14
23 = 15
27 = 16
29 = 17
26 = 18
30 = 19
28 = 20
25 = 21
52 = 22
49 = 23
13 = 24
14 = 25
15 = 26
16 = 27
18 = 28
17 = 29
33 = 30
35 = 31
36 = 33
31 = 35
37 = 36
60 = 37
1 = 38
2 = 39
3 = 40
4 = 41
6 = 42
5 = 43
39 = 44
41 = 45
38 = 46
42 = 47
40 = 48
51 = 49
57 = 50
43 = 51
7 = 52
8 = 53
9 = 54
10 = 55
12 = 56
46 = 57
47 = 58
44 = 59
48 = 60
45 = 61
57 = 62
68 = 63
59 = 64
50 = 65
58 = 66
123 = 67
121 = 68
100 = 69
119 = 70
97 = 71
98 = 72
77 = 104
72 = 77
99 = 73
101 = 74
102 = 75
110 = 76
108 = 78
90 = 79
92 = 80
93 = 81
79 = 82
87 = 83
88 = 84
89 = 85
70 = 86
84 = 87
85 = 88
86 = 89
83 = 90
66 = 91
104 = 95
112 = 96
60 = 105
76 = 106
106 = 107
59 = 108
116 = 110
127 = 111
125 = 114
120 = 115
126 = 116
115 = 118
118 = 119
0 = 121
0 = 122
0 = 123
114 = 127
56 = 133
56 = 134
111 = 135
124 = 113

@r-c-f
Copy link
Owner

r-c-f commented Feb 26, 2023

Here the corresponding debug log bits for barrier on the server side would be useful, at least for now (I should probably add a provision for more information to the waynergy logging to prevent necessitating this).

Thank you for reporting these issues, by the way; it is extremely useful to get data points for configurations I don't really use myself.

@moghingold
Copy link
Author

I can't figure out how to get useful debug output from Barrier when I hit keys on the keyboard. I can get it to show me when the mouse (and thus its focus) leaves and enters each connected screen, or grabs the clipboard etc, but not show output on each keystroke the way waynergy does. Do you know how I can get you the information you're asking for? Right now the debug output on the Barrier side when I hit the numlock key is, effectively, null

@moghingold
Copy link
Author

moghingold commented Feb 28, 2023

I think I got it:

[2023-02-28T09:33:56] DEBUG1: onKeyDown id=0 mask=0x0000 button=0x0048
[2023-02-28T09:33:56] DEBUG1: send key down to "badvertising-ll" id=0, mask=0x0000, button=0x0048
[2023-02-28T09:33:56] DEBUG1: onKeyUp id=0 mask=0x0000 button=0x0048
[2023-02-28T09:33:56] DEBUG1: send key up to "badvertising-ll" id=0, mask=0x0000, button=0x0048

It does not seem to double-register the button-press on the Mac.

r-c-f added a commit that referenced this issue Feb 28, 2023
This will log things at the synergy protocol level, which would normally
be overkill but given recent issues like #74 it would actually be quite
useful.
r-c-f added a commit that referenced this issue Feb 28, 2023
The mouse bits are commented out for now, as this is strictly for #74
debugging at the moment, but just in case I'll leave them for easy
reactivation later.
@r-c-f
Copy link
Owner

r-c-f commented Feb 28, 2023

waynergy --loglevel debugsyn should now present the relevant information in latest master, though it's useful to know that barrier doesn't think it's sending a duplicate at least.

@moghingold
Copy link
Author

Here's what I got when I hit numlock:

6.303816972: [DEBUG] Got CALV
7.343619541: [DEBUGSYN] DKDN: id 61311, mod 0, key 72
7.343653842: [DEBUG] Key 72 remapped to 77
7.343671866: [DEBUG] Modifiers: depressed: 10 latched: 0 locked: 10 group: 0
7.343684162: [DEBUG] Keycode: 77, state 1
7.343845678: [DEBUGSYN] DKUP: id 61311, mod 0, key 72
7.343860488: [DEBUG] Key 72 remapped to 77
7.343878163: [DEBUG] Modifiers: depressed: 0 latched: 0 locked: 10 group: 0
7.343890528: [DEBUG] Keycode: 77, state 0
7.406720423: [DEBUGSYN] DKDN: id 0, mod 0, key 72
7.406745643: [DEBUG] Key 72 remapped to 77
7.406755703: [DEBUG] Modifiers: depressed: 10 latched: 0 locked: 10 group: 0
7.406763457: [DEBUG] Keycode: 77, state 1
7.406844564: [DEBUGSYN] DKUP: id 0, mod 0, key 72
7.406859864: [DEBUG] Key 72 remapped to 77
7.406875582: [DEBUG] Modifiers: depressed: 0 latched: 0 locked: 0 group: 0
7.406888926: [DEBUG] Keycode: 77, state 0
9.261802901: [DEBUG] Got CALV

r-c-f added a commit that referenced this issue Mar 1, 2023
Issue #74 showcases the need to allow for improperly-duplicated keys to
be dropped. id maps will already take precedence, but we need to ensure
that anything else is ignored.
@r-c-f
Copy link
Owner

r-c-f commented Mar 1, 2023

For some reason Barrier is duplicating the button, while sending with a key id of 0, which probably shouldn't be happening.

In any case, a workaround. In new latest master, keys should now be dropped by mapping to -1, so disable one of the ids in a new section in config.ini:

[id-keymap]
61311 = -1

This is a simpler variant of what I'd posted earlier, which makes things slightly less confusing.

@moghingold
Copy link
Author

That fixed it!

r-c-f added a commit that referenced this issue Mar 3, 2023
Keyboard shortcut processing will prevent certain keys from registering
with waynergy-mapper, and, in the case of #74, triggers quite
undesirable behavior when the keys differ wildly from the server. Using
the keyboard shortcut inhibition protocol, this should hopefully
eliminate this and make keymap generation much smoother.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants