terminal server client disables mouse on desktop

Bug #288868 reported by Alex Lopez
58
This bug affects 8 people
Affects Status Importance Assigned to Milestone
tsclient (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: tsclient

Intrepid beta:

When you are connecting to remote desktop, if you leave the cursor on destination computer field and click on connect, the field keeps blocked, and mouse does not work neither on remote desktop windows, neither in the rest of the desktop. You need to close with keyboard to recover mouse control.
If cursor is not on the field, the problem does not appear.

Alex Lopez (alfitovdkiv)
description: updated
Revision history for this message
Chad Wollenberg (chad-cwolly) wrote :

Confirmed. This locks up the desktop and renders the mouse unusable. I am having this issue in RC. Being that many people rely on tsclient to do their work, I would say this one is pretty important.

There is a white box that shows up when this happens, and you cannot get rid of it. I would attach a screen shot, but I can't take one with everything frozen up.

Changed in tsclient:
status: New → Confirmed
Revision history for this message
Mike Basinger (mike.basinger) wrote :

Confirmed in Ubuntu 8.10 final. Happens with compiz on or off.

Revision history for this message
justin (jlintz) wrote :

Confirmed this in 8.10 final as well, only solution I have so far is hitting ctrl-alt-f1 and killing tsclient, then going back to X with ctrl-alt-f7.

Revision history for this message
Mike Basinger (mike.basinger) wrote :

Installing the NVidia 173 driver or the Nvidia 177 driver in intrepid-proposed fixed the problem for me.

Revision history for this message
d1prince1 (dan-w-prince) wrote :

I am also experiencing this issue with a clean install of Intrepid. I am using the Nvidia 177 driver. I have found that after typing in the ip address if I hit tab a few times before connecting I do not have this issue. From what I can tell the box appears over the protocol selection field (however it appears to be offset from the actual field.)
I have not experienced full system freeze due to this, only loss of mouse within the remote desktop window, keyboard still works in the remote desktop.
I'm not sure if it matters but I leave the protocol set to the default of rdpv5.

Revision history for this message
Sam Snow (snood-deactivatedaccount) wrote :

Ubuntu 8.10, tsclient 0.150, nVidia 177 driver, compiz

I am seeing the loss of mouse (but not keyboard) functionality in the remote Windows session and in the local session (Ubuntu 8.10). I also see what appears to be an floating field / data entry box -- almost as though two tsclient instances were started but one wasn't "painted" completely.

I use Alt-F4 to log off the remote Windows session, then quit tsclient completely. (Requires two clicks on Close button. First click kills the "floater", and the second click kills tsclient.) After that, tsclient works as it should -- until I restart either the Ubuntu session or the remote Windows box. If I do that, I'm back to square one.

Revision history for this message
liegerm (dcaldwell-liegerm) wrote :

I'm seeing exactly the same issue as Sam Snow. Using nVidia 177 driver with Compiz off on Ubuntu 8.10 final.

Revision history for this message
Todd Morgan (tubatodd) wrote :

Ubuntu 8.10, Intel GMA 965 Driver, Compiz

I can confirm that this happens for me too. It happens about 60+% of the time. The mouse stops working, but the keyboard allows me to log back out of the remote machine and then close the tsclient application.

Revision history for this message
Mike Basinger (mike.basinger) wrote :

The fix listed by myself does not work always.

Revision history for this message
Mike Basinger (mike.basinger) wrote :

It is a problem with tsclient, if I goto another tty and kill tsclient, the rdesktop session it start responds fine.

Revision history for this message
Toni Rosa (toni-rosa) wrote :

It happens here too.
Ubuntu 8.10 64bit, Ati Radeon Mobility X1600, and xorg-driver-fglrx.
Some time just pressing "esc" rdesktop disconnects, and some others I have to "Ctrl-alt-F1" and "killall tsclient"

Revision history for this message
JeSTeR7 (cblocker) wrote :

Here is a screenshot of what happens to me when I leave the "Computer" field highlighted and just hit enter. I get the same symptoms as above, but my history stays on the screen.

This does not occur if you simply click "Connect" or tab to another field and hit the enter key.

Revision history for this message
CharleyS (charley-socci-com) wrote :

Also happens to me.

2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux

NVidia 177

I also just installed the linux backports modules for intrepid to fix the Intel 4965 iwlagn i kernel panic problems... I don't know if that has any bearing... this is a brand new install.

Revision history for this message
Andrew (adhenry) wrote :

damn it. I was having the same problem, and saw the post above about killing tsclient, and thought that would solve the problem.

However, I had just uninstalled the nVidia proprietary driver and installed the free nv driver because I was having performance problems on my desktop and wanted to see if they were caused by the driver. So there I was running the nv driver, and I started vnc via tsclient to test out the above tip, and what do you know!! It didn't crash! Seems like this problem is possibly caused by the nVidia driver, which is a real bummer because it's the only way of getting suspend to ram to work :(

Seems like I had the opposite effect to others here, but now my VNC works fine with nv driver. Just one more comment: tsclient VNC has ALWAYS worked for me to another computer: a CentOS 5.2 server. Now I tried to VNC to Ubuntu Server 8.10 and it was only this that was hanging... CentOS was still working fine.

Revision history for this message
Chad Wollenberg (chad-cwolly) wrote :

This bug doe not have anything to do with graphics drivers. I've had the bug on 4 different machines using all different graphics cards, and currently on an ATI graphics cards using mesa.

This problem can be easily bypassed by making sure the cursor is NOT in the computer field when you connect. If you do connect by mistake, you can tab around and cancel the session. The keyboard still works, it just locks up the mouse.

Even though this is a workaround, this is still something that really needs to be fixed.

Revision history for this message
Christian Kirbach (christian-kirbach-e) wrote :

problem is definitely unrelated to graphics drivers, I see this on three different machines.

Revision history for this message
Andrew (adhenry) wrote : Re: [Bug 288868] Re: terminal server client disables mouse on desktop

Christian Kirbach wrote:
> problem is definitely unrelated to graphics drivers, I see this on three
> different machines.
>
>
Ok, maybe it is unrelated, but I uninstalled nvidia driver 177 and used
the nv driver and it worked. Then I re-installed nvidia driver 177 and
it still works, consistently. That is strange even if the problem is
not graphics related, isn't it? Now I have tried a VNC session over 10
times between reboots and it has not crashed at all, no matter whether
the mouse pointer is outside or inside the eventual VNC window.

Revision history for this message
Mick K (mjkemsley) wrote :

Andrew, are you pressing "Enter" key to connect or clicking the mouse on the Connect button?

It appears to only occur when Computer field is focused and Enter is pressed

Revision history for this message
Andrew (adhenry) wrote :

Korax wrote:
> Andrew, are you pressing "Enter" key to connect or clicking the mouse on
> the Connect button?
>
> It appears to only occur when Computer field is focused and Enter is
> pressed
>
>
I press the Connect button, but then I get a small password entry
dialogue where I type in the password for the VNC session.

Revision history for this message
Ghosty (ghosty.be) wrote :

Awful, a bug so stupid takes more than 2 months to fix?
It is seriously annoying ...
Also seen here with nvida card and compiz enabled ...
Did not have the issue with hardy ... (thinking of even downgrading to Gutsy, ever since hardy more and more of these stupid things occured and never seem to get fixed ...

Revision history for this message
Ghosty (ghosty.be) wrote :

nvidia and intel card that should have been*

Revision history for this message
Simone Tregnago (simonetregnago) wrote :

Ghosty, I'm sure that if you think that is so stupid you could provide a good patch shortly.
It's open source, collaborative. Feel free to correct the bug yourself: the community will appreciates your work.

Revision history for this message
Duane Chamblee (duanec-nc) wrote :

I downloaded the tsclient from sourceforge

http://sourceforge.net/projects/tsclient

and got it configured (had to remove gnome-desktop-2.0 files, and install some others)...
make and make install worked and I'm now using it.

No lockups so far.

Revision history for this message
8472 (dv-underworld) wrote :

confirmed.
same problem on my two (at work and home) ubuntu's too.

Revision history for this message
itaint3z (itaintezbeinrich) wrote :

Im using Feisty. Im pretty noobish but I was able to figure out that the white box that pops up is a blanked out terminal with which you cannot see the text that is supposed to be displayed. Im guessin if u enter your root password and press enter your operation that you were conducting will complete. This is the same problem I am having so hopefully it gets solved

Revision history for this message
xoroz (fferreira-osiatis) wrote :

Confirme for me as well.
I just installed a fresh Ubuntu Hardy 8.10 and I have this annoying bug.
Anyone knows another RDP client for linux? I really need it to work because I am all day connecting to remote servers.
I noticed If i am connected to one at a time it does not happen, only when I try to connect to a second server.
Then I I do CRTL-ALT-BCKSPACE login again and all works fine.
will remove tsclient, and compile from source. Could be a solution.
cheers,

Revision history for this message
max (mikhmv) wrote :

Confirm too. Intrepid and Jaunty.
some times even completely freeze Xserver.

Revision history for this message
Evans Tucker (evanstucker) wrote :

Same problem as everyone above. Hitting Alt-F4 closes the Terminal Server window and returns mouse click abilities.

Just out of curiosity, if I wanted to help out the open source effort, how would I go about solving this problem? How do I know whether or not someone else is already working on this? I don't want to spend a lot of time trying to figure it out only to discover that someone else already solved it. Do people take ownership of specific bugs and checkout the code with the intent of fixing them? If so, can members of the general public do this, or only people involved in this particular project? Has anyone written a "how to" somewhere for becoming an active member of the open source movement?

I'm mostly a scripter, but I can read and understand most code. Not sure how I would go about troubleshooting this issue though. Would one just run some sort of stack trace or something to begin troubleshooting a problem with an executable? Or would my first step be to download the source, compile, and then see where to go from there?

Revision history for this message
Andrew (adhenry) wrote :

I know that everyone has already told me that this is not a graphics driver
issue, but I'm telling you that uninstalling the Nvidia driver, and using
the open nv driver solved this issue for me. I then re-installed the nvidia
driver and it was still 'solved'.

Before anyone else tells me that im full of c**p, has anyone else tried
this?

Revision history for this message
itaint3z (itaintezbeinrich) wrote :

Switching from Ubuntu to Kubuntu fixed the problem for me.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.