> Using even the latest kernel my laptop won't shut down the display. It does
> work in windows, so I'd like to get it working in Linux as well. It is a
> Compaq LTE5300, 133Mhz, Cirrus Logic 7543 PCI video. It also no longer turns
> off the power upon halting the machine. It did do that in earlier kernels.
1) Display blanking:
I believe this is an XFree bug. An upgrade to the latest version has
been reported to fix this.
2) Power-off:
User-mode tools problem. Fix your rc scripts or upgrade to the latest
inittools. One or the other should fix the problem.
The cause, I believe, was that a separate syscall was added for
power-off; earlier kernels overloaded the 'halt' syscall.
> The message I get on the console and thru syslog is:
>
> Mar 13 01:25:19 laptop kernel: apm_bios: set display standby: Unrecognized
> device ID
Perhaps I should explain. Display blanking problems come in two varieties
at the moment. XFree bugs (VC blanks; X display doesn't), and BIOS bugs.
> I was working with one of the developers (forgot his name), and he suggested I
> apply a patch:
>
> - --- linux/drivers/char/apm_bios.c.orig Wed Feb 11 01:13:06 1998
> +++ linux/drivers/char/apm_bios.c Thu Feb 12 15:35:55 1998
> @@ -261,7 +261,7 @@
> #define APM_SET_DISPLAY_POWER_STATE(state, error) \
> APM_BIOS_CALL(al) \
> : "=a" (error) \
> - - : "a" (0x5307), "b" (0x01ff), "c" (state) \
> + : "a" (0x5307), "b" (0x0100), "c" (state) \
> APM_BIOS_CALL_END
> #endif
>
> And I also tried 0x0101, 0x0102 to no avail.
The APM standard in from of me says that the major code (MSB) for the
display devices is '01' and the minor code (LSB) 'FF' means 'all of the
minor devices associated with this major device'.
I've had *one* bug report so far where a faulty BIOS didn't recognize the
'FF' lsb to mean 'all such devices' and interpreted 'FF' as 'device number
255'. This is clearly a BIOS bug. Upgrading the BIOS fixed the problem,
but he could hack around it by chaning the above constant '0x01FF' to
'0x100'.
Your BIOS is more seriously broken: it doesn't recognize the display
devices at all, hence the 'unrecognized device id' message in the kernel
logs, which comes straight from the BIOS.
[The mysterious linux-kernel developer you quote was me, BTW. ;-) ]
> I'm using the latest version of the manufacturers BIOS, and it reports on
> bootup:
>
> SystemSoft BIOS for Opti Viper 557/558N 1.01 (2450-73)(Version 7.20)
> SystemSoft Plug-n-Play BIOS
Complain to your vendor. An 'unrecognized device ID' message in response
to device ID 0x01FF is just plain wrong.
Sorry I can't be of more help.
If anyone knows the windows code well, I'd be very curious to find out how
the windows APM code works. I'm not instrumented to investigate this.
I've examined the FreeBSD code thoroughly, and can't find any material
difference between linux-APM and FreeBSD-APM, although I've had several
reports of apm features (save-to-disk, especially) working correctly with
FreeBSD and not working with linux-APM. There is the remote possibility
that some detail of the linux-apm setup is triggering odd
apm-incompatibilities in buggy BIOSes (the linux apm implementation
adheres to the spec *exactly*, so we're talking about BIOSes that assume
some implementation detail *not* covered by the spec). I'm still working
on this, but I've had no luck to date.
If anyone has one of these marginal BIOSes -- especially one with a
verified 'works in windows/BSD, not in linux' feature --- and can provide
a decent disassembly of the BIOS code to allow me to track down this
anomaly, I'd appreciate it.
--Scott
@ @
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-oOO-(_)-OOo-=-=-=-=-=
C. Scott Ananian: cananian@lcs.mit.edu / Declare the Truth boldly and
Laboratory for Computer Science/Crypto / without hindrance.
Massachusetts Institute of Technology /META-PARRESIAS AKOLUTOS:Acts 28:31
-.-. .-.. .. ..-. ..-. --- .-. -.. ... -.-. --- - - .- -. .- -. .. .- -.
PGP key available via finger and from http://www.pdos.lcs.mit.edu/~cananian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu