Re: [Linux-fbdev-devel] Re: Ruby redux

[Benjamin H. <be...@ke...>]

> The next generation X server will be based totally on top of OpenGL using 
> drm/fbdev. I'm going to be working with him to make sure that it supported 
> full multihead support!!!!! We will not have to do anymore X server hacks. 
> All the X Server hack on the PCI bus will go away. So we have alot of work 
> ahead. I say by next year this time main stream linux will be 
> multi-desktop ready. 

In fact, DRM handles hardware access arbitration. Wether it's
3D/GL/whatever depends on what userland client library is used.

For "legacy" cards, we can perfectly have a 2D driver using DRM to
submit commands (or beeing allowed to mmap the registers the good old
way eventually) and a server built on top of this (hint hint:
kdrive ? :)

The main ideas is to have a common mode setting and hw access
arbitration (& command submiting, DMA/AGP management etc...)
infrastructure that isn't in the server.

Wether you then use a 2D userland driver, a 3D userland driver, XGL on
top of the later, or whatever else is pretty much irrelevant.

I may want to rework a bit of the fbdev mode setting API if I can find
time to work on this. It needs some better ways to determine "related"
framebuffers, trigger re-probe of outputs, play with the output mapping,
and get hotplug events to userland. It also need to properly work with
the DRM for access arbitration to the HW. There are a lot of issues to
deal with before we can safely change modes on the fly while a 3D server
is running, but we'll have to be capable of it ultimately.

Ben.