Messages in this thread | | | Date | Thu, 1 Jun 2006 07:59:22 -0700 (PDT) | From | David Lang <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
On Thu, 1 Jun 2006, Jon Smirl wrote:
> 1) The kernel subsystem should be agnostic of the display server. The > solution should not be X specific. Any display system should be able > to use it, SDL, Y Windows, Fresco, etc... > > 2) State inside the hardware is maintained by a single driver. No > hooks for state swapping (ie, save your state, now I'll load mine, > ...). > > 3) A non-root user can control their graphics device. > > 4) Multiple independent users should work > > 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. > > 6) Things like panics should be visible no matter what is running. No > more silent deaths. > > 7) Obviously part of this is going to exist in user space since some > cards can only be controlled by VBIOS calls. Has anyone explored using > the in-kernel protected mode VESA hooks for this? > > 8) The user space fbdev API has to be maintained for legacy apps. DRM > can be changed if needed since there is only a single user of it, but > there is no obvious need to change it. > > 9) there needs to be a way to control the mode on each head, merged fb > should also work. Monitor hotplug should work. Video card hot plug > should work. These should all work for console and the display > servers. > > 10) Console support for complex scripts should get consideration. > > 11) VGA is x86 specific. Solutions have to work on all architectures. > That implies that the code needed to get a basic console up needs to > fit on initramfs. Use PPC machines as an example. > > 12) If a driver system is loaded is has to inform the kernel of what > resources it is using. >
13) for hardware that supports it a text mode should be supported
David Lang - 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/
| |