Re: [RFC] enhancing the kernel's graphics subsystem

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Monday, May 21, 2007, Helge Hafting wrote:
> >> > TThe problem with that is the concept of heads is flawed... there
> >> > is in reality no such
> >> > thing, you have crtcs and outputs, no heads. So any attempt to
> >> > enforce the head concept involves putting policy into the kernel,
> >> > as if I have 3 outputs but 2 crtcs how do I decide the mappings
> >> > without the admin telling the kernel,
> >>
> >> Solution:
> >> One device per crtc. You can then have two users, running consoles
> >> or xservers on their crtcs, without having to involve root.
> >
> > Thats pretty much what the code does, but you still are putting a
> > certain amount of policy in the kernel...
>
> What policy would that be?
> The mapping is set by root from userspace, not by the kernel.
> The same for ownership to crtc devices. The kernel may have to
> provide some default so "init=/bin/sh" will work, that's all.

The policy of mapping outputs to CRTCs.  Like Dave said, you may have 
several outputs but only one or two CRTCs, with limitations on how they 
can be routed.  So doing "one device per CRTC" isn't quite enough, you 
also have to choose an initial output setup.  But like you say this could 
be changed at boot time.

> Sure.  Not multiseat by default, as the kernel can't know which output
> goes with which keyboard. All I want it a system that allows
> multiseat for those that care to set it up.

Sure, and like I mentioned to Jon in another mail, a decent multiseat setup 
is possible with these interfaces, albeit with a userlevel graphics daemon 
to arbitrate what the CRTC->output mappings are and to coordinate access 
to the hw if needed.

So really, I think the interfaces posted here will do what you want.  Maybe 
you can take a closer look and make sure?

Thanks,
Jesse