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)

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"
EndSection

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"
        EndSubSection
EndSection

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.

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.

Thanks
Mike

(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.

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. 

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 )

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 ***

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!

Sorry Adam but am re-opening this one.

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?

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.

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:
http://www.smolts.org/client/show/pub_21298b78-3386-45f0-8f1b-80fccf545429
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:
http://www.smolts.org/client/show/pub_d3106a99-890c-4da2-a911-d4f78b5cd818
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
        Vendor: MICRO-STAR INTERNATIONAL CO., LTD
        System: MS-6378
        Form factor: desktop
        Kernel: 2.6.23.15-80.fc7
        SELinux Enabled: False
        SELinux Policy: targeted
        SELinux Enforce: Disabled

                 Devices
                =================================
                (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
(pcspkr)
                (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
(bluetooth)
                (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
(vesafb.0)
                (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
Access
                (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
Access
                (4358:12562:0:0) pci, agpgart-via, OTHER, VT8361 [KLE133] Host
Bridge
                (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
Interface
                (None:None:None:None) platform, Unknown, None, Platform Device
(floppy.0)
                (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
(via686a.24576)
                (None:None:None:None) scsi_generic, Unknown, None, SCSI Generic
Interface

        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?

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.

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 
vnc-4.1.2-24.fc8
vnc-libs-4.1.2-24.fc8
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).

With -20 in f7 and -24 in F8 vnc/vnc-server has been stable without further
problems.

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.