linux-kernel - Re: [RFC] enhancing the kernel's graphics subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200705220957.40218.jbarnes@virtuousgeek.org>
Date:	Tue, 22 May 2007 09:57:40 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	dri-devel@...ts.sourceforge.net
Cc:	Philipp Klaus Krause <pkk@...h.de>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/