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