[Xorg] OLS and console rearchitecture: second pass

[Jesse Barnes]

Thanks for posting this, Jon.  I'll show it to some of the gfx guys around 
here to see if they have any comments too.

On Thursday, July 29, 2004 12:46 pm, Jon Smirl wrote:
> 1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
> track the boot video device and expose the contents of C000:0 for that
> special case.

We already have config space exported via sysfs, so adding PCI ROM support 
shouldn't be too hard.  I think you mentioned a quirk for cards whose ROMs 
are embedded somewhere in system firmware space--I think that'll work too.

> 2) VGA control - there needs to be a device for coordinating this. It
> would ensure that only a single VGA device gets enabled at a time. It
> would also adjust PCI bus routing as needed. It needs commands for
> disabling all VGA devices and then enabling a selected one. This device
> may need to coordinate with VGA console. You have to use this device
> even if you aren't using VGA console since it ensures that only a
> single VGA device gets enabled.
> Alan Cox: what about hardware that supports multiple vga routers? do we
> care?

Are you thinking of something like /dev/vga that you'd ioctl to select a 
device?

> 3) Secondary card reset - Handled by an initial hotplug event. We need
> a volunteer to write clean vm86 and emu86 apps for running the ROM
> initialization. Resetting needs #1 and #2 to work since resetting a
> card will enable it's VGA mode. I have an implementation of this but it
> needs a lot of clean up.

In my case, I'll need it even for primary card reset.  :)  Can you post a link 
to your old code?  I'd be interested in checking it out even if it's not the 
package we settle on (I think Alan mentioned switching to qemu at some 
point?).

> 4) DRM code reorganization. There were several requests to reorganize
> DRM to more closely follow the Linux kernel guidelines. This
> reorganization should occur before new features are added.

Yay!  The sooner, the better, IMO.

> 5) Multihead cards will expose one device file per head. Many IOCTLs
> exposed by these devices will be common. Some, like mode setting, will
> be per head.

This makes sense to me.

> 6) Mode setting before early user space - this was decided to be a
> platform specific problem. With minor adjustment the kernel can be made
> to boot without printing anything except errors before early user space
> starts. Platform specific code will need to handle these error messages
> if any. This includes INT10, Openfirmware, mainframe serial consoles,
> VGA mode. Suppressing informatory printing before early user space
> starts allows a clean boot straight into graphics mode.

Since, for the most part, this is already platform specific (i.e. many 
platforms use vgacon if their cards have been POSTed by the BIOS, others use 
firmware based printk, and still others use serial consoles), it seems 
sensible.  And we can always fall back to static, simple mode setting for 
vgacon-like early output.

> 7) Mode setting from normal user space - devices will have a standard
> IOCTL accepting a mode string like fbdev currently uses. This IOCTL
> will lock the device and optionally trigger a hotplug mode event. Mode
> setting for some fixed devices is simple enough to avoid the hotplug
> event. In the hotplug event the mode line will be decoded, DDC queried,
> etc. Some classes of devices (for example Intel 810,830,915) have to
> have their mode set using vm86 and the video BIOS. Others might use a
> small C app to query DDC and then use a device specific IOCTL to set
> the mode registers. Early boot and normal user space will use the same
> hotplug apps so they need to be as small as possible (good luck IA64
> and emu86).

Heh.  It shouldn't be too bad.  We have lots of memory to waste on initrds. :)

> 21) It was also discussed the X should stop implementing OS level
> features and instead use the features of the underlying OS. If the
> underlying OS is lacking support the support would be implemented in a
> library external to X. Examples of moving from X to OS support include:
> PCI bus, input, console groupings, etc.

Again, yay!

Thanks,
Jesse