www.cendio.com
Bug 4677 - ThinLinc Client sends KP_8 etc instead of KP_Up with NumLock+Shift
: ThinLinc Client sends KP_8 etc instead of KP_Up with NumLock+Shift
Status: CLOSED FIXED
: ThinLinc
VNC
: trunk
: PC Unknown
: P2 Normal
: 4.3.0
Assigned To:
:
:
:
: 3523 5228 5248
  Show dependency treegraph
 
Reported: 2013-06-03 14:54 by
Modified: 2014-10-21 13:49 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2013-06-03 14:54:52
Currently, the TL client has "windows like numlock", ie Shift does not cancel
NumLock. Keysym 0xffb8 is sent regardless of if shift is depressed or not.
------- Comment #1 From cendio 2013-06-03 15:00:16 -------
Debug printouts when pressing KP_8 with NumLock on:

 Viewport:    Key pressed: 0xffb8 (0xffb8) '8' => 0xffb8
 Viewport:    Key released: 0xffb8 => 0xffb8

And with shift:

Mon Jun  3 14:59:48 2013
 Viewport:    Key pressed: 0xffe1 (0xffe1) '' => 0xffe1

Mon Jun  3 14:59:51 2013
 Viewport:    Key pressed: 0xffb8 (0xffb8) '8' => 0xffb8
 Viewport:    Key released: 0xffb8 => 0xffb8

Mon Jun  3 14:59:55 2013
 Viewport:    Key released: 0xffe1 => 0xffe1
------- Comment #2 From cendio 2013-06-04 11:06:15 -------
We have an open request from upstream to generally discuss our suggested
changes to the keyboard handling. We need to look at that at the same time.
------- Comment #3 From cendio 2013-08-30 10:50:48 -------
Ugh. FLTK's keyboard handling is messy as hell. I don't think we can fix this
without severely redesigning how FLTK handles key presses. So there are two
options:

1. Ugly hack and blindly assume that Shift always negates NumLock on X11.

2. Rethink our keyboard strategy in FLTK.


I'm leaning towards 2. Our keyboard needs are a bit peculiar and dictated by
how RFB is defined. It's probably cleaner for us and upstream if instead we
have a mechanism to intercept low level system events and do whatever magic is
necessary inside vncviewer instead. FLTK might need to help out in disabling IM
though.
------- Comment #4 From cendio 2013-08-30 11:00:52 -------
(In reply to comment #2)
> We have an open request from upstream to generally discuss our suggested
> changes to the keyboard handling. We need to look at that at the same time.

Will handle this on bug 4786 instead as there are other FLTK issues that needs
to be dealt with.
------- Comment #5 From cendio 2014-02-06 11:10:44 -------
This bug has transformed into rewriting our keyboard changes for FLTK. My
current plan is to introduce a callback routine in FLTK where we can get raw
system events (MSG:s on Windows, XEvent:s on X11, etc.). All the magic will
then be in vncviewer.
------- Comment #6 From cendio 2014-02-06 11:11:25 -------
Consider bug 4984 and bug 4971 when writing the new code.
------- Comment #7 From cendio 2014-08-21 17:38:38 -------
Urgh. Windows is just full of horrible hacks in its keyboard code. Besides bug
5226, I've also seen these fun things:

 a) With num lock on, pressing shift-1 results in:

    (fake) shift release
    keypad end press
    keypad end release
    (fake) shift press

 b) Windows cannot track both shift keys properly. If you press both of them,
you get two WM_KEYDOWN. But if you release them in the same order as you
pressed them, the first WM_KEYUP will just vanish.
------- Comment #8 From cendio 2014-08-22 11:55:18 -------
(In reply to comment #7)
> Urgh. Windows is just full of horrible hacks in its keyboard code. Besides bug
> 5226, I've also seen these fun things:
> 
>  a) With num lock on, pressing shift-1 results in:
> 
>     (fake) shift release
>     keypad end press
>     keypad end release
>     (fake) shift press
> 

Bug 5228.

>  b) Windows cannot track both shift keys properly. If you press both of them,
> you get two WM_KEYDOWN. But if you release them in the same order as you
> pressed them, the first WM_KEYUP will just vanish.

Bug 5229.
------- Comment #9 From cendio 2014-08-22 13:56:28 -------
(In reply to comment #7)
>  a) With num lock on, pressing shift-1 results in:
> 
>     (fake) shift release
>     keypad end press
>     keypad end release
>     (fake) shift press

