Re: Overriding X on panic
Hi! > >> 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 ... > 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 Yes, pretty please... > 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 You can have my hgc card + monitor if it helps :-). Okay, it is old ISA, so it probably does not, but with serial or netconsole debugging should be doable, no? Pavel -- Thanks for all the (sleeping) penguins. - 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/
Re: Overriding X on panic
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/
Re: Overriding X on panic
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 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Overriding X on panic
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 Alan - 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/
Re: Overriding X on panic
Alan wrote: On Sat, 25 Nov 2006 00:54:53 -0500 Casey Dahlin <[EMAIL PROTECTED]> wrote: Linus did say that he would do anything within reason to help desktop linux forward, and frankly a big step forward would be to get error messages to the user. What might be some safe options for overriding, switching away from, killing, or otherwise disposing of the X server when an unrecoverable Oops is about to occur on the TTY? Assuming frame buffer support is present in the kernel you need an ioctl that specifies the frame buffer depth/layout so the kernel can print correctly on it. At that point most of the time you'll get the report out - more than trying to mode switch probably. Send patches Alan I agree. Getting the kernel to write out to the current display mode, instead of having to change display mode would be less risky. It does not have to be fast, and would only need a very simple font, enough to display an oops. Other options are enabling some sort of oops writing to some PCI cards. E.g. Some Creative sound cards remember some settings over a warm boot, so one could write out the oops there, and have code to auto detect it when the system is rebooted. I only noticed this when reverse engineering some creative sound cards, and rebooting from windows to linux made my test linux driver make sound, but would only work if one booted into windows first, then warm boot to linux. How many bytes are needed for an oops? James - 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/
Re: Overriding X on panic
On Sat, 2006-11-25 at 16:10 +, Alan wrote: > > modesettings to use can still be in userspace, the execution of the > > series of IO's would be in the kernel, and the kernel would store > > bundles of settings, including a "rescue" one, but also for > > suspend/resume... > > 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... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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/
Re: Overriding X on panic
On Sat, Nov 25, 2006 at 04:10:43PM +, Alan wrote: > > modesettings to use can still be in userspace, the execution of the > > series of IO's would be in the kernel, and the kernel would store > > bundles of settings, including a "rescue" one, but also for > > suspend/resume... > > The mode switch sequences for modern cards are a bit more hairy than > lists of I/O poking unfortunately. The int 10 call to get back to text mode generally seems to work, but, uh. Yeah. Maybe not. (I'm sure nobody would /really/ object to linking x86emu into the kernel...) -- Matthew Garrett | [EMAIL PROTECTED] - 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/
