Bug 98149 - EDID doesn't detect resolution 1440x900 correctly NV34 FX5200Go
Summary: EDID doesn't detect resolution 1440x900 correctly NV34 FX5200Go
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-07 15:15 UTC by Dino
Modified: 2019-12-04 09:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Dmesg log (115.34 KB, text/x-log)
2016-10-07 15:15 UTC, Dino
no flags Details
vbios rom (60.00 KB, application/octet-stream)
2016-10-07 15:31 UTC, Dino
no flags Details
dmesg working log (105.04 KB, text/x-log)
2016-10-08 05:22 UTC, Dino
no flags Details
vbios working rom (60.00 KB, application/octet-stream)
2016-10-08 05:22 UTC, Dino
no flags Details

Description Dino 2016-10-07 15:15:30 UTC
Created attachment 127102 [details]
Dmesg log

I have an older laptop Toshiba P25-S609 which has NV34 based graphics (NVIDIA FX5200Go). With 4.2 kernel and lower (and possibly 4.3) native resolution 1440x900 is detected properly. With 4.4 kernel and newer (e.g. Xubuntu 16.04.1 and newer) image on screen is displayed really weird. It is split in 4 parts, and then it is shown from right to left (inverted). With xrandr --newmode and cvt 1440 900 I can set the resolution, but then tty is still messed up.
I have tried to get the bug with options drm.debug=0x1e nouveau.debug=debug, and vbios.rom from /sys/kernel/debug/dri/0/ and it is here: 
http://filebin.ca/2xexyy0VGT9L/vbios.rom

Here is the image of what it does look like: 
http://imgur.com/a/ZUi0j 

Dmesg log is attached below.
Comment 1 Dino 2016-10-07 15:31:31 UTC
Created attachment 127104 [details]
vbios rom
Comment 2 Ilia Mirkin 2016-10-08 00:46:11 UTC
Looks like the included EDID in the VBIOS is:

00000000  00 ff ff ff ff ff ff 00  2e 0d 00 00 00 00 00 00  |................|
00000010  04 09 01 02 80 00 00 00  e2 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 08 00 01 01  01 01 01 01 01 01 01 01  |................|
00000030  01 01 01 01 01 01 64 19  00 40 41 00 26 30 18 88  |......d..@A.&0..|
00000040  36 00 00 00 00 00 00 18  00 00 00 00 00 00 00 00  |6...............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 ff  |................|

Which decodes to

Checksum Correct

Section "Monitor"
        Identifier ""
        ModelName ""
        VendorName "KPM"
        # Monitor Manufactured week 4 of 1999
        # EDID version 1.2
        # Digital Display
        # Display Physical Size not given. Normal for projectors.
        Gamma 1.00
        Option "DPMS" "true"
        Modeline        "Mode 0" -hsync -vsync 
EndSection

Which is obviously crap - no modelines are given, that's why we pick the default 1024x768 & co modelines. Investigating further about how this used to work. (Also manufactured in early 1999 seems surprising given that this is a probably 2004 or so laptop...) But the checksum checks out, so we happily use it.

Would you be so kind as include a dmesg with drm.debug=0x1e nouveau.debug=debug from a working kernel?
Comment 3 Dino 2016-10-08 05:21:39 UTC
Thanks for your kind reply. Here is the dmesg log and vbios.rom from the working kernel 4.2.8. I am aware of that this is an old laptop, I am just curious to find out what is the cause of this bug.
Comment 4 Dino 2016-10-08 05:22:24 UTC
Created attachment 127132 [details]
dmesg working log
Comment 5 Dino 2016-10-08 05:22:56 UTC
Created attachment 127133 [details]
vbios working rom
Comment 6 Ilia Mirkin 2016-10-08 06:10:44 UTC
Right, so as I expected, the working version has

[    2.538445] nouveau  [     DRM] BIOS FP mode: 1440x900 (96210kHz pixel clock)

So we messed something up, since we no longer follow down that path in nouveau_bios.c. Perhaps ->is_mobile is no longer getting set to true? Or some other reason...
Comment 7 Martin Peres 2019-12-04 09:17:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/289.


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.