On Sunday 26 November 2006 17:19, Dave Airlie wrote: > On 11/27/06, Alan <[EMAIL PROTECTED]> wrote: > > On Sun, 26 Nov 2006 09:18:41 +0100 > > > > Arjan van de Ven <[EMAIL PROTECTED]> 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....
I've been working on this myself. Unfortunately the box I was using for devel has died and the start I made on the work was lost several months ago when I had a hard drive die on me. (I really need to go buy a UPS and a better surge protector - the box I was doing devel on bought it in a lightning strike and the hard drive I had used as a backup just died) > 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.... Yeah - this is why the work I was doing kept the old vgacon around and used fbcon on those platforms that needed it (unchanged). My plan was to add a graphics system that would "take over" from the boot console when it was ready to take over. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/