waynergy
waynergy copied to clipboard
arrow keys not working in XWayland
The arrow keys in XWayland windows with a Windows primary (synergy). The native wayland applications are working fine. I am using version 0.0.3. In config.ini
xkb_key_offset = 7
is set and I installed the provided win keymap file.With loglevel=4
, I can see the arrow codes coming in but they don't have any effect in XWayland windows. I also verified this in xev
and wev
.
The issue is gone if I use the wlr backend (-b wlr
) so most likely an issue with the default backend.
That is odd indeed, as wlr is the default backend when none is specified. Which compositor are you using? And could you possibly post the log file from when it is broken and when it seems to work (at least the initial part -- be somewhat careful, given that this is basically a keylogger)
Hi there. This is an old issue but I want to document this as best I can for future users. I had the same problem when I tried to switch from i3/Barrier to Sway/Waynergy. The problem is, at least on my device, the keycodes sent by the Windows server for the arrow keys, INS/DEL/etc cluster, and some keypad keys are greater than 318. Keycodes greater than 318 are accepted by Wayland but not X, resulting in XWayland dropping them on the floor.
I ended up completely disregarding the documented win
xkb keymap and using the in-built evdev keymap with xkb_key_offset
and a smattering of raw-keymap switches to force the >318 keycodes to the ones the evdev keymap expects. It looks something like this. This should work on a US pc105 keyboard with a Windows 10 server talking to a Linux client, but YMMV.
~/config/waynergy/config.ini pertinent points
xkb_key_offset = 8
[raw-keymap]
offset = 0
offset_on_explicit = false
331 = 113 #LEFT
328 = 111 #UP
333 = 114 #RIGHT
336 = 116 #DOWN
338 = 118 #INS
327 = 110 #HOME
329 = 112 #PGUP
339 = 119 #DEL
335 = 115 #END
337 = 117 #PGDN
347 = 133 #WIN
312 = 108 #RALT
349 = 135 #MENU
284 = 104 #KPEN
325 = 77 #NMLK
309 = 106 #KP/
~/.config/waynergy/xkb_keymap entirety
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};
No custom ~/.xkb keymap at all, as you can see. The xkb_key_offset of 8 syncs almost everything on a W10 US pc105 QWERTY bog-standard keyboard to the evdev
keymap in xkb's stock files. I haven't tested if this handles media keys, www keys, or anything "fancy" like that. I use a bog standard simple Das Keyboard. If you're using a different board you'll likely need to hunt for a different keymap.
In the event that a key is missing, the process to remap it is as follows:
- Open up
/usr/share/X11/xkb/keycodes/evdev
(or whichever keycode map you end up using) - Find the key that's broken by symbol name
- Get its numerical keycode
- Run waynergy with
loglevel = 4
or-L 4
, connect - Press the broken key, get its keycode from the log. Remember if it's >318, X and XWayland will just ignore it.
- Set in config.ini [raw-keymap]
X = Y
where- X is the waynergy logged code MINUS your
xkb_key_offset
value (8 in this example) - Y is the keycode from the xkb keymap
- I recommend same-line commenting what key this is for your sanity's sake later
- X is the waynergy logged code MINUS your
- Restart Waynergy
This is a tedious process if a lot of keys are incorrect (maybe try to find another keycode map in xkb if this is the case). I'm hoping we can figure out a better way to handle this, but for now this should at least form the basis of getting someone past the hard blocker of "Half my keyboard is scrungled".
Also I'm half hoping someone will look at this and say "You're daft, here's a better way" :)
pls mention the comment above in some faq or readme, it helped out alot
also for this,
X is the waynergy logged code MINUS your xkb_key_offset value (8 in this example)
if its out of range, and it logs without -L 4
option, it already offsets the code before logging, so u dont really need to subtract it