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

arrow keys not working in XWayland #22

Open
bram-arcsec opened this issue Jan 10, 2022 · 4 comments
Open

arrow keys not working in XWayland #22

bram-arcsec opened this issue Jan 10, 2022 · 4 comments

Comments

@bram-arcsec
Copy link

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.

@bram-arcsec
Copy link
Author

The issue is gone if I use the wlr backend (-b wlr) so most likely an issue with the default backend.

@r-c-f
Copy link
Owner

r-c-f commented Jan 11, 2022

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)

@trysdyn
Copy link

trysdyn commented May 18, 2022

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:

  1. Open up /usr/share/X11/xkb/keycodes/evdev (or whichever keycode map you end up using)
  2. Find the key that's broken by symbol name
  3. Get its numerical keycode
  4. Run waynergy with loglevel = 4 or -L 4, connect
  5. Press the broken key, get its keycode from the log. Remember if it's >318, X and XWayland will just ignore it.
  6. 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
  7. 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" :)

@adsau59
Copy link

adsau59 commented Sep 20, 2022

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

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

4 participants