Bug 436318 - Mouse no longer active after vnc to vnc-server with powersave active
Mouse no longer active after vnc to vnc-server with powersave active
Product: Fedora
Classification: Fedora
Component: vnc (Show other bugs)
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-03-06 09:47 EST by Mike C
Modified: 2013-04-30 19:38 EDT (History)
1 user (show)

See Also:
Fixed In Version: vnc-server-4.1.2-24.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-04 06:50:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike C 2008-03-06 09:47:27 EST
Description of problem:Machine A is running vnc-server in FC7 and the
screensaver is running under kde. Machine B running F8 makes a vnc connection
via ssh tunnel to machine A. Machine B then disconnects from A.  Now the screen
no longer wakes up if the mouse on machine A is moved. The machine needs to be 

Version-Release number of selected component (if
applicable):vnc-server-4.1.2-19.fc7 and vnc-4.1.2-23.fc8

How reproducible:Every time

Steps to Reproduce:
1. Make vnc connection from F8 machine to FC7 machine via ssh tunnel
2. Do stuff and then disconnect from FC7 machine
3. FC7 machine no longer has its mouse active. Alt-Ctrl Backspace does not stop
the X session, and Ctrl-Alt Fn does not work either. However if the vnc
connection is re-established via an ssh tunnel it is seen that the kde desktop
is still there on teh vnc-server machine as before, and work can be done via the
vnc connection on the server machine. 
Actual results:Mouse and keyboard no longer active on the vnc-server machine.

Expected results:Mouse and keyboard should remain active on the machine even if
another user connects to it via vnc through an ssh tunnel.

Additional info:No pertinent messages appear in the /var/log/messages file. Also
this has been tested with different physical machines acting as A and B in the
above description - all are yum updated to the present. It is the same for
different screensavers running in the vnc-server machine.

Additionally ssh'ing in and doing telinit 3, followed by telinit 5 does not fix
the problem either and a re-boot is necessary.
Comment 1 Adam Tkac 2008-03-12 14:04:10 EDT
Are you using Xvnc (= vncserver) or libvnc.so module to Xorg? Would it be
possible tell me how you setup ssh tunnel, please? (ssh -X or -via parameter)
Comment 2 Mike C 2008-03-12 17:10:53 EDT
OK what I do is as follows:

On the machine that acts as the vnc server I add a section in xorg.conf like:
Section "Module"
        Load  "vnc"

and also in the "screen" section there is a password line added like:
Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     24
        Option      "passwordFile" "/opt/local/etc/vnc/passwd"
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes    "1680x1050" "1280x1024" "1024x768" "800x600"

That machine is booted to runlevel 5 and nothing further needed there.

In the client machine I have entries in .ssh/config such as 

Host farend
#next line when port forwarding for ssh changes from 22 to 23456
Port 23456
ForwardAgent    yes
Hostname        farend.specialhost.co.uk
LocalForward    55900 localhost:5900

So in one terminal window I then:
ssh farend
and this sets up the tunnel with port forwarding from local 55900 to remote 5900

Then I have a script which is run in a second terminal window that essentially does
vncviewer -passwd ~/.vnc/passwd localhost:55900

Then this gives a vnc window to the server machine via the tunnel even if the
remote user has not yet logged in provided X on the server is running.

I hope this helps.
Comment 3 Mike C 2008-03-19 08:14:22 EDT
I have now tested this problem with new version vnc-server-4.1.2-19.3.fc7 and
this version now also fixes the bug reported above. Once the new version is
pushed to stable this bug can be closed also. Please also build for F8.

