xrandr: needs changes for dualhead + panning

[Eeri Kask]

Maarten Maathuis wrote:
> 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).  :-)
>>
>> [...snip...]
>>
> 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.


This ambiguity emerges out of the apparently missing "big picture"
providing an idea how the Xinerama and Randr technologies are supposed
to fit together in the X11 architecture; unfortunately the common
documentation doesn't help in creating that picture too. :-)

Views appearing sometimes supporting the forecast Randr obsolating
Xinerama at a first sight look like a request to replace rational
numbers by integers: it is certainly justified, assuming this simplifies
overall complexity at no loss in model performance. The above forecast
sure comes true, but it is uncertain if beyond laptop computer users: in
a contrary, imaginary case of a, say some Tesla-rack-like apparatus
featuring numerous separate graphics units, as of today, reading the
randrproto.txt document it is not clear how Randr replacing Xinerama
could cope in providing a single m-by-n tiled visible rendering area out
of these --- the need for dynamically runtime-configurable, plugin
screens etc, many arguments valid for handheld devices simply do not
exist in these scenarios.

It is evident that Xinerama and Randr are not duplicated efforts.
Historically one could put e.g. several different video cards into ISA
slots and Xinerama coupled the physical framebuffers into a logical
one~[1].  In contrast, Randr-1.2 today apparently provides essentially
this: given one physical framebuffer, this is decomposed into various
virtual ones, each corresponding to a CRTC.

These are semantically clearly inverse operations.  Anyway, a random
application probably doesn't care about the hardware ordering --
combined together or decomposed apart -- it has to deal with physical
TFT-panels as viewports of a noncontiguous rendering area presented to
the user, which carry many semantical aspects of usual X11-windows ...
they are mostly in the same sense configurable and the configuration
events are reported to the application by X11-events.  Though, from that
point of view, an essential feature missing yet is mouse event
mechanism, Enter/Leave and everything the like (much the same if moving
the mouse from ":0.0" to ":0.1", or from window to window; mouse
location queries, etc).


Greetings,

    Eeri Kask


[1]  Unfortunately Xinerama-tiling apparently replaced the historical
X11-display decomposing into X11-screens (":0.0", ":0.1", etc) by a
single screen ":0.0", and was not layered beneath the X11-screens (e.g.
how to configure a 2x2-Xinerama-tiled X11-screen as ":0.0" besides a
1x1-one as ":0.1", etc?).  Today, different rendering hardware becoming
common (TV, sterescopic/multiview imaging devices, game consoles,
handhelds, etc) creates the need to combine X11-screens, some
Xinerama-tiled and some not, some dynamically attached and some not,
some colorful and some greylevel, into a single X11-display.