[compiz] compiz works really strange with external monitor

Danny Baumann dannybaumann at web.de
Thu Feb 7 23:34:56 PST 2008


Hi,

> > Well, it's not so much a 'weird configuration' as a faithful
> > representation of reality. :) What to do with this information is policy
> > and thus not up to the X server.
> 
> This should be obvious... The xinerama query is returning the actual
> heads, as it is supposed to. There are uses for this setup, and it
> should be possible to detect without extra work from a client point of
> view, as it is now. "Fixing" this in X is not something I consider a
> good solution. For starters, you would have to add another means to
> detect setups like this.

Ok, I stand corrected. I therefore withdraw my previous proposal ;-)

> There are valid reasons where you actually _want_ the existing
> behavior. I can name at least a couple.
> 
> As for handeling this in various panels and the like, I believe the
> expected behavior is pretty obvious, with a few quirks. Allow the
> panels to snap to either screen edge during movement, and add some
> logic for what to do when the screen changes. This, however, is not up
> to compiz and thus is not the subject of this discussion. But it's
> definitively not up to X either.
> 
> Having the option to remove what users experience as redundant edges
> make sense in Compiz. A simple option would do the trick in the vast
> majority of cases, but if we really want to, it wouldn't be impossible
> to add automatic detection of what the user want based on struts. This
> would involve panels actually handling this sanely too.
> 
> I do see why you would avoid having it in core, but I believe this is
> a functionality that would be perfect in the workarounds plugin. It's
> a fairly straight forward thing to implement and I don't see any down
> side right now. We certainly have features there that are less proper
> than that.

I tend to disagree. Just removing the smaller head is not a good idea
IMO if there _are_ scenarios where you might want the existing
behaviour.

Attached is a proposal for a patch that makes the
outputDeviceForGeometry function inside compiz a bit smarter about
overlapping outputs. I described how it works in the patch, but the
idea is to not return the head where the rectangle center is (this is
ambiguous for overlapping outputs), but the head the largest rectangle
area part resides. If two outputs contain an equal area, it returns the
smaller one.
In our example, it changes the behaviour so that a window
is maximized to the smaller head if it's completely on that one and to
the larger head otherwise. I can't really think of a more meaningful
behaviour without making this configurable. 
This patch is only a
proposal, nothing final yet - if someone has an idea how to code it
more efficiently and especially on how to get rid of that ugly heap
allocation, I'm all ears ;-) Please note I didn't use the X region
functions on purpose because I would use only a very small subset of
their functionality and they would mean even more heap allocations, so
I think it's more efficient without them.

Thanks for commenting,

Danny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-outputDeviceForGeometry-behave-smarter-when-dea.patch
Type: application/mbox
Size: 0 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20080208/fe2cbe76/attachment.bin 


More information about the compiz mailing list