Vino does not work with compositing

BTW, this but pertains to Natty because I just completed the upgrade and noticed there's no longer a functional workaround for the problem.

Same here, screen does not repaint and its very slow, unusable... a lot of times is needed to disconnect and connect back to be able to see the new repainted window.

As a side note, I have been looking for an alternative to this (I connect remotely a lot so I need for this to 'work') and found this solution:
I installed the software from http://www.nomachine.com and it actually works perfectly fast!! but it only seems to connect and gives the classic GNOME (this i what I am using) as the desktop once connected even thou you have the Unity desktop, it works kind of Remote Desktop for Windows. This software is free.
This one seems like a good alternative until Vino gets fixed.

@aa2k Nomachine NX is essentially an X server proxy.

I tried it too and experienced different results:

NX works perfectly fine and fast if you want to connect to the remote computer with a new session because it starts a new X session, but the "shadow" mode where you can connect to an existing desktop session on the remote machine is broken in the same way as Vino because it's just VNC with a different name.

Connecting and starting a new session defeats the purpose of a remote desktop session because it means you have to manually kill all of the apps that are running on your existing session, losing any unsaved work, then restart those applications under the new session.

So NX is not a workaround for broken Vino: Vino's intent is to allow one to connect to an existing session and that feature of NX does not work on Ubuntu with desktop effects on.

Josh, you are right and I agree with you but this is a good viable alternative for now seems like; as is, VNC (Vino) is unusable so we dont have that many choices (xrdp breaks some applets so not very good choice here either)... go back to 10.04, wait for a fix/patch or use something else for now...
I know there are not a lot volunteers working on VNC project for this and I understand they are very busy and dedicating their time to other issues more important than this, so for the moment this is a way to get in/control the Ubuntu system remotely - like you said, this is just like Remote Desktop but for now it would do the job, NX is not a workaround but just an alternative, many people can use this as such until a fix/patch is possible.
cheers!

> Josh, you are right and I agree with you but this is a good viable alternative for now

I think you missed the part where I explained how it's not a viable alternative.

> go back to 10.04

The problem manifested in the first release where Desktop Effects were included. It was fixed temporarily in 9.04 with a script that ran when a client connected that automatically disabled desktop effects, then re-enabled them upon disconnect. But in 9.1 someone forgot to include that workaround and since then the problem has existed in every release.

So going back to 10.04 is not a solution on the one hand in a world that doesn't exist where going back to a previous release of an operating system is a viable option to restore the functionality of an important feature; on the other, it's not a viable option because it doesn't fix the problem.

I don't see what you stand to gain by discounting my bug report but I don't see it as productive.

A solution is posted here: http://ubuntuforums.org/showpost.php?p=10775950&postcount=13

@jogibear9988 Toggling xdamage is not a solution or workaround. It causes the entire screen to refresh on every frame, which hammers the network and consumes a large amount of system resources.

Does anybody know about a good alternative? We work with this daily here and this is a real pain.

I've just done a reinstall of 10.04, and I'm having this problem too. In the past it has been sort of working, but not well. None of the 'solutions' are working for me. I use this feature a lot, especially to help friends who I've converted to Ubuntu, so it's very frustrating. I also use it to manage the majority of my computers, as they are headless, so this is becoming a real pain for me too. I appreciate that everyone is busy with fixing stuff for Unity, so directions to a viable and easy to configure alternative would be very much appreciated.

