Messages in this thread | | | From | "D. Hazelton" <> | Subject | Re: OpenGL-based framebuffer concepts | Date | Tue, 23 May 2006 23:27:49 +0000 |
| |
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 accomplish.
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?
DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |