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.
OTOH, if you're just talking about mapping sections of VRAM to user level
processes to manage as indpendent heads, that's fairly trivial to do as
you say, but you'd almost certainly want acceleration for any sort of real
world application, which is where things would get tricky.
> How are you reconciling the introduction of a new mode setting API
> with the 90 existing fbdev drivers? We clearly don't want two
> competing APIs in the kernel. What's the plan for converting all of
> the existing drivers?
My initial plan was to only convert drivers to this new API if they had
hardware that justified a DRM driver (i.e. high performance devices with
command ring buffers, 3D, etc.), and leave the other FB drivers alone,
since the FB layer is quite suited to simple devices.
The other option of course is to port the existing drivers over to the new
modesetting interfaces, though I suspect in many cases that may not be
particularly useful. I'm open to suggestions.
Thanks,
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]
