Danny Baumann dannybaumann at web.de
Wed Dec 31 04:02:37 PST 2008


> Hiya Compiz list! I am a Linux UI dude for VMware as my day job and am
> working on improving things in Workstation and Player with regards to
> multiple monitors on Linux. Some of my colleagues worked with the
> xdg/wm-spec folks just earlier this year to get the
> _NET_WM_FULLSCREEN_MONITORS hint into the EWMH spec to address the
> needs applications have in needing to be both fullscreen and spanning
> multiple monitors at the same time. Previously, we had some hacks to
> get Window Managers to do this, but it was fragile and brittle to say
> the least. Anyway, _NET_WM_FULLSCREEN_MONITORS is the right solution
> and is very useful for client virtualization software such as VMware,
> and for any other apps that wish to go fullscreen and span more than
> one monitor (i.e. video players, etc.).
> Long story short, last Friday, I had just pulled out a git clone of
> compiz and was getting ready to start looking at patching
> _NET_WM_FULLSCREEN_MONITORS into Compiz and I discovered that Danny
> Baumann had done just that literally the day before. WOOT! Thank you
> Danny!!!

You're welcome :)

> I spent some time Friday in using the simple test application that
> David Trowbridge wrote
> (http://bugzilla.gnome.org/attachment.cgi?id=122703) that exercises
> _NET_WM_FULLSCREEN_MONITORS as well as using the multiple monitor
> feature of Workstation and things look really good! So I just wanted
> to introduce myself, say THANK YOU to Danny for adding the new hint,
> and see if there's anything I can do to help with this hint. 

You can ;-)

- There's one reported regression: URL I will try to see what's
happening there (and if I can reproduce it at all), but if you have any
pointers, let me know.
- What the current compiz code does (which is similar to what kwin and
metacity do) is that the fullscreen rectangle is calculated as the
boundary box of all the specified monitors, no matter at which point
they were specified. Re-reading the spec I think this is not exactly
correct. The spec clearly states that the specified monitors specify
edges, not an arbitrary set. Attached is my take on fixing that and
bringing compiz' behaviour in accordance to the spec.
For an example, imagine a scenario with 2 monitors: a 1280x800 laptop
panel and a 1280x1024 external monitor. The resulting window sizes for
some specified monitor sets are as follows:
(monitor set: left/right/top/bottom - old code - new code)

0000 - 1280x800+0+0     - 1280x800+0+0
1111 - 1280x1024+1280+0 - 1280x1024+1280+0
0001 - 2560x1024+0+0    - 1280x1024+0+0
0100 - 2560x1024+0+0    - 2560x800+0+0
0101 - 2560x1024+0+0    - 2560x1024+0+0

You can also see the difference when trying the test tool with two
differently sized monitors. I think the new version makes much more
sense because it allows greater flexibility (e.g. a video player doesn't
want parts of its window offscreen) and it matches the spec much better.
I wanted to know about your opinion, though.

> Also, I'm not quite familiar with the Compiz release schedule yet...
> does anyone know what released Compiz version will have
> _NET_WM_FULLSCREEN_MONITORS in it and when that will happen? Is there
> any chance it can make it into the next released stable version?

If we can solve the regression above, I see no reason not to pick this
change into the 0.8 branch. I even think we _should_ pick it, because
some distros are likely to stay with 0.8 (once it's released) for a


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Bring-fullscreen-rectangle-calculation-in-line-with.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20081231/a6e976a9/attachment.bin 

More information about the compiz mailing list