New DRM model

Benjamin Herrenschmidt benh@kernel.crashing.org
Tue, 10 Feb 2004 08:59:36 +1100


> Why does general purpose mode setting need to be in the kernel? It's a 100K of
> code. We're only talking about about the few seconds between power-on and early
> user space starting. After we get early user-space I use it to run the mode code
> in user space.

I'm talking about the part of the code blasting the card registers. The
mode setting cannot be completely general purpose anyway. The choice of
a mode depends on things that can be quite specific to a given card,
like memory organisation, common ratio for mirroring, etc...

So far, the idea we discussed with Keith would be to have a userland
library independent on the xserver proper providing the mode setting
"API", allowing to query the various cards & heads capabilities,
triggering new probes, and changing the configuration. It would also
deal with the overall display geometry (where each screen is located
relative to the next one).

But the actual _implementation_ of this library has to use some per-card
knowledge at 2 stages: Upon a user mode setting request, to decide what
effective mode can/will be used, and that can affect the "other" card's
head as well (like when enabling mirroring with an external 4:3 display,
the internal non-4:3 flat panel may be resized to a 4:3 ratio).

And then, once the full configuration for the card is decided, the
actual blasting of registers, which should be done by the kernel for
security reasons. (Or a trusted root process, but I'd prefer avoiding
yet another daemon).
 
> Does your hardware power on to a visible configuration? If so why can't we use
> that until early user-space starts? If not, the DRM driver could be hardwired to
> start the card out in 640x480 until early user-space starts.
> 
> Note that the new model only applies to DRM devices. Everthing else would
> continue with the old code.

Which is wrong. We are looking into a model replacing everything at this
point, simpler and saner if possible, and designed around the DRI needs,
for sure, but not limited to it.

Ben.