Releases/7/XinF7

= X in Fedora 7 =

Various planning bits for the work on the Xorg subsystem in FC7. Please add ideas and requests.

At the moment it's unclear what Xorg release we'll be basing from, since the FC7 schedule isn't up yet. X and Fedora both roughly follow six-month schedules, with X's release happening slightly after Fedora (FC6 in October, Xorg 7.2 in Decemberish?) so it's unlikely that we'll be able to pull in all of 7.3; this doesn't necessarily preclude updating individual modules.

Flaky monitor support
Various monitors have unreliable DDC, and will only sometimes give you back the information about what the monitor supports. Some KVMs will drop the DDC pins. Some will even lie! Given this we need a more reliable runtime way of binding monitor capability information with outputs. General strategy:


 * Begin (and maintain) an EDID block database, possibly with corrections. We print raw hex dumps of EDID info in the X log now, so we can start building this even without active participation just by mining bugzilla reports.
 * Cache EDID blocks when we get them, reuse the most recent one on startup if DDC fails.
 * Mechanism for binding EDID to monitor in config file and at runtime.

Enhanced laptop monitor jiujitsu
VBE has a panel size extension. Can steal code from the i810 driver for it.

EDID info also available in ACPI, sometimes, need to wire this up.

Legacy reduction
The base Xorg installation still includes a lot of legacy junk.


 * libXaw. The major users are emacs and xterm, so dropping this might be a bit of a fight.
 * xorg-x11-utils, -server-utils, -apps, etc.. Probably more stuff in here than is strictly necessary.
 * xorg-x11-twm.

Others?

Minimal driver installs

 * Install only drivers that are actually required by the system and enhance the system to install drivers on demand. (RahulSundaram)
 * AdamJackson: It's not clear what the demand for this is. We don't do this for the kernel, so it's difficult to say why we'd want to do this for X.  Even on amd64, the X drivers only come to about 5M on disk.  This seems like a premature optimization.  (Of course, if you count the DRI drivers too, it rises to more like 28M, but a typical kernel's worth of drivers comes to around 82M, so.)  There are certainly ways to reduce the disk footprint, but I don't think excluding drivers is the right way to do it.
 * DavidTimms: You could argue that perhaps 95% of adapters are either nvidia, ati or intel, and hence only install those three output drivers by default, installing others based on detected pci info. A notebook/laptop never needs more than one driver; it can't be physically changed. How would you detect a fixed construction machine like a notebook ?
 * AdamJackson: You can't. Also some laptops can be changed, scary enough.

Death to the font server
We're not really sure what the point of having this was, and it's very slow to start. It doesn't seem to get much use as an actual network service either.

The default font path still includes the font server, so we'd need to make the X server able to find core fonts on its own. Shouldn't be hard, right?

Autoprobe
Start writing configs without the driver as well as without the monitor.

Configuration

 * Eviscerate more of s-c-display. The driver selection dialog should probably be replaced with a button for "Use VESA instead".


 * Have a spiffy GUI canvas widget for configuring multihead that lets you drag monitors around to arrange them. Slight randr 1.2 dependency.


 * Work on per-driver "Advanced" configuration tabs (plugins?). For example the open source ATI driver has a plethora of very useful xorg.conf options that improved my user experience by a good margin (AGP speed, but also settings related to dual-head or external monitors selections, and so on).
 * AdamJackson: I really want to avoid going down the path of exposing every config option. If AGP speed makes a difference, it should just be defaulted to the right setting.  The multihead thing is more or less addressed by the above widget idea.


 * DavidTimms: Make it easy to set custom resolutions for out of the ordinary (but becoming more common) display devices like video projectors, plasma panels, lcd panels, and led wall displays with weird resolutions like 1366x768 or 3600x1200, that do not talk nicely.


 * Remember any custom settings made and restore after logoff or restarts.
 * Don't disable output ports when feedback {EDID, DPMS, or termination} suggests that an output device is not plugged in. {Most professional audio visual equipment drops these signals. AV installers need to guarantee that any setting made stay that way, rather than needing to make manual workarounds after a reboot. If vga, dvi/d and composite outputs get turned on, the only reason to turn it off is because the user directly instructs it to be turned off.}
 * AdamJackson: No, that misses the point of RANDR1.2. If you want a pipe lit, say so; the server will remember.  But the initial startup will only light what it knows is available (unless nothing is there, in which case we just assume 800x600 as usual).

Intel
Use modesetting by default.

Kind of tricky! They keep reworking it, and it may end up requiring an X server that supports randr 1.2, which would mean xserver 1.3 which utterly breaks other stuff (in particular, all binary drivers) and might not be done in time for FC7. If it works with randr 1.1 though... who knows. Needs more research.

nVidia
Include nouveau. Full support requires kernel changes (drm module); push this upstream as well.

AIGLX
This is sort of dependent on some upstream work getting completed, but we can help drive that. The primary issue is getting the glXBind Image path working entirely on-card and unifying the memory pools between 2D and 3D driver; currently we do all 2D rendering host-side and upload textures on every damage event, which is passable but not great.

EXA

 * Still some driver conversion work in progress. See Xorg's ExaStatus page.


 * Some additional fast paths that need to be written:
 * Composite helper for single-TMU cards
 * a8 to argb32 expansion for dx7ish cards with no native a8 destination format


 * Upstream work that needs finishing:
 * MITSHM tweaking
 * Assembly memcpy for upload and download (steal from sis/via drivers)
 * Damage-tracking for pixmap migration

Startup
Doing a lot better by doing less filesystem bashing, but still some wins to be had. See bootprobe for measuring tools.

Compiz

 * Enable compiz by default where the open drivers support it. Dont just say "Desktop effects cannot be enabled" otherwise but actually guide the user if we can.
 * Patch compiz to exec metacity if it can't start.
 * Ability to configure more compiz options in preferences.
 * AdamJackson: Again, really want to avoid the zillions-of-options world. Should come up with a design doc of what we should expose.
 * JohnMahowald: I've packaged gnome-compiz-manager, a tool I found to manage those config options. Currently awaiting review
 * Improve compiz to support the exact same keyboard shortcuts that metacity does.

XCB
Enable XCB. Right now this just means using the XCB version of Xlib. Presumably some toolkit work will need to be done as well to actually take advantage of XCB fully.

Showoff
Blow users away by including something {other than useless desktop effects} that seriously shows off the capabilities of cpu/ ram/ graphics/ 3d/ display system. eg. something like nvidia's chameleon 3d demo {DavidTimms}