| Bug ID | 98149 |
|---|---|
| Summary | EDID doesn't detect resolution 1440x900 correctly NV34 FX5200= Go |
| Product | xorg |
| Version | unspecified |
| Hardware | x86 (IA32) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Driver/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | dino@archlinux.info |
| QA Contact | xorg-team@lists.x.org |
Created attachment 127102 [deta= ils] Dmesg log I have an older laptop Toshiba P25-S609 which has NV34 based graphics (NVID= IA 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.0= 4.1 and newer) image on screen is displayed really weird. It is split in 4 part= s, and then it is shown from right to left (inverted). With xrandr --newmode a= nd 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=3D0x1e nouveau.debug=3Dd= ebug, and vbios.rom from /sys/kernel/debug/dri/0/ and it is here:=20 http://filebin.ca/2xex= yy0VGT9L/vbios.rom Here is the image of what it does look like:=20 http://imgur.com/a/ZUi0j=20 Dmesg log is attached below.
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=20
EndSection
Which is obviously crap - no modelines are given, that's why we pick the
default 1024x768 & co modelines. Investigating further about how this u=
sed 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 u=
se
it.
Would you be so kind as include a dmesg with drm.debug=3D0x1e nouveau.debug=
=3Ddebug
from a working kernel?
Thanks for your kind reply. Here is the dmesg log and vbios.ro= m 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.
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...
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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/iss= ues/289.