#1279 closed defect (upstream)
bug in compiz and frame extents
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 1.0 |
Component: | client | Version: | trunk |
Keywords: | x11 ubuntu compiz frame extents | Cc: |
Description
This is just a tracker ticket for redirecting users to compiz where the bug belongs. Other window managers may have similar bugs.
Their bug tracker http://bugs.compiz.org/ seems to be broken, so we'll just have to live with the ugly warning until someone fixes the compiz code.
As of r13253, the warning we print looks like this:
Warning: invalid frame extents value '[0, 0, 0, 0, 0, 0, 28, 0]' this is probably a bug in 'Compiz' using '[0, 0, 28, 0]' instead
What happens: for frame extents synchronization (#919), we send a _NET_REQUEST_FRAME_EXTENTS on the window we create for this purpose. The window is realized but not yet visible. (this is what seems to confuse compiz)
When we query the value of _NET_FRAME_EXTENTS, we get 8 32-bit values rather than 4.
This can easily be tested using this GTK test application: browser/xpra/trunk/src/tests/xpra/x11/get_frame_extents.py.
It prints the window's XID, so you can also use xprop to verify that the bug is not in the xpra X11 glue code.
Change History (5)
comment:1 Changed 6 years ago by
Resolution: | → upstream |
---|---|
Status: | new → closed |
comment:2 Changed 6 years ago by
FWIW: had a look at the compiz code and it looks fine, yet even xprop reports the wrong values..
comment:3 Changed 6 years ago by
comment:5 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1279
this is not a bug in xpra.