xrandr: needs changes for dualhead + panning

[Maarten Maathuis]

On 12/23/2008 12:14 PM, Eeri Kask wrote:
>> 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
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>    
The problem is mostly one of how applications see your screen. One 
xinerama screen or two?
b would have two (which is the current situation), a might have one.