Bug 28779

in summary, i have two proposals for improvements: "easy" (as not too much pain for developers) and "hard" (as teeth-grindingly difficult with possible changes beyond just X and major protocol alterations).

an easy one will be:
1) make multi-head/multi-screen (non-xinerama screens) configuration possibility a requirement for all in-tree X drivers.

i heard some term called "zaphod mode" - i believe this is some cryptic term by which some few people call such simple thing which should be pretty much vendor/driver-independent and easy to set up/use.

we all use "virtual desktops" but those are _real_ multiple desktops !
why would you want them to always be glued together into one giant virtual desktop (xinerama) ? 0_o
(rhetorical question - i know why. this is just different use-case)

also looks like that KDE devs decided to ignore multi-screen configurations in their new DE, as it (particularly, plasma) goes apeshit when sees it (from what i remember in kde4.0-times) but can we blame them as such serious dudes as Intel devs apparently have ditched such thing completely from their drivers and not talking about better way to get it back ? o_0

and the juicy hard one will be:
1) same as previous, except make it more seamless and straight-forward as randr manages outputs per one screen (and less hackish since using several instances of same driver for same card is not a good way to do things).

On Windows(tm) its default behaviour (in XP(r) anyway) to add new outputs as screens of available window space but not create one giant desktop _with common elements_ as it tends with FreeDesktop environment (X,Xinerama, x\g\kdm, kicker\plasma\gnome-panel, kwin\metacity, etc.). with FreeDesktop it's quite unorthodox to get separate screens per same X instance:

assigning screens at "ServerLayout" section _and_ defining exact outputs for each screen is NOT enough, you _must_ also define two same "device" sections even for same device with one difference - "Screen <number>" directive so it will not tend to take everything on same screen even though you explicitly defined that in "layout" and "screen" sections.
only then you will be able to launch applications with "DISPLAY=:0.1 mplayer"-like command and manage windows there with your pointer without fear of stuff on first screen affecting it. xrandr doesn't show all of the screens in this case - you have to explicitly define it, e.g. "DISPLAY=:0.1 xrandr" will show outputs and properties for Screen 1 but never for both at a same time.
That's what i call "Multi-Head", dammit - when several _people's heads_ can make use of hardware while only one "seat" is involved in operating.

otherwise screen elements tend to fill up all available space. it, probably, semi-configurable but sucks so much :(

2) as KMS now involved and outputs configured at boot time we have little problem and nice opportunity, both having same root - VTs (kinda kernel-level "screens", in my understanding) shared per outputs and TTYs shared per card, single card.

so the problem will be - if you stick several devices with different parameters (e.g. FullHD panel + TV) to several outputs before booting kernel those devices Will have their native resolution set which is right but VT will be all squeezed to the size of smallest device (using 'clone' picture from smallest device across all of them).
maybe because there is only one kernel framebuffer per whole device ?

the opportunity will be to turn this situation around with use of KMS - instead of just cloning picture of squeezed VT, to assign 12 separate VTs to each of the detected devices dynamically while also dynamically binding TTYs to those VTs.
in which case same ttys could be binded (or not, at will. e.g. you will not want all of them to be accessible in restricted station but one) to same VT numbers as before but displayed separately (separate fb per active output ?).

in this case one X instance will be able to run with same VT number\s as concurrent one on a different output\s, also providing Multi-Seat users with ability to use non-X VTs or/and own several X instances while not disrupting anything for other X users.

if X instance is trying to use output which already taken by another X instance then next VT (8-12 ?) of that output should be used for that screen(multi-screen)/screen-part(xinerama) with separate tool (xrandr?) or hot-key (while pointer is on that screen\screen-part) should be used to switch them.

3) speaking of Multi-Seat - it should be achievable on a single card (without crutches as Xephyr !)

with KMS/non-root X it's not several instances of same driver for same card should spawn per X instance but several X instances should be able to benefit from single driver (or from kernel drm code directly ?).

so, if someone will come up with practical idea of how to achieve that (like making xf86-<driver> instance shared per X-server instances somehow or even independent of them. and with most work done with KMS in kernel it may be possible, right ?) then DE developers could add little menus in theirs DMs to select output/screen configuration (after all, those ARE _Display Managers_ and they should, you know, manage displays) before session's start (and keep last used configuration per user, or with KMS/non-root X involved - in each user's home). this would be sweeeet

of course, it would be also nice to have a non-X analogy for master/slave input assignments to create input(keyboard, mouse,etc.)/output(+bunch of independent VTs) groups and effectively getting Multi-Seat completely independent of X-server, but this is probably too much.
_ _
with all 3 implemented it will be possible to manipulate all of inputs and outputs of your machine in pretty much any way imaginable.

guts tell me (i'm not a programmer, so it guts and not brain) that direction to implement all that is to center around outputs, their properties, common properties of theirs displays and encoders, effective video memory management; making output management more generic and card/vendor/driver independent or putting it simply - expanding stuff that's going on right now with KMS and randr without hesitation and fear for some "backward compatibility" and stuff.
the scalpel is already taken by Intel devs, they say, but where are needles ?

it is nice to have network-transparent environment where it is so damn easy to mix local and network resources from separate machines as UNIX-like world presents (and X and FreeDesktop are not exceptions) but when you have bunch of people and hardware in close proximity of each other and some fast-paced input/output activity is involved (for information ;) - it's much better to use each hardware potential to full extend until you have to make use of networking.
(and no, in contradiction to my previous mentions - Windows(tm) doesn't reveal that potential any better, in fact it reveals Jack shit)

some interesting links: 
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10484.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10519.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10524.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10529.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10537.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10623.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10646.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10648.html
http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10649.html
						
http://www.x.org/wiki/Projects/XRandR
http://www.thinkwiki.org/wiki/Xorg_RandR_1.2
http://wiki.debian.org/XStrikeForce/HowToRandR12
http://intellinuxgraphics.org/dualhead.html
						
http://www.nvnews.net/vbulletin/showthread.php?t=101547
http://wiki.archlinux.org/index.php/Xorg_multiseat
http://www.gentoo-wiki.info/HOWTO_Multiseat_X
https://help.ubuntu.com/community/MultiseatX
						
http://www.phoronix.com/vr.php?view=15018

colourful examples are coming soon...

PS: heh... a lot of words when you put it in text, i hope someone will be able to make some sense of that mind-dump.
wanted to write it all up like a year ago when first heard about KMS and multi-pointer stuff but thought this is asking too much in unclear fashion.
that until i've noticed major gpu memory management, drm and fb rework, dri2 transition, xrandr improvements being done and decided that this is just a time to post/suggest something like this until its too late and stuff is stabilized in places.

what a hell is "zaphod" anyway ? it's not an english word for sure...