On 5/21/07, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
quoted text
> 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?

What about modifying the existing fbdev API? You could start with one
fbdev device per CRTC and then add a new IOCTL to control the output
device. I haven't seen anything yet that justifies abandoning the
existing fbdev API.

Note that you could add fbdev API support to the radeon DRM driver.
Preserving the fbdev API doesn't mean that you have to preserve the
old driver code.

-- 
Jon Smirl
jonsmirl@gmail.com
-
unsubscribe notice
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/