| Summary: | [915GM] Incorrect modeline due to incorrect EDID block for LG SL80 TV | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Paul Menzel <paulepanter> |
| Component: | General | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | paulepanter |
| Version: | DRI git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Paul Menzel
2012-08-15 14:56:28 UTC
(In reply to comment #0) > The LG SL80 TV exhibits the same garbled screen as reported in #26294 [1] when > connecting an ASUS Eee PC 701 4G over VGA. > > This is just a separate report for this particular TV and a patch is going to > be send to the list. Log files are included in comment 26294#c20 and comment > 26294#c21 of the referenced report. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 It looks like I messed up the mark up [2][3]. [2] https://bugs.freedesktop.org/show_bug.cgi?id=26294#c20 [3] https://bugs.freedesktop.org/show_bug.cgi?id=26294#c21 Just a test: bug 26294 ticket 26294 report 26294 comment #26294#c20 report 26294#c20 (In reply to comment #1) […] > Just a test: > > bug 26294 > ticket 26294 > report 26294 > comment #26294#c20 > report 26294#c20 bug 26294 comment 20 should work [1]. [1] http://www.mail-archive.com/tools-discuss@opensolaris.org/msg04107.html Here is the (decoded) EDID.
$ ./edid-decode lg.edid
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 1e 6d 01 00 01 01 01 01 02 13
version: 01 03
basic params: 68 73 41 78 0a
chroma info: cf 74 a3 57 4c b0 23 09 48 4c
established: a1 08 00
standard: 81 80 61 40 45 40 31 40 01 01 01 01 01 01 01 01
descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 7e 8a 42 00 00 1e
descriptor 2: 01 1d 00 72 51 d0 1e 20 6e 28 55 00 7e 8a 42 00 00 1e
descriptor 3: 00 00 00 fd 00 3a 3e 1e 53 10 00 0a 20 20 20 20 20 20
descriptor 4: 00 00 00 fc 00 4c 47 20 54 56 0a 20 20 20 20 20 20 20
extensions: 00
checksum: 1d
Manufacturer: GSM Model 1 Serial Number 16843009
Made week 2 of 2009
EDID version: 1.3
Analog display, Input voltage level: 0.7/0.7 V
Sync: Separate
Maximum image size: 115 cm x 65 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Established timings supported:
720x400@70Hz
640x480@60Hz
800x600@60Hz
1024x768@60Hz
Standard timings supported:
1280x1024@60Hz
1024x768@60Hz
800x600@60Hz
640x480@60Hz
Detailed mode: Clock 148.500 MHz, 1150 mm x 650 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
Detailed mode: Clock 74.250 MHz, 1150 mm x 650 mm
1280 1390 1430 1650 hborder 0
720 725 730 750 vborder 0
+hsync +vsync
Monitor ranges: 58-62Hz vertical, 30-83kHz horizontal, max dotclock 160MHz
Monitor name: LG TV
Checksum: 0x1d (valid)
Patch sent to the dri-devel list [1]. [1] http://lists.freedesktop.org/archives/dri-devel/2012-August/026476.html (In reply to comment #4) > Patch sent to the dri-devel list [1]. > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-August/026476.html TLDR: A T60 with a 945GM/GMS(?) controller works without that patch with Linux 3.2.x. I am petrified. Testing this TV with a T60 and a different VGA cable (all pins populated, instead of Pin 9 missing) everything works fine (besides a little vertical shift to the right). :/ $ lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01) 15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller The read EDID is the same. $ xrandr -q --verbose […] VGA1 connected 1920x1080+0+0 (0xb9) normal (normal left inverted right x axis y axis) 1150mm x 650mm Identifier: 0x42 Timestamp: 222127 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: DVI1 CRTC: 0 CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff001e6d010001010101 02130103687341780acf74a3574cb023 09484ca1080081806140454031400101 010101010101023a801871382d40582c 45007e8a4200001e011d007251d01e20 6e2855007e8a4200001e000000fd003a 3e1e5310000a202020202020000000fc 004c472054560a20202020202020001d 1920x1080 (0xb9) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz 1280x1024 (0x47) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x720 (0xba) 74.2MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.0KHz v: height 720 start 725 end 730 total 750 clock 60.0Hz 1024x768 (0x4c) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x4d) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 640x480 (0x4f) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 60.0Hz 640x480 (0xbb) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz v: height 480 start 489 end 492 total 525 clock 59.9Hz 720x400 (0xbc) 28.3MHz -HSync +VSync h: width 720 start 738 end 846 total 900 skew 0 clock 31.5KHz v: height 400 start 412 end 414 total 449 clock 70.1Hz DVI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 222127 Subpixel: horizontal rgb Clones: VGA1 CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: Here is the excerpt from `/var/log/Xorg.0.log`. [ 282.004] (II) intel(0): EDID vendor "GSM", prod id 1 [ 282.004] (II) intel(0): Using hsync ranges from config file [ 282.004] (II) intel(0): Using vrefresh ranges from config file [ 282.004] (II) intel(0): Printing DDC gathered Modelines: [ 282.004] (II) intel(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) [ 282.004] (II) intel(0): Modeline "1280x720"x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e) [ 282.004] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 282.005] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 282.005] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 282.005] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 282.005] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) So I am puzzled. Could it be a specific problem to the chipset 915GM? Created attachment 67539 [details]
`/var/log/Xorg.0.log` from T60
Created attachment 67540 [details]
`xrandr -q --verbose` from T60
Comparing the modelines from the `xrandr -q --verbose` output they are the same, which is even more confusing.
From Lenovo T60.
1920x1080 (0xb9) 148.5MHz +HSync +VSync *current +preferred
h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz
v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz
From ASUS EeePC 701 4G. The `*current` is missing, because when capturing it, I had to go back to LVDS, since it did not work by default.
1920x1080 (0xbd) 148.5MHz +HSync +VSync +preferred
h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.5KHz
v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz
To be clear, both systems use the same Linux kernel and userspace (Debian Sid/unstable). (In reply to comment #5) > (In reply to comment #4) > > Patch sent to the dri-devel list [1]. > > > > [1] http://lists.freedesktop.org/archives/dri-devel/2012-August/026476.html > > TLDR: A T60 with a 945GM/GMS(?) controller works without that patch with > Linux 3.2.x. > > I am petrified. Testing this TV with a T60 and a different VGA cable (all > pins populated, instead of Pin 9 missing) everything works fine (besides a > little vertical shift to the right). :/ Testing the T60 with the VGA cable with Pin 9 missing, it still works. So this problem is 915GM specific. Created attachment 68066 [details]
output of Linux kernel 3.2.23 ring buffer (dmesg)
As j4ni requested on IRC here is the output from `dmesg` from the 915GM
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
with Linux 3.2.23 and `drm.debug=0xe`. Though the `PIPE A underrun` message more or less kicked the beginning out. I will repost that too.
$ xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
$ xrandr --addmode VGA1 1920x1080R
$ xrandr --output VGA1 --mode 1920x1080R
$ xrandr --output VGA1 --mode 1920x1080R --output LVDS1 --off
$ dmesg > 20121004--eeepc-701-4g-VGA-1--mode.dmesg
Created attachment 68072 [details] output of Linux kernel 3.2.23 ring buffer (dmesg) (In reply to comment #11) > Created attachment 68066 [details] > output of Linux kernel 3.2.23 ring buffer (dmesg) > > As j4ni requested on IRC here is the output from `dmesg` from the 915GM > > $ lspci | grep VGA > 00:02.0 VGA compatible controller: Intel Corporation Mobile > 915GM/GMS/910GML Express Graphics Controller (rev 04) > > with Linux 3.2.23 and `drm.debug=0xe`. Though the `PIPE A underrun` message > more or less kicked the beginning out. I will repost that too. Here it is. $ xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync $ xrandr --addmode VGA1 1920x1080R $ xrandr --output VGA1 --mode 1920x1080R $ xrandr --output VGA1 --mode 1920x1080R --output LVDS1 --off $ dmesg > 20121004--eeepc-701-4g-VGA-1--mode--LVDS-off.dmesg Created attachment 68073 [details]
T60 (945GM): output of Linux kernel 3.2.23 ring buffer (dmesg)
Here is the output from `dmesg` from the T60 having the LG SL80 connected over from the VGA from the beginning an image is shown but not in the correct resolution. But it is shown.
$ xrandr --output VGA1 --auto
$ xrandr --output VGA1 --auto --output LVDS1 --off
$ dmesg > 20121004.1.tv-on--VGA1--auto--LVDS1--off.dmesg
In #intel-gfx, ajax confirmed that this is probably a bug in the 915(GM) part of the driver. Unfortunately Intel has not yet released the gen3 documentation, so for non-Intel employees it will be hard to fix this issue. Comparing register dumps of a working and non-working Linux kernel would be one option, but unfortunately as seen in bug 26294 I could not find a working one, although I think it is a regression. In the meantime ajax asked me if vesa works (boot with `nomodeset`) and I will try to get back with this information as soon as possible. Hi, Freedesktop's Bugzilla instance is EOLed and open bugs are about to be migrated to http://gitlab.freedesktop.org. To avoid migrating out of date bugs, I am now closing all the bugs that did not see any activity in the past year. If the issue is still happening, please create a new bug in the relevant project at https://gitlab.freedesktop.org/drm (use misc by default). Sorry about the noise! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.