Hello guys,

 Using remote desktop to access Ubuntu desktop for a while I had to face the same issue with composition enabled. As a temporary workaround, for the time being, I use an application name TeamViewer (http://www.teamviewer.com/en/download/index.aspx). If it is not perfect, at least it copes well for me with the Unity desktop.

Hope this help. Regards.

I found that disabling Compiz with the command "metacity --replace" and then setting the screensaver to blank greatly alleviated my remote connection problems. The screensaver was causing some problems (probably my bad for choosing Electric Sheep), but I was usually able to restart the vino-server by "ssh -y user@ip" and then running "vino-preferences".

To be clear, this behavior is exhibited with other VNC clients as well. I am using JollyFastVNC Pro and have identical issues since upgrading to Natty.

Other solution is posted here (Install 2D Unity) http://digitizor.com/2011/04/25/install-unity-2d-ubuntu-11-04/

For me VNC works also using the Ubuntu Classic: No Effects mode.
This can be choose during the login phase.

Hope this helps

I agree with aa900 that using Ubuntu Classic No effects mode seems to help- I will say that when trying this overnight a few nights ago, by xsession-errors file grew to 45GB!! Now, I'm not sure if there is a causal relationship here, but I can tell that switching back to the "non-classic" view made this issue go away (but not Im back to not being able to use VNC)

Most of the errors listed in the huge error file were related to Nautilus, and this may be another instance of the bug listed: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/738203

This very much seems like a driver specific issue with the proprietary fglrx driver, see bug 353126.

Perhaps you can try with the free ati driver, and see whether it works better?

Not a new issue, most likely specific to fglrx (which we can't fix, as it's proprietary), so this is not a release blocker.

This is not a driver specific issue. I'am having this problem with both INTEL and NVIDIA video chips.

vino 2.32.1-0ubuntu2.1
kernel 2.6.38-8-generic x86_64

this lack of remote desktop support is very frustrating since most of my work is done from home and I can no longer have Ubuntu on my server machine due to the repaint problems in 11.04. I switched to using the 'Classic' desktop with no special effects and it was better. there where still occasional repaint problems. I had to remove Ubuntu and use another distribution.

based on Eric's comments, putting this back on the desktop team's radar to relook at.

Wow that only took six major revisions and three years.

I originally reported this in Intrepid in 2008 when Compiz was originally added to the repos. Since then it's gone through three years of "this isn't our responsibility" and "this can't be reproduced" and "this should be filed upstream."

I've lost count of how many bugs I've opened only to have them immediately closed by the surrounding "not my problem" field.

One more thing:

This is a huge, major feature that is totally and completely broken.

Isn't there something more we can do other than just gently placing it on the desktop team's radar?

Kind of seems like now that we're forced to use compositing in the default window manager this should be called a show stopper bug: We're rolling out an operating system with a major feature that is broken out of the box.

any update on this?

> any update on this?

Yes. I have run through testing this on various combinations of graphics cards and video drivers for both natty and oneiric while running Unity. In this testing I was able to reproduce the bug only with fglrx-installer and the old nvidia-173 proprietary drivers. The free drivers worked properly. The nvidia-current driver worked fine as well, even in natty.

Thus, I confirm Pitti's earlier statement that this is an fglrx specific bug.

As a next action for this bug, Canonical will escalate to AMD. There is insufficient time remaining for a fix to be included in oneiric, but we may be able to provide an updated driver via x-updates; as of oneiric jockey (aka 'Restricted Drivers') will be able to load driver updates from this repository.

No promises for earlier Ubuntu releases, however if we provide driver updates it will be via the x-updates PPA. Otherwise, you can download and manually install new drivers from AMD directly, but note these are not supported by Ubuntu.

Alternatively, the open source -ati driver supports the full range of ATI chipsets; it doesn't have as rich of 3D support as fglrx but it has sufficient support to run Unity reasonably well. So as another workaround you should be able to disable fglrx and run using just the open source driver.

Similarly, for those users on older NVIDIA hardware not supported by nvidia-current, the -nouveau driver is available, and as of oneiric also supports 3D unity. It also lacks the level of 3D support that the proprietary driver has, but is sufficient for running unity.

And of course, Unity-2D remains a suitable workaround.

We had also considered the option of dropping Vino from the distro entirely. However I think this is unnecessary; the bug seems localized to just certain video drivers, and there are multiple ways of working around it. I also am hopeful we can get a fix for fglrx in the not too distant future. This seems like a handy feature and would be a shame to lose it over what appears to be just a single driver bug.

I should add, it appears the xdamage gconf option has been removed from vino in oneiric, so I could not verify that resolves it. I did try testing it with nvidia-173 on natty, but it didn't seem to have an effect.

The free drivers are crap.

Ubuntu is a seriously awesome Linux distribution and a lot of people use it to introduce newbies to Linux.

We can't put our best foot forward with a broken remote desktop solution because nobody wants to accept responsibility for the problem.

If this was a tiny distro like Tiny Core things would be different, but Ubuntu is a multi-national corporation and there's just no excuse for this.

You guys need to get together with someone at AMD and work this problem out instead of just throwing up your hands and saying it's AMD's problem.

> You guys need to get together with someone at AMD and work this problem out instead of just throwing up your hands and saying it's AMD's problem.

Calm down, I'm trying to help you. Did you miss the part where I said, "Canonical will escalate to AMD"?

Bryce, I'm experiencing this very bug on a computer with the open source intel driver using gnome-shell. So this is definitely not specific to fglrx.

By the way, this is in Oneiric, and I am ready to do any test that can help you fix this bug.

I have the same problem with vino-server in an oneiric system with a ATI Video (ATI Technologies Inc RS880 [Radeon HD 4250]), but not running the fglrx proprietary driver. What I get is a session with sporadic updates - I can get the screen updated by wiping a terminal window around the screen. So I can confirm that this is not just an fglrx-specific bug.

Sorry, I'm unable to further reproduce this behavior after an update and reboot. Please withdraw the above comment.

I agree with Craig Hansen's original post, with an ATI card and fglrx wiped out and reverting to ati driver, still have the issue.

Remote desktop is hot feature of a modern os, i must start a vncserver(like separate session) to operate with my desktop , but is not an option for dummy user.

On several systems using ATI video and not using the fglrx propriety driver, and fresh installs, I am now experiencing the sporadic updates I first reported in comment #32. I am no longer seeing the remission that I reported in #33.

This bug report is *only* going to focus on the issue with -fglrx. If you're experiencing vino/compositing problems outside -fglrx please file a new bug report. It's not inconceivable that there are multiple unrelated problems with vino and video cards.

Bryce: the description of the bug is "Vino does not work with compositing". If this bug is only going to focus on the issue with fglrx, the description has to be changed to "FGLRX doesn't work with Vino". Else, it's getting comments and attention from people getting this bug with other video drivers.

I opened bug #915906 about the issue with ATI's open source driver.

And I've filed Bug #918815 about to the same issue with the Intel graphics driver.

@Pierre Fisher Can you please mark your bug duplicate or dependent on this one?

@Josh : Marking Bug #918815 (as well as Bug #915906) as a duplicate of this bug would be inconsistent with what Bryce wrote in message #37 here above. In any case the description of both bugs explicitly refer to this bug and makes them this way dependent on it. Is this OK or do you want something more explicit?

@Pierre You have good points there, thank you. I think we can keep things as they are based on what you've found.

I was able to get it to work after going into the ATI Catalyst control application and enabling the "tear free" option. I hope this works for others :)

