From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: dri-devel@lists.sourceforge.net
Subject: Re: [RFC] enhancing the kernel's graphics subsystem
Date: Tue, 22 May 2007 09:57:40 -0700
User-Agent: KMail/1.9.6
Cc: Philipp Klaus Krause <pkk@spth.de>, linux-kernel@vger.kernel.org
References: <200705171423.46748.jesse.barnes@intel.com> <1179792587.32247.769.camel@localhost.localdomain> <46531A55.9090403@spth.de>
In-Reply-To: <46531A55.9090403@spth.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200705220957.40218.jbarnes@virtuousgeek.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1542
Lines: 33

On Tuesday, May 22, 2007, Philipp Klaus Krause wrote:
> Benjamin Herrenschmidt schrieb:
> >> In collaboration with the FB guys, we've been working on enhancing
> >> the
> >> kernel's graphics subsystem in an attempt to bring some sanity to the
> >> Linux graphics world and avoid the situation we have now where
> >> several
> >> kernel and userspace drivers compete for control of graphics devices.
>
> What's the difference between this and Jon Smirls' proposals from early
> 2005?

There are lots of differences.  From memory, Jon tried to enhance the FB 
layer to do modesetting with an eye toward multiseat support.  Modes were 
set by echoing values into sysfs, and iirc it didn't tie into the DRM 
layer at all or use proper memory management.

These patches use ioctls on the DRM device for modesetting (at least for 
now), and provide userspace with maximum flexibility.  Framebuffer objects 
are allocated using the new DRM memory manager, and any FB devices created 
are slaves of the DRM layer, avoiding some of the fighting over 
suspend/resume and graphics programming.

Many of the aims are the same though, Jon was trying to address many of the 
problems outlined in my initial mail too, we just have different opinions 
about how exactly those problems should be solved. :)

Jesse
-
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/