More fun. If you release shift before End, you'll see a "1" on the release
event instead of a matching End. This of course makes it easy to get out of
sync.
------- Comment #10 From cendio 2014-08-22 14:21:51 -------
(In reply to comment #9)
> (In reply to comment #7)
> >  a) With num lock on, pressing shift-1 results in:
> > 
> >     (fake) shift release
> >     keypad end press
> >     keypad end release
> >     (fake) shift press
> 
> More fun. If you release shift before End, you'll see a "1" on the release
> event instead of a matching End. This of course makes it easy to get out of
> sync.

The solution to this is to track keys using their scan code, not their vkey.
This is a bit pesky in practice though as Windows sometimes forget to inform us
of the scan code, so we have to go digging for it.
------- Comment #11 From cendio 2014-08-22 15:19:06 -------
I have something that works well now. Available here:

https://github.com/CendioOssman/tigervnc/tree/xhandlers
------- Comment #13 From cendio 2014-09-15 13:28:32 -------
FLTK patches committed upstream and in cenbuild.
------- Comment #14 From cendio 2014-09-15 13:59:43 -------
Vendor drop of TigerVNC in r29365.
------- Comment #15 From cendio 2014-09-16 16:21:54 -------
AltR is sent as AltL from Windows. Need to have a look at that.
------- Comment #16 From cendio 2014-09-17 10:32:46 -------
(In reply to comment #15)
> AltR is sent as AltL from Windows. Need to have a look at that.

Not a bug. AltR wasn't available in the server key map so it picked AltL as a
replacement.
------- Comment #17 From cendio 2014-09-18 14:46:55 -------
All done.

Test instructions are available as vnc/tigervnc/doc/keyboard-test.txt.
------- Comment #18 From cendio 2014-09-29 13:05:55 -------
Tested Linux/X11/CentOS6 and Mac OS X:

* In general, the keyboard handling works very good. Everything I've been able
to test works as expected. 

* For this particular bug - the problem with KP_8 vs KP_Up - I've verified with
Wireshark that shift indeed cancels NumLock on CentOS6, and that KP_Up is sent.
However, on the server side, it is translated to "Up". NumLock is also off in
the session. This means that in applications such as Gedit, the behaviour is
not exactly like a local machine: NumLock+Shift+KP_8 will both move the cursor
up as well as mark the text, since the GTK mechanism of "treat Shift as Numlock
disabler instead of region marker" does not work in this case. But this is a
server side problem.
------- Comment #19 From cendio 2014-09-30 13:40:47 -------
The Windows platform has been tested as well. Only one minor problem:

* The PrtScr/SysRq key does not work as expected: Sends XK_Print only when Alt
is pressed; nothing without modifiers.
------- Comment #20 From cendio 2014-09-30 17:10:57 -------
(In reply to comment #19)
> The Windows platform has been tested as well. Only one minor problem:
> 
> * The PrtScr/SysRq key does not work as expected: Sends XK_Print only when Alt
> is pressed; nothing without modifiers.

Urgh. That key was very magical. Should be fixed in r29441.

Bonus points for testing pressing/releasing Alt+PrtScr in different orders as
the damn thing can end up sending different scan codes on press and release.
------- Comment #21 From cendio 2014-10-06 15:01:06 -------
(In reply to comment #20)
> (In reply to comment #19)
> > The Windows platform has been tested as well. Only one minor problem:
> > 
> > * The PrtScr/SysRq key does not work as expected: Sends XK_Print only when Alt
> > is pressed; nothing without modifiers.
> 
> Urgh. That key was very magical. Should be fixed in r29441.
> 
> Bonus points for testing pressing/releasing Alt+PrtScr in different orders as
> the damn thing can end up sending different scan codes on press and release.

Works fine.
------- Comment #22 From cendio 2014-10-20 14:40:20 -------
On Windows, the first keypress is lost. Happens also for the F8 menu. Does not
happen with 4.2.0.
------- Comment #23 From cendio 2014-10-20 16:15:00 -------
(In reply to comment #22)
> On Windows, the first keypress is lost. Happens also for the F8 menu. Does not
> happen with 4.2.0.

Only happens on full screen. Keyboard grab is not relevant though.

Turns out this is an old bug in FLTK. We have a workaround in vncviewer for it,
but it is no longer effective with the new keyboard code. And it doesn't seem
like another workaround can be applied. So we need to fix the original bug.
------- Comment #24 From cendio 2014-10-20 17:32:38 -------
Fixed in r29523.
------- Comment #25 From cendio 2014-10-21 13:49:31 -------
(In reply to comment #24)
> Fixed in r29523.

Works.