Run the ATI Catalyst application (Admin Version) and turn on the "tear free" option. Problem is immediately resolved. YAY!!!

@Nicolas Seguin
Yes, it also works for me. Thanks.

I think it's not vino's fault, but the compositing manager.

I'm using x11vnc as the vnc server, and here's a part of its message.

29/04/2012 21:14:17 XDAMAGE is not working well... misses: 166/216
29/04/2012 21:14:17 Maybe an OpenGL app like Beryl or Compiz is the problem?
29/04/2012 21:14:17 Use x11vnc -noxdamage or disable the Beryl/Compiz app.
29/04/2012 21:14:17 To disable this check and warning specify -xdamage twice.

So I connected to my machine with -noxdamage, enabled 'tear free' of my ATI card.
Then I can connect without -noxdamage

@WangLu As has been discussed in earlier comments this is not a reasonable solution because the "noxdamage" increases bandwidth use and processor/RAM use. Try using vino with noxdamage over a DSL connection and you will see what I mean.

I can confirm that this bug persists with Ubuntu 12.04 on my HP Pavilion g4 laptop. (lspci yields VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Device 9647). I have tried with and without the ATI proprietary fglrx driver (v8.96.7 which is the standard 'non-post-release' offered up by Additional Drivers). Have also tried the 'No Tear' option in the AMD Catalyst Control Center. Finally, tried logging in to Ubuntu 2D and Gnome Classic (No Effects) but still no screen refresh. Although not my first choice, TeamViewer seems to work fine so will stick with that until this issue is worked out. This bug looks to be a stubborn one and I do appreciate the efforts that the team is putting in to solving it.

I'm using the Tear Free option at the moment, but screen refresh is terribly slow, even when used over a LAN. It appears to be refreshing entire screens at a time, which is what I presume the noxdamage setting also does. Yes, it "works" but its really so slow as to be completely unusable unless you are truly desperate.

I have installed 12.04.1 on a fresh system with an Asus P8B75-M motherboard. There are no additional drivers installed but the failure of the VNC server to update screen/window changes is exhibited. However if a window is moved then the screen does update.

