Opened 4 years ago

Closed 4 years ago

Last modified 2 years ago

#149 closed defect (fixed)

The '<' key produces '>' with the winswitch xpra

Reported by: dschauer Owned by: antoine
Priority: major Milestone: 0.12
Component: Xpra Keywords:
Cc:

Description

Using xfce4's terminal the '<' and '>' keys are fine.
Using the same terminal and going through xpra, < (lt) is > (gt), but > (gt) is still correct, and , (comma) and . (period) are still correct.

Without xpra: <> ,.
With xpra: >> ,.

I can copy/paste a '<' from a non xpra window and it works as expected.

Same thing happens with Xfce's Mousepad 0.2.16 and Terminal 0.4.7.

This is with aur/xpra-winswitch 0.0.7.22-1
aur/parti-all 0.0.6-2 is fine and does not have this bug.

Both Xfce's Mousepad and Terminal behaviours are correct in terms of '<' and '>' when using the xpra from parti-all.

Attachments (2)

keycode_dont_ignore_level.patch (1.4 KB) - added by antoine 4 years ago.
patch for shifted keys
2012-11-20-221402_2560x1600_scrot.png (206.5 KB) - added by antoine 2 years ago.
screenshot showing ubuntu 12.04 server with windows 7 client

Download all attachments as: .zip

Change History (20)

comment:1 Changed 4 years ago by lindi

What keyboard layout are you using?

comment:2 Changed 4 years ago by antoine

  • Owner changed from Antoine Martin to antoine
  • Status changed from new to accepted

Can you please test the patch and tell me if this fixes the problem for you?

Changed 4 years ago by antoine

patch for shifted keys

comment:3 Changed 4 years ago by antoine

For telling us the type of keyboard you have, please give post the output of:
setxkbmap -print

And if possible a link to a picture (worth a thousand words), ie: maybe this one? ('fr')

comment:4 Changed 4 years ago by dschauer

Not going through xpra:

setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+us(altgr-intl):2+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

Going through the non winswitch xpra:

setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(pc105)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

The xpra from winswitch is the same as the one from parti-all as far as the "setxkbmap -print" output.

Last edited 4 years ago by antoine (previous) (diff)

comment:5 Changed 4 years ago by antoine

Does the patch above make any difference (better or worse?)

What I am really interested in is your xkbmap from outside xpra. (and your keyboard layout, pic or otherwise)

comment:6 Changed 4 years ago by dschauer

The patch corrected the problem. My keyboard layout not going through xpra is the first one in comment4. The second one is going through either the winswitch xpra or the parti-all xpra.

comment:7 Changed 4 years ago by dschauer

This is what the main part of my keyboard looks like.

http://en.wikipedia.org/wiki/File:KB_United_States-NoAltGr.svg

If I use the international AltGr dead keys with the English (US) layout, right alt works outside of xpra, but not when going through xpra (either the parti-all one or the winswitch one).

Outside of xpra:

setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us(altgr-intl)+us:2+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

Inside xpra:

 setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(pc105)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

Well, what I mean is "Right Alt" works as "Right Alt" in xpra, and not as "AltGr", but it does work as "AltGr" outside of xpra.

Last edited 4 years ago by antoine (previous) (diff)

comment:8 Changed 4 years ago by antoine

  • Resolution set to fixed
  • Status changed from accepted to closed

Excellent, that's merged in r88
I think there are still other problems in this area but we'll try to deal with those when they get reported.

Re layouts: gotcha, you said so quite clearly... sorry about that. me getting confused!

Thanks for your help! Feel free to re-open this bug if other keys misbehave.

comment:9 Changed 4 years ago by antoine

  • Resolution fixed deleted
  • Status changed from closed to reopened

Ooops, just missed the comment about AltGr, re-opening this bug...

comment:10 Changed 4 years ago by antoine

  • Milestone set to 0.12

comment:11 Changed 4 years ago by rainwoodman

as of 0.12.3 the bug with < is still there. The client is running on Windows 7. The server is on Fedora 15(vanilla install)

comment:12 Changed 4 years ago by antoine

  • Status changed from reopened to accepted

There have been no new build released since the fix, hopefully I will find the time to do one this week... In the meantime, you can use svn (at least on *nix, much harder to do on win32/osx)

comment:13 Changed 4 years ago by antoine

Please test v0.0.7.25 and let me know if the issue is still present.
And if so, please report full OS version, setxkbmap -print, setxkbmap -query, etc..

comment:14 Changed 4 years ago by Dschauer

'<' and '>' work correctly for me now. This issue has been resolved.
Alt-Gr also works correctly for me now (is not treated as right alt).

Up to date Arch Linux x86_64 install for both server and client.
Installed AUR xpra-winswitch 0.0.7.27-1 package on both the server and client.

server:

$ xpra --version
xpra v0.0.7.27
$ uname -o
GNU/Linux
$ setxkbmap -print
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+us:2+inet(evdev)"        };
        xkb_geometry  { include "pc(pc104)"     };
};
$ setxkbmap -query
rules:      evdev
model:      evdev
layout:     us,us

client, outside xpra:

$ xpra --version
xpra v0.0.7.27
$ uname -o
GNU/Linux
$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us(altgr-intl)+us:2+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};
$ setxkbmap -query
rules:      evdev
model:      evdev
layout:     us,us
variant:    altgr-intl,

client, inside xpra (Xfce4 terminal):

$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+us:2+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};
$ setxkbmap -query
rules:      evdev
model:      evdev
layout:     us,us
Last edited 4 years ago by Dschauer (previous) (diff)

comment:15 Changed 4 years ago by lindi

Yes this was fixed several week ago, sorry for not commenting on it. I think it is at least xpra svn 131 that has a fix. The protocol was changed to send raw keycodes.

comment:16 Changed 4 years ago by antoine

  • Resolution set to fixed
  • Status changed from accepted to closed

Excellent, thanks for getting back to me.

Closing.

comment:17 Changed 2 years ago by Grischa

I still have this problem.
Also the '|' key produces '>'.
Client Windows 7, server Ubuntu 12.04.

The key issue is instantly fixed when I turn off "Keyboard Synchronisation". However, then key combinations do not work anymore...

Both in an ssh session and in an xpra-xterm I get the same output for setxkbmap -print

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)"     };
};

Should I reopen this bug or open another one?

Changed 2 years ago by antoine

screenshot showing ubuntu 12.04 server with windows 7 client

comment:18 Changed 2 years ago by antoine

Just tested (see screenshot) and I cannot reproduce this at all, I've tried with the default windows layout I have (gb) then switched to 'us', still no problem.

Feel free to create a new ticket on xpra's bug tracker, including as many details as possible (logs, etc)

Note: See TracTickets for help on using tickets.