xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 10 years ago

Closed 10 years ago

Last modified 9 months ago

#36 closed defect (fixed)

Cursor left and cursor down do not repeat

Reported by: Doug Doole Owned by: Antoine Martin
Priority: minor Milestone: 0.0.7.x
Component: client Version: 0.0.7.33
Keywords: Cc:

Description

The cursor left and cursor down keys are not auto repeating for me. All other keys that I have tried (including cursor up and cursor right) do auto repeat.

I have seen this in 0.0.7.28 and 0.0.7.29.

Cursor left and down were repeating in 0.0.7.23.

Attachments (4)

cursor-111031.tar.bz2 (5.3 KB) - added by Doug Doole 10 years ago.
setxkbmap.print.client (248 bytes) - added by Doug Doole 10 years ago.
setxkbmap.query.client (76 bytes) - added by Doug Doole 10 years ago.
xmodmap.client (9.3 KB) - added by Doug Doole 10 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 10 years ago by Timo Juhani Lindfors

cursor keys autorepeat here with svn 259

comment:2 Changed 10 years ago by Antoine Martin

Status: newaccepted

That's quite odd, I'm not seeing this here.
Are you still using "My client is on Kubuntu 11.04 and my server is on Ubuntu 10.04." as per #35?
Can you post the output of (from the client):

  • setxkbmap -print
  • setxkbmap -query
  • xmodmap -pke
  • the initial xpra log output from the server (no need for debug output for now)

Changed 10 years ago by Doug Doole

Attachment: cursor-111031.tar.bz2 added

comment:3 Changed 10 years ago by Doug Doole

Sorry, forgot to mention the client/server config. As you suspected, the client is Kubuntu 11.04 and the server is Ubuntu 10.04.

The requested diagnostics are attached as cursor-111031.tar.bz2.

On my system, setxkbmap -query didn't work. It reported that "-query" wasn't recognized.

