On Sul, 2004-03-14 at 02:50, Jon Smirl wrote:
> 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.
Insufficient for SAK but heading the right way.
> 2) Move the code implementing user console to user space. User console would
> work via ptmx/pts like X terminals.
I'm glad Linus has already vetoed this particular idea.
> 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.
Mergefb is specific to some cards. VIA uses SAAM for example which is
different. Other cards have other rules. I agree you want some of this
in kernel space, because of memory management and locking. VIA for
example has its memory manager in kernel space in part because of this.
You might also want to keep mergefb behaviour and do driver level
clipping depending on the hardware. You simply don't know at any
generic level.
The multi-user stuff btw is mostly console layer breakage in design,
although some bits of PAM go comprehensively tits-up due to design
decisions if they multi-console stuff is done.
> 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.
GL requires too much context to be useful in kernel space. Even things
like tinyGL which are smaller than OpenGL-ES don't solve that. And
openGL (even the full thing) cannot represent many card capabilities, as
well as being catastrophically incapable of performance/accuracy
tradeoffs, or cleanly expressing which paths are efficient or not.
GL is a fine API for scientific 3D, its hackable for gaming, its a joke
as a kernel API. Remember you are responding to an MS proposed
"innovation" thats now very late, and slipping at a rapid rate. That
might just indicate they got it wrong, very wrong.
In fact for 2D you might argue something SVGlike would be more
appropriate as a graphics API, except that too can be in user space.
> > 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?
Not really. SAK requires you can get back to a known state. It certainly
doesn't require you do mode computation in user space, you just need to
know the register values ready.
> 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.
Until one of the apps crashes. And putting OpenGL in the kernel doesnt
work so that doesn't get you out of things.
> 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
Software mesa is slow, large and horribly inefficient. The current mesa
software rendering code is ok for fixing up hardware, but the mesa
design while it now does hardware extremely well seems to do software
rendering extremely slowly. For its current use that is a sane tradeoff.
> 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.
I'll end up with a 2.5Mb application, versus a 35K application using
nanogui using Mesa, I'd end up with a 350K application using tinyGL. And
nanogui would still be way faster.
OpenGL is a diabolically bad interface for the kernel level of things
due to the huge amounts of state. The current DRM may not be perfect
because it does keep too much in user space (and you can see that in the
way DRM modules keep growing private memory management interfaces with
their drivers).
If you look at what you actually need for the kernel and for consoles
you can see its very little indeed.
You need
- Mode switch (but not neccesarily computation except
for the initial modes - which could be tables)
- Accelerated full screen scroll (for console)
- Optionally basic screen2screen bitblit
- Put character/characters
- Hot plug/unplug
- User space acceleration interface (DMA ring, PIO,
MMIO, whatever - varies a lot by card)
- Font table operations (for non bitmap displays)
- Optional frame buffer memory manager
and thats about it.
Text mode consoles are cheap in terms of memory (the Linux one is
actually quite bloated in some ways, but by way of comparison the vt52
console engine in ELKS is about 900 bytes)
Similarly the accelerator ops for the card are cheap as they are in
terms of the accelerator interface for most hardware, or tiny direct
bits of code for non 3D stuff (VGA is one register etc)
So now explain why I want opengl in my kernel, and please please think
about kernel code the right way around. Nasty accidents tend to occur in
design if you think
User->Library->Kernel->Generic Foo->Foo Driver
Flexible design tends to occur when you think
User (optionally using helper library) -> Foo driver (--> libraries)
because the driver is then able to opt out of the "generic" behaviour
decreed by some allseeing (and eventually always wrong) designer.
Alan
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
