Messages in this thread | | | Date | Thu, 1 Jun 2006 12:59:31 -0400 | From | "Jon Smirl" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
On 6/1/06, Ondrej Zajicek <santiago@mail.cz> wrote: > On Wed, May 31, 2006 at 12:39:19AM -0400, Jon Smirl wrote: > > >Yes, but I have accepted that there is a certain direction and order the > > >maintainers want things done in. For this reason I can't just leave DRM > > >alone. > > > > fbdev (Antonino A. Daplas <adaplas@gmail.com>) and DRM (Dave Airlie > > <airlied@gmail.com>) have two different maintainers. I have not seen > > Tony comment on what he thinks of Dave's plans so I don't know what > > his position is how driver merging can be acomplished. > > Is there some document describing long-term direction or plans for this? > (another than http://jonsmirl.googlepages.com/graphics.html) > I googled for last Kernel Summit mentioned here but didn't found anything > specific.
I wish everyone involved would write up their positions. It is very hard trying to determine what someone's overall plan is based on hundreds of emails spread over multiple lists.
Half of what we are auguring about probably isn't even a real issue, it is just mistaken perceptions of what the other parties want.
It doesn't even need to be a global write up. I'd just like to see design write ups for the kernel issues around fbdev, console, DRM integration, boot display, device nodes, multiuser console, etc. Leave out everything around X and OpenGL. Since there aren't very many ways to solve these problems I suspect everyone is closer together than we may think.
Without specifying a design here are a few requirements I would have:
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.
-- Jon Smirl jonsmirl@gmail.com - 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/
| |