I can confirm this behaviour. Installed 12.04.1 and enabled flgrx driver. VNC is extremly slow and doesn't refresh screen. It works normally with radeon driver. I also tried with latest fglrx driver but it doesn't change anything.

for trouble shooting, i have some updates. all are personal opinions and welcome to point out my misunderstanding.

based on fglrx driver.

when using metacity, we can see ProcCopyArea is frequently invoked if i drag a window around desktop. it help to update the damage region to some drawable which is indicated by VINO as following:
                  vfb->priv->xdamage = XDamageCreate (vfb->priv->xdisplay,
          GDK_WINDOW_XID (vfb->priv->root_window),
          XDamageReportDeltaRectangles);
in fact, the drawable ID is 186 on my platform, and i can oberve that DamageExtNotify for that ID in this case. the codestack shows it is triggered by damageCopyArea which is mentioned above. then VINO works well. key point, this copy is absolutely not requested by VINO because the client ID is different, so it's not the copy between RFB and root window. i wonder if it is metacity doing this copy.

while, change to compiz. ProcCopyArea won't be invoked for draging a window. no damage updates to drawable 186. VINO freezes.

actually we can force to flush some damages to drawable monitored by VINO, that's why enabled tear free option gives us a workaround, rotating screen also helps. but i don't prefer to add this flushing into common cases.

i also got some questions:
how does compiz draw the window while it is moving? if it won't copy area, is there any method to get the damages in Xserver side? i suppose it uses OGL to directly draw this process, but m not sure where it is rendered, root window or redirect window? i ask OGL guys to report kinds of damage to fglrx driver, no effect.

i carefully say that it might be issue of DRI in fglrx driver, because radeon driver supports VINO much better, and DRI in fglrx doesn't comply with standards quite well. so all my info and questions are for the purpose of fixing this issue. if any buddy know the damage reporting mechanism for drawable monitored by VINO in COMPIZ+RADEON case, please help me.

Same issue here
 uname -rv
3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20 15:22:35 UTC 2013
cat /etc/issue
Ubuntu 12.04.2 LTS \n \l
nvidia-173-updates 173-14-36-0ubuntu0.0.1
nVidia 6200 AGP8x
01:00.0 VGA compatible controller: NVIDIA Corporation NV44A [GeForce 6200] (rev a1) (prog-if 00 [VGA controller])
 Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 16
 Memory at cf000000 (32-bit, non-prefetchable) [size=16M]
 Memory at a0000000 (32-bit, prefetchable) [size=512M]
 Memory at ce000000 (32-bit, non-prefetchable) [size=16M]
 [virtual] Expansion ROM at cdfe0000 [disabled] [size=128K]
 Capabilities: [60] Power Management version 2
 Capabilities: [44] AGP version 3.0
 Kernel driver in use: nvidia
 Kernel modules: nvidia_173_updates, nouveau, nvidiafb

Workaround: always login classic shell no-effects

I don't know who are the devs of vino, but they could have a look to the realvnc server I use for years in Windows, it has an 3 desktop options that apply "While connected":
* Remove wallpaper
* Remove background pattern
* Disable user interface effects
beside the "Capture Method" options
* Poll for changes to the desktop
* Use VNC hooks to track changes (default)
    §Poll console windows for updates (default)
* Use alpha-blended windows (default)

I'm going to guess that at this point this bug is being ignored because Compiz is being phased out in Ubuntu.

seriously?

we're going to ignore this until we completely phase out the technology - and then ignore it some more?

way to go Canonical...

for the record, I am using KDE on Ubuntu 12.04 running nvidia304.88 drivers for an nVidia GT520 and this is very much still an issue... how many years later?

it is probably worth noting I didn't have this issue on my slightly older version of nvidia304 - didn't start happening until I upgraded the drivers to .88 (thank you Steam for insisting on that!)

As was to expect this bug still exists in 13.10. Please continue to ignore it.

I have the bug with 14.04 Trusty. Using vino on server side (and remmina as client),
test between two machines in LAN.

With fglrx installed on the server, the image does not update at all.

When switching back to X.org driver : the image is updated on the client side but very slowly. (Window movements initiated from the client are also slow to display on the server's screen)

I installed the Catalyst control center (fglrx-admcccle 2:13)
and in admin mode I activated the "no tear" mode as suggested above. Now it works fine. Thank you.

However the 'no tear' workaround I tested is not a solution for people who use an external screen, because of this other bug 1410930

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release