[Dri-devel] Three concepts for changing the way video works in Linux

[Jon S. <jon...@ya...>]

Here's three more ideas I'm thinking about but I haven't written any code for...

First some terminology. We really have two consoles. There is the kernel console
that gets the printk output. Second is a user console that you can log into. 
Right now the fbconsole system maps these to the same place but they don't have
to be. The kernel console can go out a serial port, network, etc.

1) Use SysReq to get to kernel console. In this model the kernel console is
always active, it's just hidden. Hit SysReq and it appears. Hit an oops or panic
and it will appear too. The video driver has enough state information to make
this console appear no matter what mode the video hardware is in. Hit SysReq
again and it will disappear and your display will be back where you left it.
Extra points if you can get something like kdbg running on it.

2) Move the code implementing user console to user space. User console would
work via ptmx/pts like X terminals. There would be a process listening to the
pts device which would implement the terminal emulator, VT, etc and draw on the
video device. The process would always be running and be started from init. The
main purpose to this is that it becomes very easy to plug in multiple graphics
cards and build a multi-user box.

3) Turn multi-headed cards into two DRI devices that can be used independently.
Using item #2 a separate user could be logged into each head. If you own both
the primary and secondary device you could set a special mode on the primary
that would trigger merged fb and disable the secondary device.

These are just concepts right now. If you've got ideas on how to improve on
these let me know.

A fourth concept which has already been heavily discussed is making OpenGL the
primary graphics API. OpenGL can be quite small, OpenGL-ES is already shipping
on some phones. Just to recap OpenGL/xserver is a response to Windows Longhorn.
It is also a high level API that allows graphics hardware to grow more
intelligent without disrupting the top level API.

--- Alan Cox <al...@lx...> wrote:
> It does not remove the need to security audit the code. It makes the
> mess slightly smaller if you get it wrong. You probably also want a
> minimal set of mode setup code in the kernel so you can get back to a
> known text mode configuration when a GUI server goes kaboom, or when the
> user hits SAK (and SAK is mandatory for many secure configurations).

Are these needs addressed by the concepts above?

> > wants to the hardware. What if I am running X/DRI in one VT and another app
> > that does direct 3D drawing via the hardware on another VT. Does framebuffer
> > preserve the complete state of the hardware at VT switch?
> 
> It needs to yes. Although it doesn't necessarily need to do it all in 
> kernel mode.

There is another solution. By using DRM/OpenGL as the core API and single driver
there is no need to save the hardware state at VT switch. The only reason ww
have the state saving problem on VT switch is because we are trying to multitask
two device drivers and some user apps all trying to directly use the hardware.
Moving to a single device driver and blocking user space access to the hardware
will allow the hardware state to be managed. The other choice is like VMware
where we create a virtual Radeon device.

> For high end hardware maybe. For the low end I actually expect we'll see
> something different, probably from Intel first (since Intel is
> continually trying to leverage die size for new features) which is on
> CPU operations to do texture walk and basic effects. In other words
> using the CPU to do the grunt work in the tight inner loops of the 3d
> library. This makes a lot of sense in a low price environment where you
> already have the framebuffer in CPU memory not over a PCI bus.
> 
> Also don't lose sight of the fact large numbers of Linux systems, and
> probably a growing percentage over time will be phones, dvd players,
> pda's, post PC systems and the like. I don't think anything in your
> design is problematic here at all. It works fine for single mode, dumb
> 2D devices.

This is true. Software Mesa can completely emulate everything and just use a
dumb framebuffer for output. The DRM driver for a dumb framebuffer is pretty
simple to write. For the smallest possible system restrict yourself to
OpenGL-ES, statically link to the software Mesa version of it and use a dumb
frame buffer driver. You'll end up with an app the same size as if you used
SVGAlib.



=====
Jon Smirl
jon...@ya...

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com