[Dri-devel] New DRM design (was ATI I2C, MONID)

[Jon Smirl]

I've been getting a lot of mail about this both on and off list. First off, very
little code has been written, this is just a design concept. 

One thing is clear there are two consoles involved. One is the system console
that receives printk's, the second is your garden variety command line terminal
session. I'd like to explore pushing this second type into user space. One
advantage to doing that would be the ability use 3-4 PCI graphics cards to set
up a multiuser system. You could even have separate command line sessions on
each display head.

Implementing a system for displaying printk's to the screen has to cope with
another type of problem caused by a xserver that is hardware compositing the
entire screen on every vertical retrace. Without coordination anything you write
to screen will be gone 1/60th of second later. Full screen games have the same
problem.

The bigger goal here is that I'm exploring a system that would shut down all
direct user space access to the graphics hardware. The graphics hardware would
be protected by a single device driver and a user space library is used for
accessing it. This type of design accomodates graphics hardware where the VRAM
is not visible to the bus. SGI machines already have this and there may be more
chips like this in the future. It also stops the free for all where every app is
programming the graphics hardware from user space.

I've had several discussion now about how to handle printk's in an environment
like this. The best one so far is for the graphics driver to hold a log of the
printk's it has received. When a new one is received the driver suspends whoever
is writing to screen, possibly by letting them continure to write to the back
buffer and stopping screen swaps. It then formats the front buffer and paints in
it's log of printk's. Note that the front buffer will already be set up for
display in the current mode. Formatting and painting is something that can be
done at interrupt time. The system would then stay in this state, updating for
more printk's, until some kind of input was received (sysreq?). The printk's
would also be sent off to some normal command line console where you could look
at them and run programs if the system remains stable.

One hole in this is what happens if a printk occurs in the middle of a mode
switch? or if the display is in a suspended state? This will require some
research. Getting the display out of suspend may not be achievable at interrupt
time. These aren't new holes, they're there right now for the current console.
The above scheme does provide the new feature of making the printks appear while
xserver or a game is running.



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

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