Hi!
> >> I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram
> >> identifies it with
> >>
> >> sys_vendor = "Sony Corporation "
> >> sys_product = "PCG-SRX51P(DE) "
> >> sys_version = "01 "
> >> bios_version = "R0232U2"
> >>
> >> Suspend to RAM by using "s2ram -v -m -f" actually works and the
> >> laptop comes back to life, is accessible by network, etc. kudos
> >> so far.
> >> The only but serious problem is, that the lcd stays off after
> >> resume. No matter what kind of options for s2ram I try, if I disable
> >
> > Is the _lcd_ off or the _backlight_ off? Use bright flashlight to
> > tell.
>
> The lcd. If you press the lid button you get the same effect (but you
> cannot use it to turn the lcd on again :-(( ). But I'll doublecheck with
> a flashlight nevertheless.
If lid button breaks the lcd, even in grub boot loader... then I'd
call your machine broken hardware, complain to the manufacturer. (Are
you at latest BIOS?)
> >> framebuffer or suspend from X, the lcd always stays off. Only
> >> a reboot fixes this. Note that the X driver also cannot dis-/enable
> >> the lcd (xset dpms force off). It always stays lit. I also tried
> >> with i810switch, but that also does not affect the lcd.
> >> spicctrl -b42 neither.
> >> Latest kernel I tested is 2.6.20-git11 from today.
> >>
> >> So has anyone of you suspend, acpi, sonypi, fb people an idea how to fix
> >> this? I suspect one has to call some magic ACPI method upon resume? What
> >> other kind of information would be needed to debug this? Anything more
> >> to try? Are there some sony people here listening who can fix this?
> >
> > sonypi people actually might know how to help...
> >
> >> 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC
> > [Chipset Graphics Controller] (rev 11)
> >
> > Wait a moment, did not Intel release nice, commented, GPLed sources
> > for their graphics cards somewhere? That might help.
>
> URL? But I suspect the lcd on/off is controlled by some embedded controller
> or such (reachable via acpi, at least I've an EC0 in /proc/acpi/).
Google a bit, it was a _big_ announcement. Of course it is _possible_ EC
is responsible, but I don't quite think so.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