Comment 4 Adam Tkac 2008-03-19 08:22:10 EDT
(In reply to comment #3)
> I have now tested this problem with new version vnc-server-4.1.2-19.3.fc7 and
> this version now also fixes the bug reported above. Once the new version is
> pushed to stable this bug can be closed also. Please also build for F8.

Yes, fix is going to be included in next F8 update. Are you sure that new
version solves problem? I wonder if yes.
Comment 5 Mike C 2008-03-19 09:29:04 EDT
Yes, certainly on my test (vnc-server) machine here running F7 the new version
retains mouse control on that machine even if the client connects via vnc and
then disconnects again, when the server had already gone into powersave mode. I
checked three times and it gives normal operation after vnc'ing in and
disconnecting - the machine running vnc-server still has normal mouse/keyboard
response, and will come out of powersave mode in the same way as if there had
not been any vnc activity. Until this new version that was not the case. So this
new version seemed to have fixed this problem.
I do have access to another machine which is running F7 also and I could try to
test the new version of vnc-server there as well.

I will test on that second machine and let you know the outcome. 
Comment 6 Mike C 2008-03-19 11:25:33 EDT
I have now conducted tests on the second machine running vnc-server-4.1.2-19.3.fc7.

The local user in that machine now retains mouse/keyboard function even if I vnc
in whilst that machine is in powersave mode.

I will test that machine again later this evening, but this does look like the
problem reported in this bz is also resolved which is excellent given that the
fix was done for a different bug! (
https://bugzilla.redhat.com/show_bug.cgi?id=430468 )
Comment 7 Adam Tkac 2008-03-19 11:36:12 EDT
Interesting. Closing as duplicate of #430468 because it is same problem. Update
will be available soon (vnc-4.1.2-20.fc7 and vnc-4.1.2-24.fc8)

*** This bug has been marked as a duplicate of 430468 ***
Comment 8 Mike C 2008-03-19 11:50:09 EDT
I have tested this further - and it appears my earlier enthusiasm was misplaced.

By leaving the vnc-server machine running for a much longer time, and then
vnc-ing in then brings in the same symptoms as reported in the initial report of
this bug.

So the new version does not fix this issue and more work is needed for this.

Sorry for writing in too early before - I clearly got too excited that it was fixed!
Comment 9 Mike C 2008-03-19 11:58:18 EDT
Sorry Adam but am re-opening this one.
Comment 10 Mike C 2008-03-19 12:04:06 EDT
I am wondering if there are any specific tests I can run which will provide more
information about why this bug is occuring? There is nothing in /var/log/messages.
I can run tests tomorrow and then after Monday if you can suggest specific
things I may be able to do to get log files with something in them.  Is there a
way to get some backtraces which might help for example?
Comment 11 Mike C 2008-03-19 13:16:20 EDT
I would like to run vnc tests on two machines that I have that are both running
F8 and are both in the same room, so that I can be the "local" user on both
machines with one being vnc client and the other vnc-server. When the build for
f8 has completed I will then be able to run any suggested tests in the evenings
here on almost any day. 

Also is there any way to nail down whether this problem is purely vnc, or xorg -
clearly this manifests itself when using vnc but is it possible this is throwing
up an X problem?  If you can suggest something I can do to help diagnose this I
would be happy to help further as this bug has been there quite a while and I
want to be able to help find where the problem is.

The bz #430468 is definitely fixed even though this one is not.
Comment 12 Mike C 2008-03-19 15:47:30 EDT
I have run some additional tests for three different combinations of hardware,
and find that the problem reported here is hardware dependent!

I am running the vnc client machine with your new f8 version (vnc-4.1.2-24.fc8)
and connecting to three different machines as vnc-server. The results in this
case are as follows:

Case 1)
For the vnc-server machine with hardware profile:
and running vnc-server-4.1.2-19.3.fc7
This problem does not appear - although it was a problem when I first entered
this bug report. The recent version of vnc-server does seem to have resolved it
for this machine.

Case 2)
For the vnc-server machine with hardware profile:
and running vnc-server-4.1.2-24.fc8
This problem does not appear - though I did not test for this bug on this
hardware until now.

Case 3)
However for the machine with hardware profile which I have to list below
(since it gives errors connecting to the smolt server):
        OS: Fedora release 7 (Moonshine)
        Default run level: 5
        Language: en_US.UTF-8
        Platform: i686
        BogoMIPS: 3201.10
        CPU Vendor: AuthenticAMD
        CPU Model: Unknow CPU Type
        Number of CPUs: 1
        CPU Speed: 1599
        System Memory: 748
        System Swap: 1004
        System: MS-6378
        Form factor: desktop
        SELinux Enabled: False
        SELinux Policy: targeted
        SELinux Enforce: Disabled

                (4131:34048:4131:34048) pci, cyblafb, VIDEO, CyberBlade/i1
                (None:None:None:None) platform, i8042, None, Platform Device (i8042)
                (None:None:None:None) platform, pcspkr, None, Platform Device
                (None:None:None:None) scsi, sr, None, SCSI Device
                (None:None:None:None) input, Unknown, MOUSE, Macintosh mouse
button emulation
                (None:None:None:None) scsi, sd, None, SCSI Device
                (4358:12376:4358:12376) pci, VIA 82xx Audio, AUDIO, VT82C686
AC97 Audio Controller
                (None:None:None:None) platform, Unknown, None, Platform Device
                (None:None:None:None) input, Unknown, None, Sleep Button (CM)
                (None:None:None:None) input, Unknown, None, Power Button (CM)
                (None:None:None:None) input, Unknown, None, Power Button (FF)
                (4358:45330:0:0) pci, Unknown, OTHER, VT8361 [KLE133] AGP Bridge
                (4358:12344:2341:4660) pci, uhci_hcd, USB, VT82xxxxx UHCI USB
