Re: LCD sync rates
On Thu, Jun 28, 2001 at 08:21:15PM -0700, Heather wrote:
> > On Thu, Jun 28, 2001 at 10:59:28AM -0700, Heather wrote:
> > > > and the slightest variation can result in a black screen when your start
> > > > the X server.
> > >
> > > I recommend having your net connection live and be ssh'd in from another box.
> > > That keeps you a visible text session.
> > >
> > > You can sometimes use a different GUI utility (e.g. SVGAlib app, or vga_reset
> > > or something) to reinit the video and keep working without having to reboot
> > > to yank its chain.
> >
> > CTRL+ALT+backspace or CTRL+ALT+F1 still work even when the display
> > doesn't want to show you anything.
>
> Not necessarily. The X server is also responsible for input focus - one might
> argue that's its primary job - and if it's *really* unhappy, it won't get around
> to your useful keystroke.
Hmm, good point. That makes sense, given my past experience with X...
> Too busy dealing with a crying vidcard. Maybe next
> week sometime.
>
> Meanwhile your monitor is squealing at you :( :( :(
The X server doesn't know that the monitor isn't syncing, since the
vid card doesn't act any differently whether the monitor handles the
video output or not. (I think it can detect whether or not a monitor
is connected, though.) I don't know if this is the case for most LCD
displays in laptops, or if the video controller will stop working if
the vid mode is out of range. That wouldn't make much sense though,
because that would make it hard to get back to a working range...
>
> > If the X server locks up, you can
> > always use alt+sysrq+u, alt+sysrq+b
>
> Magic sysrq's might only work at a console prompt. cf above, your keyboard
> may be inoperable.
No, they always work, since it's all in the kernel, before it goes
through the "keyboard mode" stuff that kbdmode messes with. That
being the case, it doesn't matter if X is running and has your
keyboard in raw mode. You obviously don't see the output from your
keystrokes, but they show up in the kernel log messages, even
alt+sysrq+?.
Err, one other thing that can bring down alt+sysrq: The system could
deadlock with interrupts disabled, in which case you lose, and nothing
will ever get through, not ethernet, not mouse, not keyboard, not
serial. I don't think X can disable interrupts, though, so as long as
the kernel isn't buggy, you're fine (he says optimistically... :)
Anyway, we both agree that logging in remotely is the way to go. I
was just pointing out that, especially for this problem, you can get
away with not doing that if you can deal with the system when it's
having problems. (For the display-won't-sync problem,
nothing is going to happen that overwrites the kernel in memory or
whatever, so it's unlikely that the system will hang and require a
reboot.)
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Reply to: