Keyboard keys not being sent.
Closed this issue · 27 comments
Mouse pointer is working but type on the keyboard has no effect on remote machine, keyboard keys are not sent to my host machine though. Installed on a Raspberry Pi
Confirmed -- same problem between two netbooks. Tested using i3 and dwm window managers and in plain x. Keyboard input does appropriately cease on the local machine, but there is no apparent effect on the remote machine. xev on the remote machine actually does pick up keystrokes, but all keypresses are logged as keycode 204, NoSymbol.
Having exactly the same issue between my two arch machines. I recently switched one of them to Arch from Ubuntu though (and x2x was working fine between them then), so perhaps the problem has to do with Arch vs. Ubuntu?
Same here, between 2 arch machine, one on i3 and one on xmonad
Although I'm not sure it'll be of any use, both of my machines were running awesome.
It's strang my terminal seems to respond to keystroke (the flashing cursor respond to my hitting keys, but no characters are displayed).
Do you have a copy of xev on the machine you're connecting to? Check to see if you get the same results as doctorcolossus.
yes indeed, same as doctorcolossus - then I wonder if it's just a question of setxkbmap ??
I wonder if x2x depend on the xorg.conf ? If you have one on your ubuntu and none on the arch you could try to copy one over the other, mainly the one about keyboard?
Quick fix: Works for me by changing line 2071 of x2x.c to:
keysym = XkbKeycodeToKeysym(pDpyInfo->toDpy, pEv->keycode, 0, 0);
I do not know the implications of this, but I'd have to guess that it wouldn't use the keyboad settings on the remote machine.
I also noticed by enabling debug that the above function returns a (null) keypress, so there might be something strange with the connection to that X server.
Additional note: Running on Arch -> Arch using i3 on both.
Would it make sense to make that patch? Or maybe add it as a command line option?
I guess that depends where the actual issue is- x2x or the x server connection. Changing the decode from using the "from" x to using the "to" x has some important implications, I think. Might even actually be an extra feature to make that a command line option, but idk exactly how useful it would really be.
Same problem here.
I had this issue (mouse working, all keypresses logged as keycode 204) and got it to work by using ssh -Y instead of ssh -X when starting the program (i.e: ssh -Y plasma.local x2x -west -to :0.0).
@rhoit thanks dai -Y falg worked for me:
ssh -YC thapakazi@192.168.12.123 'x2x -east -to :0.0'
THY
worked for me too. Thanks @thapakazi 😄
ssh -Y doesn't make a difference here. Letter keys work fine, but numbers are messed:
both 11 and 12 keycodes show as keycode 77 for example.
worked for me too. Thanks @alexoj @thapakazi 🙇♂️
-Y worked here between a Linux and OpenBSD machine.
-Y didn't work for me on KUbuntu->KFedora. Both PCs have the same physical keyboard and software keyboard layout and DE so there should be no keycode incompatibilities.
Would it make sense to make that patch? Or maybe add it as a command line option?
If it existed as a cli option it would theoretically give people the ability to try another fix before coming to issue tracker.
Unfortunately, there is not enough information to understand if this is a bug, a number of different bugs or a misconfiguration.
What information is missing, I can probably test things out.
At least xev output from both machines.
However note that the project is dormant, so it will have to wait until a new maintainer steps in and solves the number of accumulated problems.
@Avamander, could it be because you are opening a Wayland session (default choice in Ubuntu, may be default in KUbuntu too) instead of an Xorg session?
Since a lot of people (including me) got this keyboard-only-problem “solved” with the ssh -Y option, it looks like it is just about a security control in the way of x2x (cf "man ssh", -Y option). The other case I know for x2x not working is when we use Wayland instead of Xorg. Both these cases are not bugs but only usage/configuration issues. So, IMHO, this bug report could be closed as “not a bug”, with comment from @alexoj set as a working solution.