> 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg