![]() | |||||||||||||
Messages in this thread |
On 11/27/06, Alan <alan@lxorguk.ukuu.org.uk> wrote: > On Sun, 26 Nov 2006 09:18:41 +0100 > Arjan van de Ven <arjan@infradead.org> wrote: > > > The mode switch sequences for modern cards are a bit more hairy than > > > lists of I/O poking unfortunately. > > > > for the Intel hw Keith doesn't seem to think it's all that much of a > > problem though... > > Including the TV out, odder LCD panels, non BIOS modes etc ? If so then > it might be an interesting test case for intelfb to grow some kind of > console helper interface > It's non-trivial, I think you are better off going initially with just using the current framebuffer that X is using, I know ajax was doing some hacking on this with a "user"-framebuffer, until I disuaded him due to I think the trouble caused by dual-head and something else I can't remember.. I personally think we need to probably just bite the bullet and start sticking graphics drivers into the kernel, the new randr-1.2 interface for X is probably a good starting point for a generic mode setting interface that isn't so X dependent and could replace fbdev with something more sane wrt dualhead and multiple outputs... fbdev could be implemented on top of that layer then.. also suspend/resume really needs this sort of thing.... My main worry with integrating graphics drivers into the kernel is that when they don't work the user gets no screen, with network/sound etc this isn't so bad, but if they can't see a screen debugging gets to be a bit more difficult.... Dave. - 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/ | ||||||||||||
| Last update: 2006-11-26 22:23 [from the cache] ©2003-2008 | |||||||||||||