1.1 Controller
                (None:None:None:None) net, Unknown, NETWORK, Networking Interface
                (None:None:None:None) tty, Unknown, None, 16550A-compatible COM port
                (None:None:None:None) platform, Unknown, None, Platform Device
                (None:None:None:None) platform, serial8250, None, Platform
Device (serial8250)
                (None:None:None:None) input, Unknown, None, PC Speaker
                (4358:1670:4358:0) pci, parport_pc, OTHER, VT82C686 [Apollo
Super South]
                (4358:1393:4358:1393) pci, pata_via, IDE,
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE
                (None:None:None:None) scsi_host, Unknown, None, SCSI Host Adapter
                (None:None:None:None) pnp, serial, None, 16550A-compatible COM port
                (None:None:None:None) serio, psmouse, None, i8042 AUX port
                (4358:12375:4358:12375) pci, Unknown, OTHER, VT82C686 [Apollo
Super ACPI]
                (None:None:None:None) usb_device, Unknown, None, USB Raw Device
                (4358:12344:2341:4660) pci, uhci_hcd, USB, VT82xxxxx UHCI USB
1.1 Controller
                (None:None:None:None) input, Unknown, MOUSE, PS/2 Generic Mouse
                (None:None:None:None) usb_device, Unknown, None, USB Raw Device
                (4358:12562:0:0) pci, agpgart-via, OTHER, VT8361 [KLE133] Host
                (None:None:None:None) input, Unknown, KEYBOARD, AT Translated
Set 2 keyboard
                (32902:4649:32902:80) pci, e100, NETWORK, 82557/8/9 [Ethernet
Pro 100]
                (None:None:None:None) scsi_generic, Unknown, None, SCSI Generic
                (None:None:None:None) platform, Unknown, None, Platform Device
                (None:None:None:None) serio, atkbd, None, i8042 KBD port
                (None:None:None:None) scsi_host, Unknown, None, SCSI Host Adapter
                (None:None:None:None) pnp, i8042 kbd, None, IBM Enhanced
(101/102-key, PS/2 mouse support)
                (None:None:None:None) pnp, i8042 aux, None, PS/2 Port for
PS/2-style Mice
                (None:None:None:None) platform, via686a, None, Platform Device
                (None:None:None:None) scsi_generic, Unknown, None, SCSI Generic

        Filesystem Information
                device mtpt type bsize frsize blocks bfree bavail file ffree favail
                /dev/root / ext3 4096 4096 2519727 1492832 1467261 1294336
1181671 1181671
                /dev/sda8 /home ext3 4096 4096 4032159 1258176 1053348 2052288
1919541 1919541

and running vnc-server-4.1.2-19.3.fc7

This does give the problems listed at the start of this bug report.

It is therefore possible that the bug will only manifest itself on specific
machines and is likely to be absent on others.

Therefore I wonder if there are other users who might be able to verify this
behaviour apart from me?  if not then I now only have one machine on which this
appears to be a problem.

What do you advise? If there are no reports to confirm this for other people's
machines then maybe it is only the machine in case 3 above that has this problem
in which case it may be better to close this bug as can't fix?
Comment 13 Adam Tkac 2008-03-20 06:01:06 EDT
I still don't have enough time to look onto this one deeper. This might be
driver problem but it looks like vnc problem for me. I'm going to try figure
what's going on next week.
Comment 14 Mike C 2008-03-20 09:52:17 EDT
I ran another set of tests on the one machine (case 3 above) that was displaying
the problem after installing the new vncserver.... with the stock version of vnc
client on an f8 machine making the connection as client the problem did appear.
 However when I updated that client machine to run 
and then connected to the problematic vnc server machine running
vnc-server-4.1.2-19.3.fc7 then the problem went away!

I don't understand why changing the client to your new version should make a
difference but it seems to have done this for that case.

I will check this again later today but this does look now that if both the
machines concerned are running your new code that this resolves this bug.

I am now in a position where all my client and server machines now behave
perfectly well with all machines running your new versions (-24 in f8).
Comment 15 Mike C 2008-03-26 14:25:22 EDT
With -20 in f7 and -24 in F8 vnc/vnc-server has been stable without further
Comment 16 Mike C 2008-04-04 06:49:09 EDT
After #15 I have not seen any further recurrence of the symptoms of this bug so
I am closing it as fixed in the current release.

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