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?
-Casey Dahlin
[email protected]
On Sat, 2006-11-25 at 00:54 -0500, Casey Dahlin 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?
the "real" solution is to have a small video driver in the kernel that
knows at least how to get back to text mode. It sounds obscene to some,
but if you get down to it it's not all that bad; the policy of what
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...
--
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
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
> 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.
On Sat, Nov 25, 2006 at 04:10:43PM +0000, 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]
On Sat, 2006-11-25 at 16:10 +0000, 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
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
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
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.
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
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.