Fedora 14 x86_64
[ 375.231] (II) intel(0): Integrated Graphics Chipset: Intel(R) GM45
[ 375.231] (--) intel(0): Chipset: "GM45"
startx yields:
2.6.38-git2 and earlier: correct 1440x900 display
2.6.38-git3 through -git6: not tested due to kernel build errors
2.6.38-git7 through -git14: wrong 1024x768 display with black bands at sides
Once in wrong mode, xrandr --fb 1440x900 --output LVDS1 --mode 1440x900
helps return the screen to correct display, but:
- background image is drawn incorrectly (like a 1440x900 correct one with a
superimposed 1024x768 starting from upper left corner)
- mplayer in full screen mode does not actually go full screen, but 1024x768
comparative Xorg logs and dmesg output for 2.6.38-git2 and -git14 available
upon request; lspci -v says:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at f6c00000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at ef98 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 0233
Flags: bus master, fast devsel, latency 0
Memory at f6b00000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3
thanks,
--alessandro
?"There's always a siren singing you to shipwreck"
?? (Radiohead, "There There")
On Thu, 24 Mar 2011 12:30:49 +0100, Alessandro Suardi <[email protected]> wrote:
> Fedora 14 x86_64
>
> [ 375.231] (II) intel(0): Integrated Graphics Chipset: Intel(R) GM45
> [ 375.231] (--) intel(0): Chipset: "GM45"
>
> startx yields:
>
> 2.6.38-git2 and earlier: correct 1440x900 display
> 2.6.38-git3 through -git6: not tested due to kernel build errors
> 2.6.38-git7 through -git14: wrong 1024x768 display with black bands at sides
>
> Once in wrong mode, xrandr --fb 1440x900 --output LVDS1 --mode 1440x900
> helps return the screen to correct display, but:
>
> - background image is drawn incorrectly (like a 1440x900 correct one with a
> superimposed 1024x768 starting from upper left corner)
> - mplayer in full screen mode does not actually go full screen, but 1024x768
>
> comparative Xorg logs and dmesg output for 2.6.38-git2 and -git14 available
> upon request; lspci -v says:
There's not much we can say until we see those...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Mar 24, 2011 at 12:45 PM, Chris Wilson <[email protected]> wrote:
> On Thu, 24 Mar 2011 12:30:49 +0100, Alessandro Suardi <[email protected]> wrote:
>> Fedora 14 x86_64
>>
>> [ ? 375.231] (II) intel(0): Integrated Graphics Chipset: Intel(R) GM45
>> [ ? 375.231] (--) intel(0): Chipset: "GM45"
>>
>> startx yields:
>>
>> ?2.6.38-git2 and earlier: correct 1440x900 display
>> ?2.6.38-git3 through -git6: not tested due to kernel build errors
>> ?2.6.38-git7 through -git14: wrong 1024x768 display with black bands at sides
>>
>> Once in wrong mode, xrandr --fb 1440x900 --output LVDS1 --mode 1440x900
>> ?helps return the screen to correct display, but:
>>
>> ?- background image is drawn incorrectly (like a 1440x900 correct one with a
>> ? ? superimposed 1024x768 starting from upper left corner)
>> ?- mplayer in full screen mode does not actually go full screen, but 1024x768
>>
>> comparative Xorg logs and dmesg output for 2.6.38-git2 and -git14 available
>> ?upon request; lspci -v says:
>
> There's not much we can say until we see those...
> -Chris
OK - attaching in .tgz as they'd probably cross lkml size limits:
[root@duff ~]# tar tvzf logs.tgz
-rw-r--r-- root/root 54172 2011-03-24 10:14 dmesg-2638git14.out
-rw-r--r-- root/root 51464 2011-03-24 10:23 dmesg-2638git2.out
-rw-r--r-- root/root 106118 2011-03-24 10:15 Xorg.0.log-2638git14
-rw-r--r-- root/root 107744 2011-03-24 10:23 Xorg.0.log-2638git2
thanks,
--alessandro
?"There's always a siren singing you to shipwreck"
?? (Radiohead, "There There")
On Thu, 24 Mar 2011 13:03:55 +0100, Alessandro Suardi <[email protected]> wrote:
> OK - attaching in .tgz as they'd probably cross lkml size limits:
Ok, the clue to the bizarre sizing is:
[ 376.501] (WW) intel(0): No outputs definitely connected, trying again...
[ 376.501] (II) intel(0): Output LVDS1 connected
[ 376.501] (II) intel(0): Output VGA1 disconnected
[ 376.501] (II) intel(0): Output HDMI1 disconnected
[ 376.501] (II) intel(0): Output DP1 disconnected
[ 376.501] (II) intel(0): Output HDMI2 disconnected
[ 376.501] (II) intel(0): Output DP2 disconnected
[ 376.501] (II) intel(0): Output DP3 disconnected
[ 376.501] (II) intel(0): Output TV1 connected
[ 376.502] (II) intel(0): Using fuzzy aspect match for initial modes
[ 376.502] (II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
[ 376.502] (II) intel(0): Output TV1 using initial mode 1024x768 +0+0
Transient false TV detection rears its ugly head again. (It's detected
during the 'working' setup but then disappears upon reprobing.) So X
choose the intersection of the available modes, 1024x768. But that
doesn't explain why the LVDS exists (it prints the EDID for it) but it
thinks it is disconnected.
The difference in the dmesg is:
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0x92/0xa6()
Hardware name: Latitude E6400
sysfs: cannot create duplicate filename
'/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/device'
Modules linked in: i915(+) drm_kms_helper drm i2c_algo_bit i2c_core video
Pid: 906, comm: modprobe Not tainted 2.6.38-git14 #1
Call Trace:
[<ffffffff8103319b>] warn_slowpath_common+0x80/0x98
[<ffffffff81033247>] warn_slowpath_fmt+0x41/0x43
[<ffffffff811253d0>] sysfs_add_one+0x92/0xa6
[<ffffffff81125ad6>] sysfs_do_create_link+0xf3/0x186
[<ffffffffa000175f>] acpi_video_bus_add+0x982/0xc87 [video]
which can be temporary fixed by reverting 9661e92c10a97752. But I don't
immediately see how that would cause the LVDS to be declared disconnected.
Can you add drm.debug=0xe to your grub kernel parameters and attach a
fresh dmesg?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Mar 24, 2011 at 1:27 PM, Chris Wilson <[email protected]> wrote:
> On Thu, 24 Mar 2011 13:03:55 +0100, Alessandro Suardi <[email protected]> wrote:
>> OK - attaching in .tgz as they'd probably cross lkml size limits:
>
> Ok, the clue to the bizarre sizing is:
>
> [ ? 376.501] (WW) intel(0): No outputs definitely connected, trying again...
> [ ? 376.501] (II) intel(0): Output LVDS1 connected
> [ ? 376.501] (II) intel(0): Output VGA1 disconnected
> [ ? 376.501] (II) intel(0): Output HDMI1 disconnected
> [ ? 376.501] (II) intel(0): Output DP1 disconnected
> [ ? 376.501] (II) intel(0): Output HDMI2 disconnected
> [ ? 376.501] (II) intel(0): Output DP2 disconnected
> [ ? 376.501] (II) intel(0): Output DP3 disconnected
> [ ? 376.501] (II) intel(0): Output TV1 connected
> [ ? 376.502] (II) intel(0): Using fuzzy aspect match for initial modes
> [ ? 376.502] (II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
> [ ? 376.502] (II) intel(0): Output TV1 using initial mode 1024x768 +0+0
>
> Transient false TV detection rears its ugly head again. (It's detected
> during the 'working' setup but then disappears upon reprobing.) So X
> choose the intersection of the available modes, 1024x768. But that
> doesn't explain why the LVDS exists (it prints the EDID for it) but it
> thinks it is disconnected.
>
> The difference in the dmesg is:
>
> ------------[ cut here ]------------
> WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0x92/0xa6()
> Hardware name: Latitude E6400
> sysfs: cannot create duplicate filename
> '/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/device'
> Modules linked in: i915(+) drm_kms_helper drm i2c_algo_bit i2c_core video
> Pid: 906, comm: modprobe Not tainted 2.6.38-git14 #1
> Call Trace:
> ?[<ffffffff8103319b>] warn_slowpath_common+0x80/0x98
> ?[<ffffffff81033247>] warn_slowpath_fmt+0x41/0x43
> ?[<ffffffff811253d0>] sysfs_add_one+0x92/0xa6
> ?[<ffffffff81125ad6>] sysfs_do_create_link+0xf3/0x186
> ?[<ffffffffa000175f>] acpi_video_bus_add+0x982/0xc87 [video]
>
> which can be temporary fixed by reverting 9661e92c10a97752. But I don't
> immediately see how that would cause the LVDS to be declared disconnected.
> Can you add drm.debug=0xe to your grub kernel parameters and attach a
> fresh dmesg?
The WARNING is a separate issue which popped up later.
Summarizing in this respect,
2.6.38-git2: no WARNING, correct display
2.6.38-git3..6: no tests performed due to kernel build failure
2.6.38-git7..11: no WARNING, wrong display
2.6.38-git12-13: no tests performed due to no time
2.6.38-git14: WARNING present, wrong display
Here you go with the drm debug dmesg for -git14... thanks !
--alessandro
?"There's always a siren singing you to shipwreck"
?? (Radiohead, "There There")
The LVDS connector should default to connected. We tried our best to
verify the claims of the BIOS that the hardware exists during init(),
and then during detect() we then try to verify that the panel is open.
In the event of an unsucessful query, we should then always report
that the LVDS panel is connected. This was only the case for gen3/4,
later generations leaked the return value from the panel probe instead.
Reported-by: Alessandro Suardi <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
---
drivers/gpu/drm/i915/intel_lvds.c | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index 1a311ad..86cd30b 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -473,19 +473,13 @@ static enum drm_connector_status
intel_lvds_detect(struct drm_connector *connector, bool force)
{
struct drm_device *dev = connector->dev;
- enum drm_connector_status status = connector_status_connected;
+ enum drm_connector_status status;
status = intel_panel_detect(dev);
if (status != connector_status_unknown)
return status;
- /* ACPI lid methods were generally unreliable in this generation, so
- * don't even bother.
- */
- if (IS_GEN2(dev) || IS_GEN3(dev))
- return connector_status_connected;
-
- return status;
+ return connector_status_connected;
}
/**
--
1.7.4.1
On Thu, Mar 24, 2011 at 2:30 PM, Chris Wilson <[email protected]> wrote:
> The LVDS connector should default to connected. We tried our best to
> verify the claims of the BIOS that the hardware exists during init(),
> and then during detect() we then try to verify that the panel is open.
> In the event of an unsucessful query, we should then always report
> that the LVDS panel is connected. This was only the case for gen3/4,
> later generations leaked the return value from the panel probe instead.
>
> Reported-by: Alessandro Suardi <[email protected]>
> Signed-off-by: Chris Wilson <[email protected]>
With this patch on top of 2.6.38-git14, I am back to 1440x900 by default.
Great work, thanks Chris ! FWIW, You can add my
Tested-by: Alessandro Suardi <[email protected]>
> ---
> ?drivers/gpu/drm/i915/intel_lvds.c | ? 10 ++--------
> ?1 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
> index 1a311ad..86cd30b 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -473,19 +473,13 @@ static enum drm_connector_status
> ?intel_lvds_detect(struct drm_connector *connector, bool force)
> ?{
> ? ? ? ?struct drm_device *dev = connector->dev;
> - ? ? ? enum drm_connector_status status = connector_status_connected;
> + ? ? ? enum drm_connector_status status;
>
> ? ? ? ?status = intel_panel_detect(dev);
> ? ? ? ?if (status != connector_status_unknown)
> ? ? ? ? ? ? ? ?return status;
>
> - ? ? ? /* ACPI lid methods were generally unreliable in this generation, so
> - ? ? ? ?* don't even bother.
> - ? ? ? ?*/
> - ? ? ? if (IS_GEN2(dev) || IS_GEN3(dev))
> - ? ? ? ? ? ? ? return connector_status_connected;
> -
> - ? ? ? return status;
> + ? ? ? return connector_status_connected;
> ?}
>
> ?/**
> --
> 1.7.4.1
>
>
--alessandro
?"There's always a siren singing you to shipwreck"
?? (Radiohead, "There There")