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
| ||
|
Date: Tue, 22 May 2007 10:09:47 +1000 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: Jesse Barnes <jesse.barnes@...el.com> Cc: linux-kernel@...r.kernel.org, James Simmons <jsimmons@...tafluge.infradead.org>, Dave Airlie <airlied@...il.com>, "Antonino A. Daplas" <adaplas@...il.com>, dri-devel@...ts.sourceforge.net Subject: Re: [RFC] enhancing the kernel's graphics subsystem > 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. .../... A little note about initial mode setting at boot... I do stongly beleive that the decision of what mode to choose should not be made in the kernel. At boot the kernel should either leave the HW in whatever state the FW set it (and text mode is fine) or setup some sane default (ie 640x480 has the most chances of working) if that's not an option, maybe some very minimum EDID parsing in case you have a fixed frequency weirdo panel, but that's it (unless it's a mac an OF tells you what to use :-) The kernel would provide userland with connector infos (presence load detect, EDID, ...) and userland gets to decide what to do. Some reasons to keep that policy completely out of the kernel even at boot time are: - User may want to configure his default gfx setup and have it up early - EDID do lie, monitors routinely ship with windows .inf files containing "updated" infos apple has that too in OS X (EDID overrides afaik) etc.... and if we're going to do such a database of known monitors, it should definitely not be in the kernel. Besides, we want to add more infos that EDIDs don't provide most of the time to it like subpixel ordering etc... - It sounds better that way :-) (yeah, that's the best reason !) So while I agree that the register frobbing, memory management, etc... should be indeed moved to the kernel as you guys have been doing lately, the policy of deciding what mode to set should totally stick to userland. IMHO, the best would be a lib (or daemon or both) for monitor detection & mode setting that is separate from X :-) That could handle storing the admin's default setup (including weird monitor info if any) and restoring it at boot time, etc... Cheers, Ben. - 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