On Monday, May 21, 2007, Jon Smirl wrote:
> On 5/21/07, Jesse Barnes <[email protected]> wrote:
> > On Sunday, May 20, 2007, Jon Smirl wrote:
> > > On 5/20/07, Jesse Barnes <[email protected]> wrote:
> > > > With the interfaces implemented here, a userspace application can
> > > > create a multiseat environment either with a single graphics card
> > > > with multiple outputs or multiple cards. It could do this by
> > > > creating several frame buffer objects and associating them with
> > > > whatever CRTCs were available, and managing input via existing
> > > > APIs. I don't know of anyone that's done this yet though...
> > >
> > > This design still requires a global server app since the heads share
> > > a single device.
> > > I am always concerned that the root priv code in the X server is a
> > > potential security hole. I would like to move away from a model
> > > where there is a global controlling app. I don't think we need a
> > > global controlling app at all.
> >
> > Even without a graphics server of some sort arbitrating access (and it
> > doesn't have to be a big as the current X server btw), you'd still
> > need your apps to take a card specific lock and/or coordinate so that
> > they don't clobber one another's rendering results. This could be
> > done in the kernel, but for many devices the complexity added is
> > likely to be pretty high.
>
> We have already have the card specific locks, it's how Direct Rendering
> works.
>
> Besides, card locks are a much better design that the free for all
> that happens on a VT switch.
Right, I'm just saying there's much more to it than just having the
hardware locks (which of course we already have).
> There is more to fbdev than mode setting. It is also how non-x86
> platforms achieve their boot display. How will boot display be handled
> with the your design? What about console display on non-x86 platforms?
> Loading both fbdev and the new code puts us right back into the
> multiple driver fight we have today.
Maybe you should take a look at the patches. :) The code I posted actually
creates an fb device as a slave of the DRM device, and uses that for the
boot console. Once you've booted, you can use the new interfaces to do
whatever you want with the graphics device... though it doesn't
create /dev/fb* devices per-CRTC like you seem to want, it's really easy
to do the equivalent with a small userspace program (though I haven't
actually tested sharing of buffer objects, it should work).
> If the kernel graphics system is going to get rewritten the rewrite
> needs to address all of the existing problems.
Sure, I have no problem with that, but there are usually lots of ways to
solve a given problem.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
