Re: OpenGL-based framebuffer concepts

[Jon Smirl]

On 6/1/06, D. Hazelton <dhazelton@xxxxxxxxx> wrote:
> On Thursday 01 June 2006 20:35, Jon Smirl wrote:
> > On 6/1/06, D. Hazelton <dhazelton@xxxxxxxxx> wrote:
> > > > > 5) The system needs to be robust. Daemons can be killed by the OOM
> > > > > mechanism, you don't want to lose your console in the middle of
> > > > > trying to fix a problem. This also means that you have to be able to
> > > > > display printk's from inside interrupt handles.
> > >
> > > Point of disagreement. Tons of userspace helpers isn't a good choice.
> >
> > Where do you get 'tons'? There will probably be one for initial reset,
> > one for VESA based mode setting and a few more if there is device
> > specific code needed for a specific card.
> >
> > Making console rely on a permanent daemon that is subject to getting
> > killed by the OOM mechanism is not a workable solution.
> >
> > You also need to think about how cursors are handled. A non-root app
> > needs to be able to move the cursor. Actually moving the cursor
> > requires root. The in-kernel console system needs a cursor. It would
> > be much better if cursor control was implemented in the device
> > drivers.
>
> Yes, the basic console will only require a few helpers. I get "tons" because
> that's what it would take to provide all the acceleration features to
> userspace. The daemon is *only* there to provide those acceleration features.
> The kernel itself has it's own minimal interface to drmcon that lets it work
> without userspace. The userspace side is for userspace. (Though the kernel
> will only work in a specific set mode without the userspace helpers for
> setting the mode)

You don't need a ton of helpers for acceleration, Mesa already supports this.

Handling accelerated console is discussed in my paper, but here are
the highlights.

If you examine console you will see that there are two kinds of users,
normal people running emacs/etc and system management needs like
panics and single user mode. Normal users want acceleration, system
management needs absolute robustness. Currently these two uses are
mixed up into a single console,. I think they should be separated
since they clearly have different requirements.

One solution to this split is to build the system management console
in-kernel using the existing fbdev code. A hot key can be used to
access it or it will appear automatically on a panic. The system
management console does not need acceleration, but it always has to
work and work in any context (like interrupt context). Working in any
context forces an implementation that is entirely contained in the
kernel.

For a normal user's accelerated console, build one in user space, use
Mesa or whatever. I'm not going to start a debate on this point. Once
you are in user space you can add Asian language support too.

For people that refuse to use the user space console they can use the
system management mode. If you really want to accelerate this console
you will have to add entry points to the DRM driver; the
implementation of the system management console has to stay entirely
inside the kernel. Since there is only going to be one set of
acceleration code, the entry points have to go in the DRM driver. I
would not recommend doing this because it won't be safe to use the
acceleration hardware in all cases where the system management console
may need to print.

If people are going to whine about the size of Mesa they can implement
OpenGL/ES on top of DRM. Since there is a commercial OpenGL/ES
implementation that is 100K it is proven that this can be done with a
tiny library. All that has to happen is for someone to write the
library. If you really want to whine build a 2D only library on top of
DRM.

Since the system management console can pop up at anytime and in the
context of an unstable system, I really think it should be designed to
use the currently active mode instead of trying to change the mode.
Changing the mode may require a trip to user space and user space may
be dead. The fbdev code already knows how to draw into any framebuffer
format from kernel context.

--
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/