xrandr: needs changes for dualhead + panning

[Eeri Kask]

> Maarten Maathuis:
> On 12/19/2008 08:42 PM, Carl Karsten wrote:
>>> The placement logic is output driven, and doesn't take panning into 
>>> account. So you end up with strange overlap. If dual head + panning 
>>> was a goal you might consider fixing this. It doesn't seem trivial to 
>>> do from a quick look. On the plus side it's just a xrandr change.
>>
>> dual head + panning could mean
>>
>> a the whole space pans when you get to the side of the virtual space,
>> b pan each physical display separately,
>> c a combination of a/b.
>>
>> zoiks
>>
>> Carl K
> 
> (a) would need changes on the protocol side (imo)
> 
> I was thinking of (b).
> 
> Maarten.


Indeed, other ideas than being "output driven" could include "pointing
device driven"  (or "screen centric", if there are :0.0, :0.1, etc
present).  :-)

Sure, in general one can consider the placing/moving/resizing of CRTC's
in respect to the framebuffer much the same like placing/moving/resizing
usual X11 windows on the root window ... as kind of an additional,
abstract "viewport" layer between hardware pixels and X11 windows, being
semantically closer to the latter --- we can create/destroy/configure
(i.e. move/resize, resize looks like zooming thanks to the fixed
physical size of the TFT-panel) these viewports --- everything up to
newly introduced affine transforms and "panning"; and being kind of
transparent in nature, "overlapping" viewports don't obscure each other
but show the same content in intersecting areas; so "raise" and "lower"
here simply make no sense.

In fact one could think of implementing some virtual-/pager-based
windowing or window-manager concepts in the hardware and just take the
panning architecture from there:  e.g. attach sticky bits to CTRC's and
introduce kind of a rectangular, virtual, by protocol arbitrarily
configurable bifurcation (or "panning") window tied to the pointing
device, which the mouse is confined to. So shifting this abstract window
across the framebuffer would at its borders move the sticky CTRC's in
unisono.  (Making that pan-window proportional in size to some sticky
CTRC and putting it initially over it would correspond to the current
model as a special case.)

The 1.2 randr version already in fact represents a hardware
implementation of some "high-level" concepts; e.g. like a pager
application, in combination with the  xrandr-1.2.3.tar.bz2  utility.
Though, as it is the latter actually kind of spoils some essential
features, e.g. one has to disable the CTRC shifting into the framebuffer
origin in the source code (i.e. so in fact make xrandr honour the
"--pos" command line parameter, even in case of LVDS being the only
connected CTRC of course), and per default automatically not restrict
the framebuffer size to the bounding box of all active CTRC's:  in usual
sense top-level windows don't automatically move to the screen origin
either and don't shrink to exactly fit all their subwindows.

To ensure all viewports only cover visible framebuffer including its
origin, lie side-by-side in a row/column, etc, as a policy/preference is
probably best left to the window/desktop manager to enforce or not.

Further, in the v1.3 draft in almost all cases there seems no apparent
need the panning aspects of the protocol be so strict to (and in part
even by itself arbitrarily change) affected geometry parameters as
meaningful interpretation/behaviour can be almost always invented even
in case of a sudden framebuffer size change (who knows in future the
framebuffer can be effortless dynamically resized as X11-windows do today).

Greetings,

    Eeri Kask