935 2011-03-28 01:14:41 +0000 Keyboard do not work properly when there is a vnc client connection 2011-08-22 16:08:36 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-configuration 1.0 Blacksand x86_64 RESOLVED NOTABUG scheduled for completion on or before 1.1 M4 RC1 (Sept 6) Medium normal 1.1 1 xudong.hao tom.zanussi jiajun.xu kunwei.tian sgw yp.bsp.watcher yp.watcher --- --- --- oldest_to_newest 13005 0 xudong.hao 2011-03-28 01:14:41 +0000 Image location: http://autobuilder02.yoctoproject.org/sugarbay-bernard/nightly/20110326-1/machines/sugarbay/x86_32/poky-image-sato-sdk-live-sugarbay-20110327030158.hddimg.bz2 commit: 8b6416db1e04af83ecdf57522240ac859d5d8031 On blacksand and Sugarbay with BSP image installed, start a VNC server, then prepare a client system, and connect the yocto system by vncviewer in client. Both on server terminal console and client console, press any "key" (such as "m") of the keyboard device for a long time, there was only one "key" (only one "m" ) printed in console. Reproduce steps: =============== 1) install BSP image on sugarbay and boot to yocto system A 2) start vnc server with command: "x11vnc -display :0.0" 3) re-open a terminal console, and press "m" for a long time, there will be many "m" printed 4) in a system B, connect system A by vncviewer 5) do step3, there will be only one "m" printed 6) stop vncserver, then do step3, there will be many "m" printed Influence: =============== In terminal console, if we need to modify or delete a exist command, we need to click "Backspace" one by one. 13006 1 bruce.ashfield 2011-03-28 06:11:06 +0000 Tom: any ideas for this one ? It doesn't look BSP specific, so if there's nothing obvious we can try and get more help on this. 13030 2 tom.zanussi 2011-03-29 08:08:45 +0000 (In reply to comment #1) > Tom: any ideas for this one ? It doesn't look BSP specific, so if there's > nothing obvious we can try and get more help on this. Yes, I would agree - it doesn't look BSP-specific. 13069 3 sgw 2011-03-31 10:21:34 +0000 Looking at this, we need to confirm if it fails without VNC server running. Also does if fail if we are in text mode (non-graphical), by running the minimal image and testing there. That will give us more hints as to where the problem might be. Please verify without VNC and on a text console, if those work, then the problem is with VNC not the BSP. 13085 4 xudong.hao 2011-03-31 20:13:28 +0000 (In reply to comment #3) > Looking at this, we need to confirm if it fails without VNC server running. > Also does if fail if we are in text mode (non-graphical), by running the > minimal image and testing there. That will give us more hints as to where the > problem might be. > Please verify without VNC and on a text console, if those work, then the > problem is with VNC not the BSP. Double checked and make it clear here: 1) in text mode of SDK image, everything works fine. 2) boot with minimal BSP image, everything works fine. 3) in X mode of SDK image, without VNC server running, everything works fine. 4) in X mode of SDK image, start VNC server, everything works fine; then connect with vncviewer from another machine, failure happen; disconnect vnc, everything become fine. 5) in X mode of SDK image, start VNC server and connect with vncviewer from another machine, failure happen on X mode; if we change to text mode with "Ctrl+Alt+F1", everything become fine. So this issue only happen on a X mode with a VNC connection. 15641 5 tom.zanussi 2011-08-22 16:08:36 +0000 This is expected behavior. The default setting is -norepeat, which turns off autorepeat on the X server to guard against misbehaving clients. If 5 minutes have passed with no activity from the client, the normal X server autorepeat is turned back on, on the assumption that the only user is local. From the x11vnc stdout, we can see X server key autorepeat being turned on a off, at which point, the keypresses on the server do repeat: 22/08/2011 21:24:40 Disabled X server key autorepeat. 22/08/2011 21:24:40 to force back on run: 'xset r on' (3 times) 22/08/2011 21:25:21 Restored X server key autorepeat to: 1 So I'm closing this - I don't see why we wouldn't go with the more conservative setting - users can always turn autorepeat on the server back on using the 'xset r on' command described in the message above, or wait 5 minutes after no activity from the client. From x11vnc --help: -norepeat Option -norepeat disables X server key auto repeat when -repeat VNC clients are connected and VNC keyboard input is not idle for more than 5 minutes. This works around a repeating keystrokes bug (triggered by long processing delays between key down and key up client events: either from large screen changes or high latency). Default: -norepeat You can set the env. var. X11VNC_IDLE_TIMEOUT to the number of idle seconds you want (5min = 300secs). Note: your VNC viewer side will likely do autorepeating, so this is no loss unless someone is simultaneously at the real X display. Use "-norepeat N" to set how many times norepeat will be reset if something else (e.g. X session manager) undoes it. The default is 2. Use a negative value for unlimited resets.