Bug 828614

Summary: When Num Lock is on, number keys on keypad should produce numbers
Product: [Fedora] Fedora Reporter: Tim Taiwanese Liim <tim.liim>
Component: tigervncAssignee: Tim Waugh <twaugh>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: ovasik, pcfe
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 08:44:32 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Tim Taiwanese Liim 2012-06-04 22:31:38 EDT
Description of problem:
    When Num Lock is on, number keys on keypad should produce numbers,
    eg. key "4" should produce the keysym KP_4, not KP_Left.  However,
    in many cases (50%), the key "4" produces KP_Left (wrong) even
    when Num Lock is on.

    The problem arises because the vncserver keeps its own Num Lock
    status, while vncviewer is affected by the X server ("host X")
    where it is running.  When the Num Lock of vncserver and the Num
    Lock of host X is compatible (not necessarily the same, see
    "Additional Info" item #2), "4" produces KP_4 (good, desired).
    When they are incompatible, "4" produces KP_Left even when Num
    Lock is on.

    How to toggle between the good and bad state?  When vncviewer is
    in focus, the Num Lock event is transmitted to vncserver, then to
    Xvnc.  But when vncviewer is out of focus, the Num Lock change
    event is *not* passed to Xvnc, thus they could be out of sync.
    This brings us in and out of the bad state.

    Possible fix:
    In the file unix/xserver/hw/vnc/Input.cc, we have
        void InputDevice::keyEvent(rdr::U32 keysym, bool down) {
            ...
            if (keysym == XK_Caps_Lock) {
                    vlog.debug("Ignoring caps lock");
                    return;
            }
    Perhaps we can do the same for Num Lock?  I tried it and it seems
    to be working fine.

Version-Release number of selected component (if applicable):
    tigervnc-1.1.0-5.fc17.x86_64

How reproducible:
    always, if you know how to toggle beteween the good and bad state.

Steps to Reproduce:
    1. on F17, start vncserver
    2. on F17, start vncviewer; start an X app (eg. gnome-terminal or
       keysym.tk in "Additional Info" item #1).
    3. turn off Num Lock on the host X.
    4. in the vncviewer, press and release the key "4" on the keypad.
    5. Make vncviewer out of focus, then toggle Num Lock to on.  So
       the state of Num Lock on Xvnc and that on host X is out of
       sync.
    6. in the vncviewer, press and release the key "4" on the keypad.

Actual results:
    When Num Lock is on at the host X side, Xvnc generates KP_Left at
    step 6.

Expected results:
    Xvnc should generates KP_4 instead of KP_Left.

Additional info:
  1. For reading keysym, I used the following keysym.tk.  Any X app
     that prints keysym of key events should do, but TK is easier to
     use.
        #!/usr/bin/wish
        message .msg -width 8c -justify left \
            -font "-adobe-courier-*-24-240-75-75-m-150-*" -text "this is a test"
        bind all <Any-KeyPress>   { puts "keyPress   the keysym is %K" }
        bind all <Any-KeyRelease> { puts "keyrelease the keysym is %K" }
        pack .msg

  2. It seems that if we keep Num Lock on Xvnc always off, we would
     get the desired behavior.  The following table is obtained by
     experiment.  Note that when both host X and Xvnc think Num Lock
     is on (ie. their state is in sync), the behavior is wrong.

     ---------------------------------------------------------------------- 
     on host X                  numLock off, shift off 
     on Xvnc                    numLock off, shift off 
     ---------------------------------------------------------------------- 
                                press                   release            
     seen by host X app         KP_Left down            KP_Left up 
     seen by SMsgReader         KP_Left down            KP_Left up 
     vncserver sends            shift up (nop)  
                                key 83 down             key 83 up 
     seen by Xvnc app           KP_Left down            KP_Left up 
     reaction on terminal       cursor left (correct) 
 
     ---------------------------------------------------------------------- 
     on host X                  numLock on, shift off 
     on Xvnc                    numLock on, shift off 
     ---------------------------------------------------------------------- 
                                press                   release            
     seen by host X app         KP_4 down               KP_Left up 
     seen by SMsgReader         KP_4 down               KP_4    up      <-- vncviewer corrected KP_4 up 
     vncserver sends            shift down              shift up        <-- extraneous shift down/up 
                                key 83 down             key 83 up 
     seen by Xvnc app           Shift_L down            Shift_L up 
                                KP_Left down            KP_Left up 
     reaction on terminal       ^[[1;2D (wrong, should be "4") 
 
     ---------------------------------------------------------------------- 
     on host X                  numLock off, shift off 
     on Xvnc                    numLock on,  shift off 
     ---------------------------------------------------------------------- 
                                press                   release            
     seen by host X app         KP_Left down            KP_Left up 
     seen by SMsgReader         KP_Left down            KP_Left up 
     vncserver sends            shift up (nop) 
                                key 83 down             key 83 up 
     seen by Xvnc app           KP_4 down               KP_Left up 
     reaction on terminal       "4" (ok from Xvnc point of view, wrong from host X point of view) 
 
     ---------------------------------------------------------------------- 
     on host X                  numLock on,  shift off 
     on Xvnc                    numLock off, shift off 
     ---------------------------------------------------------------------- 
                                press                   release            
     seen by host X app         KP_4 down               KP_Left up 
     seen by SMsgReader         KP_4 down               KP_4    up      <-- vncviewer corrected KP_4 up event 
     vncserver sends            shift down              shift up 
                                key 83 down             key 83 up 
     seen by Xvnc app           Shift_L down            Shift_L up 
                                KP_4    down            KP_Left up 
     reaction on terminal       "4" (wrong from Xvnc point of view, ok from host X point of view)
Comment 1 Patrick C. F. Ernzer 2013-02-07 06:50:13 EST
Adam,

would this bug also apply to caps lock or should I open a separate bug for the situation where I sometimes end up with caps lock on in a vnc session and no way to turn it off (probably because both the server and the client actually have compose on the caps lock key)?
Comment 3 Fedora Admin XMLRPC Client 2013-05-13 10:54:57 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora End Of Life 2013-07-04 00:07:38 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 Fedora End Of Life 2013-08-01 08:44:39 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.