linux-kernel - Re: Proposal for a low-level Linux display framework

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110915181802.69ef0d56@lxorguk.ukuu.org.uk>
Date:	Thu, 15 Sep 2011 18:18:02 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	Keith Packard <keithp@...thp.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linaro-dev@...ts.linaro.org,
	"Clark\, Rob" <rob@...com>, Archit Taneja <archit@...com>
Subject: Re: Proposal for a low-level Linux display framework

> is and we could use it. Such attitude is not helpful and as I don't see any
> serious intention of the DRM guys to cooperate I think those subsystems are more
> likely to diverge. At least I'll never accept any change to the fb
> infrastructure that requires DRM.

There are aspects of the fb code that want changing for DRM (and indeed
modern hardware) but which won't break for other stuff. Given the move to
using main memory for video and the need for the OS to do buffer
management for framebuffers I suspect a move to DRM is pretty much
inevitable, along with having to fix the fb layer to cope with
discontiguous framebuffers.

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