Keyboard keys not being sent. about x2x HOT 27 CLOSED

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).

from x2x.

@rhoit thanks dai -Y falg worked for me:
ssh -YC [email protected] 'x2x -east -to :0.0'

from x2x.

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.

from x2x.

THY

from x2x.

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.

from x2x.

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?

from x2x.

Same here, between 2 arch machine, one on i3 and one on xmonad

from x2x.

Although I'm not sure it'll be of any use, both of my machines were running awesome.

from x2x.

It's strang my terminal seems to respond to keystroke (the flashing cursor respond to my hitting keys, but no characters are displayed).

from x2x.

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.

from x2x.

yes indeed, same as doctorcolossus - then I wonder if it's just a question of setxkbmap ??

from x2x.

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?

from x2x.

Would it make sense to make that patch? Or maybe add it as a command line option?

from x2x.

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.

from x2x.

Same problem here.

from x2x.

thanx @alexoj -Y worked for me!

from x2x.

worked for me too. Thanks @thapakazi 😄

from x2x.

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.

from x2x.

worked for me too. Thanks @alexoj @thapakazi 🙇‍♂️

from x2x.

-Y worked here between a Linux and OpenBSD machine.

from x2x.

-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.

from x2x.

@barak

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.

from x2x.

Unfortunately, there is not enough information to understand if this is a bug, a number of different bugs or a misconfiguration.

from x2x.

What information is missing, I can probably test things out.

from x2x.

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.

from x2x.

@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.

from x2x.

@progfou

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?

No. KDE on Wayland is very experimental still.

I will investigate ssh -Y

from x2x.