Re: OpenGL-based framebuffer concepts

From: D. Hazelton
Date: Tue May 23 2006 - 23:27:18 EST

On Wednesday 24 May 2006 00:10, Kyle Moffett wrote:
> On May 23, 2006, at 13:17:18, Jon Smirl wrote:
> >> By implementing a framework where userspace doesn't have to know -
> >> or care - about the hardware, which, IMNSHO, is the way things
> >> should be, then userspace applications can take advantage of such
> >> a system and be even more stable.
> >
> > A true monolithic design doesn't really work for video hardware. In
> > the monolithic model all devices in a class present a uniform API.
> > The better design for GPUs is the exo-kernel model. DRM already
> > uses the exo-kernel model. With exokernels each driver presents a
> > unique API and userspace libraries are used to provide a uniform API.
> The one really significant potential problem with the exo-kernel
> model for graphics is that the kernel *must* have a stable way to
> display kernel panics regardless of current video mode, framebuffer
> settings, 3D rendering, etc. The kernel driver should be able to
> provide some fundamental operations for compositing text on top of
> the framebuffer at the primary viewport regardless of whatever
> changes userspace makes to the GPU configuration. We don't have this
> now, but I see it as an absolute requirement for any replacement
> graphics system. This means that the kernel driver should be able to
> understand and modify the entire GPU state to the extent necessary
> for such a text console.

For this it's not trivial, but seems to be, on the surface, rather easy to

Since the driver is controlling all aspects of the system - memory and the
like - and doing DMA to/from that memory for userspace accesses why not use
one of the built-in framebuffer fonts and draw the panic directly to the
video memory of the current screen?

Of course there are some times when this might not be possible - most notably
during a display mode switch. In that case I have no solutions, because when
a Panic happens you have no guarantees about the state of the system.

Perhaps have the video-hardware re-initialized on a kexec after the panic and
provide some way for the new kernel to display the panic information?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at