Description of problem: vino hangs immediately if /apps/metacity/general/reduced_resources is set Version-Release number of selected component (if applicable): 2.8.0-1 How reproducible: always Steps to Reproduce: 1. set gconf key /apps/metacity/general/reduced_resources on the box where vino server is running 2. Connect to vino server from other box 3. Try to move window Actual results: There will be no any responce from vino server Expected results: Vino must work properly in this case
Okay, this is a fundamental problem with having the VNC server as an X client. In order for metacity to be able draw the wireframe, it needs to grab the server so it can scribble over everyone elses windows. But because the server is grabbed, Vino can never deliver a button release event to cancel the grab. In this case, the only way to stop the hang is to click the mouse button on the actual machine which has hung. Anything that grabs the server like this is going to break Vino - for example, try to log out with Vino. The session manager grabs the server and you'll see Vino hang. I'm not sure the issue can be resolved easily. What we really need is something like XGrabFramebuffer() which would give metacity exclusive access to writing to the framebuffer but would still allow the X server to process non-drawing protocol requests from clients and send them events. However, right now when you do cancel the grab by clicking the mouse on the server, things stay pretty screwed up. With a bit of debugging we should be able to fix that much, at least.
Once metacity is a compositing manager it can do wireframe resize without a server grab because it will fully control the screen. Of course, in that case wireframe won't be any faster than opaque, but I'm sure people will feel better about wireframe even when it's purely placebo ;-) But the point is the new composite extension does provide the equivalent of XGrabFramebuffer(). Perhaps we could fix this bug with XTest or something? Though that probably still doesn't help with a server grab. I think we may be hosed and have to consider putting the VNC server back in the X server process :-/
XTestGrabControl() ! Where the heck did that come from? I was using XTest for synthesising input events, but never came across it. Problem solved (in theory). Move along (with thanks) :-) It still gets screwed up after a bit even using XTestGrabControl(), but I don't think that's a fundamental problem. Just requires some debugging.
What about excessive CPU usage? When vino is idle and connected to a viewer I get vino process utilization equal to a 100% on a 200mhz CPU. Sometimes network traffic is also high without any visible activity on the screen.
Okay, we no longer hang and the screwiness I was seeing is fixed too: * Thu Oct 7 2004 Mark McLoughlin <markmc> 2.8.0.1-1.1 - Don't hang with metacity's "reduced resources" mode (#134240) - Improve the key repeat rate situation a good deal (#134451)