Description of problem:
vino hangs immediately if /apps/metacity/general/reduced_resources is set
Version-Release number of selected component (if applicable):
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
There will be no any responce from vino server
Vino must work properly in this case
Okay, this is a fundamental problem with having the VNC server as an X
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
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
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
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
Okay, we no longer hang and the screwiness I was seeing is fixed too:
* Thu Oct 7 2004 Mark McLoughlin <firstname.lastname@example.org> 220.127.116.11-1.1
- Don't hang with metacity's "reduced resources" mode (#134240)
- Improve the key repeat rate situation a good deal (#134451)