lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 26 Oct 2009 02:52:30 +0100
From:	Peter Stuge <>
To:	Riccardo Magliocchetti <>
Subject: Re: no video output after suspend after "drm/i915: force mode set
	at lid open time"


Riccardo Magliocchetti wrote:
> i lost video output, screen stays black, after suspend after commit
> c1c7af60892070e4b82ad63bbfb95ae745056de0 "drm/i915: force mode set at lid 
> open time".

I also experience this symptom.

I have an IBM ThinkPad X40, chipset with integrated 855GM graphics.

The last release kernel I used was 2.6.30, with DRI enabled but no fb.
Gentoo xorg-server- with xf86-video-intel-2.7.1. All vanilla
kernels. With that kernel I would get the mode back on restore, but
the panel backlight would not come on, so it would be very difficult
to see the screen contents, especially in dim environments. documents this symptom on X40 and many other models.
One suggested workaround is to chvt 1 and save a copy of the VGA
device PCI config space right before echo mem > /sys/power/state,
and write it back and run vbetool post immediately after resume,
followed by chvt 7 (or wherever X is). This workaround functioned
fairly well for me, but not always reliably, and of course it's a
bit of a hack. :)

I am now running drm-intel.git a83a44 from Oct 14 with KMS enabled
and xf86-video-intel 1556c62 from Oct 8, and the workaround
(understandably) does not function anymore. I've tried permutations
with only saving PCI config space and only running vbetool but no go.

(Before this I tried with KMS, but it didn't do Xv.)

(Oh, and Xv performance with a83a44+1556c6 is lower than 2.6.30 nofb,
but that's somewhat secondary. MPlayer performs worse than VLC, but
both are worse than MPlayer with 2.6.30+2.7.1.)

Can I help solve this somehow?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists