Re: OpenGL-based framebuffer concepts

[David Lang <dlang@digitalinsight.com>]

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/