New DRM model

[Jon Smirl]

I have a new version of DRM at bk://mesa3d.bkbits.net/drm 
In it's current form it's 2.6 kernel only. Some support is generic but I've
mainly be working on an R200. It is still under development with lots of work to
do.

Major features:
1) Get VBIOS ROM contents IOCTL
2) Driver automaps the registers and framebuffer (map can't be changed)
3) Supports sysfs
4) Generates a hotplug event when loaded, event runs a vm86 reset program if
needed.
5) IOCTL support to set active VGA device when multiple cards are present (no
more playing with PCI bridges from user space)
6) radeon only so far, adds kernel level I2C devices which makes EDID appear in
sysfs
7) you can't have it and framebuffer loaded for the same device since they can't
share PCI IDs, sysfs, hotplug, etc.

My immediate goal is to get a login console up on a single screen. That means I
need to get the mode set, make fonts work and write a mini-terminal emulator to
the DRM API. So right now I'm building a mode setting API for it. What kind of
mode API do I need to support xserver? I've got the EDID in RAM as a starting
point. 

After looking at the Xfree86 mode code and getting lots of headaches I'm sure
this can be done is some less complex way. My initial thought is to start from
the EDID data and use that as my mode list. Xfree does it the other way around,
it starts form it's own mode list and tries to match the EDID data to it. I
still need to diff the EDID data off against the bandwidth capability of the
card.

My overall plan is something like this:
1) machine boots in VGA mode
2) DRM driver is built into the kernel
3) when hotplug event happens (early boot)
these are done in user space...
  a) card is reset if needed
  b) card is initialized and CP is started, optimal mode is set
  c) a pseudo terminal is created, takeover_console is routed to the pseudo
terminal
  d) very small user space app listens to pseudo terminal and implements
terminal emulator using DRM API
4) Full user space starts,
  a) OpenGL library can be loaded
  b) initial app execs more complex app which implements VTs using OpenGL API
  c) you can run one of these for each video card -- multiuser support
5) xserver starts
  a) uses OpenGL for it's API, no access to framebuffer.

A plus to this design is that the entire kernel TTY, VT, FB layers are
by-passed. Some of that code is very ancient and it probably has SMP issues.
Under the new model everything that doesn't actually play with the hardware is
moved to user space. Also the old model only supported one card and the new one
supports many.



=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html