surface buffer cardinality and outputs

[Sylvain BERTRAND]

It seems there is also an issue with the double buffered flow,
namely to make it work cleanly in a the case of a surface
spanning several outputs, those of course not in sync and with
different refresh rates. Better not be in a hurry to do a "page
flip" on a surface which covers several outputs.

On Thu, Mar 14, 2013 at 06:01:10PM +0100, John Kåre Alsaker wrote:
...
> Anyway I do prefer the one workspace per output approach where you
> can't see these race issues at all :)

I do agree, then:

The idea of a discret 2D dynamic matrix of stacks of outputs
instead of a continous compositor space is, in my opinon, a model
closer to what we would "see" in the reality. I picture a 2D
matrix with slots. Pointer navigation over this matrix of slots
should be quite straight forward. Clone use case: in a slot you
would have a stack of outputs, but one master and all the others
degraded clones, namely scaled copies of the master. The clients
would only care of rendering in the master output of a slot. The
compositor would take in charge the copy/scaling of the master to
the clones since the compositor would be granted scaling powers
in that case. Then clones do not exist for the clients.

As we agreed before and for what was said about that matter, a
surface would belong to and be rendered on one output only
(master of a slot in the 2D matrix). The pointer navigation would
need a "motion" that would be enhanced with the slot information
since we aren't anymore in a continuous compositor space.
Additionnaly, a client should be able to target a specific
slot/master output for surface creation, or let a compositor
policy decides the slot/master output then be told about it. The
shell part/decorations of the surface should be able to detect a
drag which crosses a slot/master output boundary and then should
do the "jump" to the new slot/master output, if it wants to.

All that means a massive refurbishment of the protocol in many
areas.

A last note on fullscreen scaling. Scaling, in that case, targets
master output/slot which should not be handed to the compositor
and rendered only by the clients (using hardware or not).

Thanks.

-- 
Sylvain