Comment 1 Peter Åstrand 2013-06-03 15:00:16 CEST

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 Pierre Ossman 2013-06-04 11:06:15 CEST

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 Pierre Ossman 2013-08-30 10:50:48 CEST

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 Pierre Ossman 2013-08-30 11:00:52 CEST

(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 Pierre Ossman 2014-02-06 11:10:44 CET

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 Pierre Ossman 2014-02-06 11:11:25 CET

Consider bug 4984 and bug 4971 when writing the new code.

Comment 7 Pierre Ossman 2014-08-21 17:38:38 CEST

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 Pierre Ossman 2014-08-22 11:55:18 CEST

(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 Pierre Ossman 2014-08-22 13:56:28 CEST

(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 Pierre Ossman 2014-08-22 14:21:51 CEST

(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 Pierre Ossman 2014-08-22 15:19:06 CEST

I have something that works well now. Available here:

https://github.com/CendioOssman/tigervnc/tree/xhandlers

Comment 13 Pierre Ossman 2014-09-15 13:28:32 CEST

FLTK patches committed upstream and in cenbuild.

Comment 14 Pierre Ossman 2014-09-15 13:59:43 CEST

Vendor drop of TigerVNC in r29365.

Comment 15 Pierre Ossman 2014-09-16 16:21:54 CEST

AltR is sent as AltL from Windows. Need to have a look at that.

Comment 16 Pierre Ossman 2014-09-17 10:32:46 CEST

(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 Pierre Ossman 2014-09-18 14:46:55 CEST

All done.

Test instructions are available as vnc/tigervnc/doc/keyboard-test.txt.

Comment 18 Peter Åstrand 2014-09-29 13:05:55 CEST

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 Peter Åstrand 2014-09-30 13:40:47 CEST

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 Pierre Ossman 2014-09-30 17:10:57 CEST

(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 Peter Åstrand 2014-10-06 15:01:06 CEST

(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 Peter Åstrand 2014-10-20 14:40:20 CEST

On Windows, the first keypress is lost. Happens also for the F8 menu. Does not happen with 4.2.0.

Comment 23 Pierre Ossman 2014-10-20 16:15:00 CEST

(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 Pierre Ossman 2014-10-20 17:32:38 CEST

Fixed in r29523.

Comment 25 Peter Åstrand 2014-10-21 13:49:31 CEST

(In reply to comment #24)
> Fixed in r29523.

Works.