(On the off chance that it makes any difference, I have not yet applied the changes suggested in #35.)

comment:4 Changed 10 years ago by Antoine Martin

I've looked at the data and nothing stands out, I will do a real test using virtual machines.

comment:5 Changed 10 years ago by Antoine Martin

Something is wrong with the keyboard data you posted: I am running 11.04 and I am getting data for setxkbmap -query:

ubuntu@ubuntu-natty32:~/Downloads$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     gb
ubuntu@ubuntu-natty32:~/Downloads$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+gb+inet(evdev)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

Note: you need to run this on the client machine! (not on the server via xpra which amounts to running it directly on the server)

comment:6 Changed 10 years ago by Doug Doole

Ah, I ran all of those commands on the server. Attached new results.

Changed 10 years ago by Doug Doole

Attachment: setxkbmap.print.client added

Changed 10 years ago by Doug Doole

Attachment: setxkbmap.query.client added

Changed 10 years ago by Doug Doole

Attachment: xmodmap.client added

comment:7 Changed 10 years ago by Antoine Martin

Confirmed with an Ubuntu 11.04 client and Ubuntu 10.04 server, and ONLY with a 10.04 server.
The keymaps are not required, but for reference, here is how you apply them to get the exact same mapping on another client:

setxkbmap -rules evdev -layout us -model pc104 -option "" -option compose:menu
cat xmodmap.client | while read line; do  echo $line | xmodmap -; done

Here is where it gets really interesting:

  • same problem with these clients (again, only with the 10.04 server): Ubuntu 10.04, 10.10 and 11.10, Debian squeeze and wheezy, opensuse 11.4 and 12.1, centos 6, fedora 15 and 16
  • but no problem with these clients (against any server I tested): fedora 16 with UK keymap, ms-windows and osx clients
  • no problem with these servers (work with any client): Ubuntu 10.10, 11.04 or 11.10, fedora 16, Debian squeeze and wheezy, opensuse 11.4 and 12.1, centos 6

Since having a different keymap (f16 with UK keymap) or not using keycodes (ms-windows and osx) avoids the problem, I think it is likely to be a duplicate keycode.
Also, looking at the debug output, the failing clients are sending both "key-repeat" packets and "key-action", the server correctly detects and ignores the second keypress with:

handle keycode 113: key Left was already pressed/released, ignoring

So I guess that the short answer for now is not to use Ubuntu 10.04 as a server... I have wasted so much time on Ubuntu-only bugs recently that I can't promise I will find the energy to spend more time on this issue right away..

comment:8 Changed 10 years ago by Doug Doole

Unfortunately, I'm not free to move my server off 10.04 because the powers that be dictate the use of LTS releases on those machines.

Cursor down/left properly auto-repeated in the 0.0.7.23 build. (Hopefully that can help you narrow down the troublesome code.)

comment:9 Changed 10 years ago by Antoine Martin

There were a number of significant improvements to the keyboard mapping code between 0.0.7.23 and 0.0.7.31 so even if I were able to isolate the changeset that caused this particular regression I am afraid that it is very unlikely that I would be able to revert it as it would break the keymapping for those who are not running broken/outdated versions of Ubuntu - which is simply not an option..
But thanks for pointing that out, maybe it will be useful.

comment:10 Changed 10 years ago by Doug Doole

I had a few minutes to kill so I played around to narrow down when the troublesome change occurred. 0.0.7.23 worked but 0.0.7.24 does not.

If you think it would be useful to know exactly which change caused the problem, I'm happy to run it down for you. (But you'll have to tell me how to map from 0.0.7.# to a specific r###. I haven't figured out where that is information hidden.)

comment:11 Changed 10 years ago by Antoine Martin

$ grep svn_revision xpra-0.0.7.24/xpra/__init__.py 
svn_revision="132"

the svn revision number was not recorded in versions before that one.

The diffstat is pretty clear, the new raw keycode stuff is the only thing that went in that release. And it is certainly not going to be removed as it fixes a number of foreign keyboard layouts.

Turning off raw keycode mode might work for you - but only for standard us-type keyboards (no time to test, sorry):

Index: xpra/xposix/gui.py
===================================================================
--- xpra/xposix/gui.py	(revision 324)
+++ xpra/xposix/gui.py	(working copy)
@@ -266,6 +266,7 @@
         pass
 
     def get_keymap_spec(self):
+        return  None,None,None
         def get_keyboard_data(command, arg):
             # Find the client's current keymap so we can send it to the server:
             try:

Or you may even have to be more selective about which attribute is None

Last edited 10 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 10 years ago by Doug Doole

I wasn't suggesting that the change be undone. However knowing which change caused the problem can sometime be helpful in addressing the issue.

The suggested change to gui.py - is that client or server side?

comment:13 Changed 10 years ago by Antoine Martin

gui.py is used on the client side, this change *should* make the server fallback to a default keymap as used with osx/ms-windows clients (and both worked ok when I tested)

comment:14 Changed 10 years ago by Doug Doole

That change does allow cursor down and cursor left to auto-repeat. However it also causes a significant reduction in auto-repeat speed. (0.0.7.23 auto-repeated at the faster speed.)

I tried playing with setting individual fields to "None", but the only way to get cursor left/down to work is to set all three to "None".

If there's anything I can do to help debug this, just let me know.

comment:15 Changed 10 years ago by Antoine Martin

Please try r406, that seems to have cured the problem for me.
(but be aware that there may well still be a few issues to iron out before the next release from trunk)

comment:16 Changed 10 years ago by Antoine Martin

Sorry, only partially fixed as you will need to use "--no-keyboard-sync" switch on the client... And that will work even before r406.
FYI: winswitch 0.12.8 has support for this option in the GUI.

comment:17 Changed 10 years ago by Doug Doole

LOL It's funny how things can happen simultaneously...

As you note was arriving, I was just testing out xpra after convincing the maintainers of my server to upgrade to Ubuntu 11.10. Since I'm off the troublesome version of Ubuntu, I can no longer reproduce the problem.

If there's something I can do to help you with this problem even though I no longer have a 10.10 server, please let me know. If you just want to close off this ticket, that's fine by me too.

comment:18 Changed 10 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

with r417, it now also works without the --no-keyboard-sync option

comment:19 Changed 10 years ago by Antoine Martin

Milestone: 0.0.7.x
Version: 0.0.7.33

comment:20 Changed 9 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/36

Note: See TracTickets for help on using tickets.