Bug 134240 - metacity server grab causes vino to hang
metacity server grab causes vino to hang
Product: Fedora
Classification: Fedora
Component: vino (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mark McLoughlin
Depends On:
  Show dependency treegraph
Reported: 2004-09-30 11:17 EDT by Leonid Kanter
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-06 13:47:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Leonid Kanter 2004-09-30 11:17:29 EDT
Description of problem:

vino hangs immediately if /apps/metacity/general/reduced_resources is set

Version-Release number of selected component (if applicable):


How reproducible:


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
Comment 1 Mark McLoughlin 2004-10-05 09:33:52 EDT
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
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.

Comment 2 Havoc Pennington 2004-10-05 10:43:20 EDT
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 :-/
Comment 3 Mark McLoughlin 2004-10-05 11:46:37 EDT
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
Comment 4 Eugene Kanter 2004-10-05 16:02:22 EDT
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.
Comment 5 Mark McLoughlin 2004-10-06 13:47:01 EDT
Okay, we no longer hang and the screwiness I was seeing is fixed too:

* Thu Oct  7 2004 Mark McLoughlin <markmc@redhat.com>
- Don't hang with metacity's "reduced resources" mode (#134240)
- Improve the key repeat rate situation a good deal (#134451)

Note You need to log in before you can comment on or make changes to this bug.