Re: i915 backlight failure on resume with 2.6.27
On Tue, 2008-12-09 at 13:38 +, Sergio Monteiro Basto wrote: OK , at least on Fedora 10, we have on updates. A new kernel with message: Additional DRM/modesetting fixes for i915 and radeon drivers. A new release of Mesa and a new release of drv-intel (which in fedora still called i810, may be its time to change the name of drive for Intel no?) Well, I filed a bug in the redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=474376 Just in case anyone over there was interested; although it looks like a simple error in backporting the i915 drm to me since the kernel.org kernel works just fine. I assume it will correct itself when FC9 moves over to a 2.6.28 kernel. James ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
On Thu, 2008-12-11 at 14:37 -0600, James Bottomley wrote: A new release of Mesa and a new release of drv-intel (which in fedora still called i810, Have you tried this 2 updates ? to me seems that I have some improvements on resume even without update kernel. Regards, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
OK , at least on Fedora 10, we have on updates.
A new kernel with message: Additional DRM/modesetting fixes for i915
and radeon drivers.
A new release of Mesa and a new release of drv-intel (which in fedora
still called i810, may be its time to change the name of drive for Intel
no?)
On Tue, 2008-12-02 at 17:52 +, Sergio Monteiro Basto wrote:
On Tue, 2008-12-02 at 11:38 -0600, James Bottomley wrote:
On Tue, 2008-12-02 at 13:08 +, Sergio Monteiro Basto wrote:
On Mon, 2008-12-01 at 11:42 -0600, James Bottomley wrote:
You probably remember the system, it's my fujitsu P7120 lifebook with
the funny backlight wiring.
Previously, suspend/resume was made to work by saving the PCI state
including the legacy backlight register setting (and worked just fine
when invoked with a hal quirk).
On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and
relies on the i915 kernel driver. This was perfectly fine, except that
the backlight was now being restored to full brightness on resume rather
than the setting on resume. The other annoyance was that VT consoles
were now lost on resume (switching to them produces a black screen,
although switching back to vt7 where X is running is fine).
As of the 2.6.27 fedora kernels, the backlight is now off on resume,
which is even more annoying. It can be turned on by doing a VT switch,
although all the console VTs are still blank, so there looks to be some
bug in the i915 driver that crept in between 2.6.26 and 2.6.27.
Hum as quick answer , kernel fedora 2.6.27 have change _DOS thing.
So may be that is the problem.
The fedora patch is talked about on lkml
http://lkml.org/lkml/2008/11/10/233
Actually, they haven't. I'm running 2.6.27.5-41.fc9.i686 and if I look
in the kernel SRPM for that kernel (by building it) the relevant area of
drivers/acpi/video.c is
ok , I forgot , fedora kernels 2.6.27 for fc10. Also don't know the
state of Arlied drm stuff, if it is only on fc10 or not .
I trace this information on :
http://koji.fedoraproject.org/koji/packageinfo?packageID=8
/* acpi_video interface */
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0, 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0, 1);
}
So nothing's changed in that area since 2.6.26.
It could still be a disagreement between ACPI, BIOS and the driver over
who turns on the backlight, but the loss of the text console strongly
suggests that something is slightly wrong with the VGA modes.
About this _DOS , I reported this problem a long time ago, which now
is on http://bugzilla.kernel.org/show_bug.cgi?id=6001
James
--
Sérgio M. B.
smime.p7s
Description: S/MIME cryptographic signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
On Tue, Dec 02, 2008 at 01:08:50PM +, Sergio Monteiro Basto wrote: Hum as quick answer , kernel fedora 2.6.27 have change _DOS thing. So may be that is the problem. The fedora patch is talked about on lkml http://lkml.org/lkml/2008/11/10/233 About this _DOS , I reported this problem a long time ago, which now is on http://bugzilla.kernel.org/show_bug.cgi?id=6001 No, _DOS has nothing to do with the behaviour on resume. -- Matthew Garrett | [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
On Tue, 2008-12-02 at 13:08 +, Sergio Monteiro Basto wrote:
On Mon, 2008-12-01 at 11:42 -0600, James Bottomley wrote:
You probably remember the system, it's my fujitsu P7120 lifebook with
the funny backlight wiring.
Previously, suspend/resume was made to work by saving the PCI state
including the legacy backlight register setting (and worked just fine
when invoked with a hal quirk).
On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and
relies on the i915 kernel driver. This was perfectly fine, except that
the backlight was now being restored to full brightness on resume rather
than the setting on resume. The other annoyance was that VT consoles
were now lost on resume (switching to them produces a black screen,
although switching back to vt7 where X is running is fine).
As of the 2.6.27 fedora kernels, the backlight is now off on resume,
which is even more annoying. It can be turned on by doing a VT switch,
although all the console VTs are still blank, so there looks to be some
bug in the i915 driver that crept in between 2.6.26 and 2.6.27.
Hum as quick answer , kernel fedora 2.6.27 have change _DOS thing.
So may be that is the problem.
The fedora patch is talked about on lkml
http://lkml.org/lkml/2008/11/10/233
Actually, they haven't. I'm running 2.6.27.5-41.fc9.i686 and if I look
in the kernel SRPM for that kernel (by building it) the relevant area of
drivers/acpi/video.c is
/* acpi_video interface */
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0, 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0, 1);
}
So nothing's changed in that area since 2.6.26.
It could still be a disagreement between ACPI, BIOS and the driver over
who turns on the backlight, but the loss of the text console strongly
suggests that something is slightly wrong with the VGA modes.
About this _DOS , I reported this problem a long time ago, which now
is on http://bugzilla.kernel.org/show_bug.cgi?id=6001
James
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915 backlight failure on resume with 2.6.27
On Mon, 2008-12-01 at 11:42 -0600, James Bottomley wrote: You probably remember the system, it's my fujitsu P7120 lifebook with the funny backlight wiring. Previously, suspend/resume was made to work by saving the PCI state including the legacy backlight register setting (and worked just fine when invoked with a hal quirk). On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and relies on the i915 kernel driver. This was perfectly fine, except that the backlight was now being restored to full brightness on resume rather than the setting on resume. The other annoyance was that VT consoles were now lost on resume (switching to them produces a black screen, although switching back to vt7 where X is running is fine). As of the 2.6.27 fedora kernels, the backlight is now off on resume, which is even more annoying. It can be turned on by doing a VT switch, although all the console VTs are still blank, so there looks to be some bug in the i915 driver that crept in between 2.6.26 and 2.6.27. Jesse asked for the reg dump from xf86-video-intel-2.4.3, so here it is: (II): DumpRegsBegin (II):VCLK_DIVISOR_VGA0: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II):VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6) (II):VCLK_POST_DIV: 0x00800080 (vga0 p1 = 2, p2 = 4, vga1 p1 = 2, p2 = 2) (II):DPLL_TEST: 0x00010001 () (II): CACHE_MODE_0: 0x6820 (II): D_STATE: 0x (II):DSPCLK_GATE_D: 0x1000 (clock gates disabled: DPLUNIT) (II): RENCLK_GATE_D1: 0x (II): RENCLK_GATE_D2: 0x (II):SDVOB: 0x0030 (disabled, pipe A, stall disabled, not detected, SDVO mult 1) (II):SDVOC: 0x0030 (disabled, pipe A, stall disabled, not detected, SDVO mult 1) (II): SDVOUDI: 0x00ff (II): DSPARB: 0x1d9c (II): DSPFW1: 0x (II): DSPFW2: 0x (II): DSPFW3: 0x (II): ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) (II): LVDS: 0xc0200300 (enabled, pipe B, 18 bit, 1 channel) (II): DVOA: 0x (disabled, pipe A, no stall, -hsync, -vsync) (II): DVOB: 0x0030 (disabled, pipe A, no stall, -hsync, -vsync) (II): DVOC: 0x0030 (disabled, pipe A, no stall, -hsync, -vsync) (II): DVOA_SRCDIM: 0x (II): DVOB_SRCDIM: 0x (II): DVOC_SRCDIM: 0x (II): PP_CONTROL: 0x0001 (power target: on) (II):PP_STATUS: 0xc008 (on, ready, sequencing idle) (II): PFIT_CONTROL: 0x0008 (II): PFIT_PGM_RATIOS: 0x (II): PORT_HOTPLUG_EN: 0x (II):PORT_HOTPLUG_STAT: 0x (II): DSPACNTR: 0xd900 (enabled, pipe B) (II): DSPASTRIDE: 0x2000 (8192 bytes) (II): DSPAPOS: 0x (0, 0) (II): DSPASIZE: 0x02ff04ff (1280, 768) (II): DSPABASE: 0x0100 (II): DSPASURF: 0x (II): DSPATILEOFF: 0x (II):PIPEACONF: 0x (disabled, single-wide) (II): PIPEASRC: 0x027f01df (640, 480) (II):PIPEASTAT: 0x (status:) (II): FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): DPLL_A: 0x0480 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 8, p2 = 10) (II):DPLL_A_MD: 0x (II): HTOTAL_A: 0x031f027f (640 active, 800 total) (II): HBLANK_A: 0x03170287 (648 start, 792 end) (II): HSYNC_A: 0x02ef028f (656 start, 752 end) (II): VTOTAL_A: 0x020c01df (480 active, 525 total) (II): VBLANK_A: 0x020401e7 (488 start, 517 end) (II): VSYNC_A: 0x01eb01e9 (490 start, 492 end) (II):BCLRPAT_A: 0x (II): VSYNCSHIFT_A: 0x (II): DSPBCNTR: 0x4900 (disabled, pipe B) (II): DSPBSTRIDE: 0x0400 (1024 bytes) (II): DSPBPOS: 0x (0, 0) (II): DSPBSIZE: 0x018f02cf (720, 400) (II): DSPBBASE: 0x (II): DSPBSURF: 0x (II): DSPBTILEOFF: 0x (II):PIPEBCONF: 0x8000 (enabled, single-wide) (II): PIPEBSRC: 0x04ff02ff (1280, 768) (II):PIPEBSTAT: 0x8242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS) (II): FPB0: 0x00021006 (n = 2, m1 = 16, m2 = 6) (II): FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8) (II): DPLL_B: 0x9802 (enabled, non-dvo, default clock, LVDS mode, p1 = 2, p2 = 14) (II):DPLL_B_MD: 0x (II): HTOTAL_B: 0x069704ff (1280 active, 1688 total) (II): HBLANK_B: 0x069704ff (1280 start, 1688 end) (II):
i915 backlight failure on resume with 2.6.27
You probably remember the system, it's my fujitsu P7120 lifebook with the funny backlight wiring. Previously, suspend/resume was made to work by saving the PCI state including the legacy backlight register setting (and worked just fine when invoked with a hal quirk). On FC9, with the 2.6.26 fedora kernels, hal no longer does anything and relies on the i915 kernel driver. This was perfectly fine, except that the backlight was now being restored to full brightness on resume rather than the setting on resume. The other annoyance was that VT consoles were now lost on resume (switching to them produces a black screen, although switching back to vt7 where X is running is fine). As of the 2.6.27 fedora kernels, the backlight is now off on resume, which is even more annoying. It can be turned on by doing a VT switch, although all the console VTs are still blank, so there looks to be some bug in the i915 driver that crept in between 2.6.26 and 2.6.27. James ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
