Message-ID: <9e4733910705210901v5996cacas640f211404c519c6@mail.gmail.com>
Date:	Mon, 21 May 2007 12:01:30 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc:	"Jon Smirl" <jonsmirl@...il.net>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On 5/21/07, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Sunday, May 20, 2007, Jon Smirl wrote:
> > On 5/20/07, Jesse Barnes <jbarnes@...tuousgeek.org> 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.

> 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.

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.

If the kernel graphics system is going to get rewritten the rewrite
needs to address all of the existing problems.

-- 
Jon Smirl
jonsmirl@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists