Bug 74164

Summary: [NV04] Native monitor resolution missing
Product: xorg Reporter: Mauro Molinari <mauromol>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Output of "xrandr -q"
none
Output of "xrandr --verbose"
none
Output of "monitor-get-edid -v | monitor-parse-edid -v"
none
Output of "grep . /sys/class/drm/card*-*/*"
none
Output of "monitor-get-edid -v >monitor-get-edid.bin"
none
dmesg output with debug options enabled none

Description Mauro Molinari 2014-01-28 22:39:11 UTC
Using Fedora 19 on a Graphics Blaster Riva TNT card.

The monitor resolutions made available by the system are:
1024x768 60.0Hz
800x600 60.3Hz and 56.2Hz
848x480 60.0Hz
640x480 59.9Hz

However, the monitor native resolution is 1280x1024 and the refresh rate can be up to 75Hz (72Hz is also supported in Windows).

The output from "xrandr -q" and "monitor-get-edid -v | monitor-parse-edid -v" mismatch. The latter shows that the suggested resolution is indeed 1280x1024 (60.0Hz).

If I do:
xrandr --newmode "1280x1024@60" 108 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync
xrandr --addmode VGA-1 1280x1024@60

and then I change the monitor settings from X, I can use that resolution indeed.

I'm going to attach the output of xrandr -q and monitor-*-edid.
Other information about my card (POST trace, BIOS dump) can be found attached to bug #68835.
Comment 1 Mauro Molinari 2014-01-28 22:40:31 UTC
Created attachment 92961 [details]
Output of "xrandr -q"
Comment 2 Mauro Molinari 2014-01-28 22:41:02 UTC
Created attachment 92962 [details]
Output of "xrandr --verbose"
Comment 3 Mauro Molinari 2014-01-28 22:42:33 UTC
Created attachment 92963 [details]
Output of "monitor-get-edid -v | monitor-parse-edid -v"
Comment 4 Mauro Molinari 2014-01-28 22:45:37 UTC
Another strange thing: if I type something like "monitor-parse-edid --help", I get the following message:

Unknown option: help
usage: monitor-parse-edid [-v] [--perl] [<edid file>]
You can also do "xrandr --prop | monitor-parse-edid"

However, if I type "xrandr --prop | monitor-parse-edid" as suggested, I get:

bad edid

In fact, the output of "xrandr --prop" is the same as "xrandr -q", which is not an edid file, but rather plain text. I don't know if this is normal.

Please tell me if I need to attach other information.
Comment 5 Ilia Mirkin 2014-01-29 00:04:43 UTC
Can you provide the output of

grep . /sys/class/drm/card*-*/*

As well as separately attach /sys/class/drm/card0-VGA-1/edid (or whatever the name of the output the monitor is actually hooked up to) -- this should be a binary file containing your edid as seen by nouveau.

Lastly, please supply the output of "monitor-get-edid -v" (I have no idea where this program comes from or exactly what it does, but it'd be interesting to see that result).
Comment 6 Mauro Molinari 2014-01-29 07:43:34 UTC
Created attachment 92970 [details]
Output of "grep . /sys/class/drm/card*-*/*"
Comment 7 Mauro Molinari 2014-01-29 07:47:10 UTC
/sys/class/drm/card0-VGA-1/edid is an empty file (0 bytes).
I tried to both cat it or cp it to my home directory for attachment, as a normal user as well as root, but it's always an empty file.
Comment 8 Mauro Molinari 2014-01-29 08:04:32 UTC
Created attachment 92971 [details]
Output of "monitor-get-edid -v >monitor-get-edid.bin"

Here is the output of "monitor-get-edid -v >monitor-get-edid.bin". This command also produced the following output on the console:

probing EDID using VBE (port 0)
VBE version: 3.0, oem version = 2.4
Memory: 4096k
OEM name: NVidia
Vendor name: NVidia
Product name: Riva TNT
Product revision: A5
Port 0:
  DDC1 not supported
  DDC2 supported
  Screen not blanked during data transfer
  Time to transfer one EDID block: 1 sec (rounded up)

Please note that to successfully execute this command I have to previously do:

setsebool mmap_low_allowed 1

otherwise the invocation of monitor-get-edid prints:

probing EDID using VBE (port 0)
mmap /dev/mem: Permission denied
VBE: could not initialize LRMI
VBE info call failed, skipping all ports

The monitor-get-edid command comes from Fedora "monitor-edid" package. A "yum info monitor-edid" produces:

Name        : monitor-edid
Arch        : i686
Version     : 3.0
Release     : 6.fc19
Size        : 119 k
Repo        : installed
From repo   : fedora
Summary     : Tool for probing and parsing monitor EDID
URL         : http://wiki.mandriva.com/en/Tools/monitor-edid
Licence     : GPLv3+
Description : Monitor-edid is a tool for probing and parsing Extended display
            : identification data (EDID) from monitors.
            : For more information about EDID, see
            : http://en.wikipedia.org/wiki/EDID
Comment 9 Mauro Molinari 2014-01-29 08:29:19 UTC
Please note I'm using a KVM switch, I don't know if this can make any difference.

Also, I have another glitch. I set the following in the screensaver settings of Fedora (I'm using the LXDE edition):
- screen saver disabled
- display power management enabled
  - standby after 2 minutes
  - suspend after 3 minutes
  - off after 5 minutes
However, the monitor never goes to sleep or off, in any way, even if I leave it on for, say, 10 minutes.
The best I can do is to turn on the screen saver and set it so that the monitor is blanked after x minutes, however it stays on (I can see that looking at the monitor led on its frame - green if on, orange if sleeping, off if off).

Is this yet another problem? Or might it be related to this one?
Comment 10 Ilia Mirkin 2014-01-29 18:22:01 UTC
Well, if that EDID file is empty, that explains everything else. So now the question is -- why is the EDID file empty? (As for the dpms thing -- I suspect it's related -- sounds like DDC isn't working.)

The KVM thing _might_ explain the situation, would be worth trying without it.
Comment 11 Mauro Molinari 2014-01-30 07:58:09 UTC
Hi Ilia,
I just tried without the KVM switch, by connecting the monitor, mouse and keyboard directly to the PC. Unfortunately, nothing changes, that edid file is still empty.
What else can we try? Who is responsible for the generation of that file? (I guess it's a special file...)
Comment 12 Ilia Mirkin 2014-01-30 21:17:48 UTC
(In reply to comment #11)
> Who is responsible for the generation of that file? (I
> guess it's a special file...)

nouveau is responsible for reading out the EDID and providing it to the drm core, which in turn exposes it in that file. See nouveau_connector_detect. (Unfortuantely it's all a bit obtuse... the DDC stuff goes through i2c, etc.)
Comment 13 Mauro Molinari 2014-01-30 21:39:26 UTC
I see... so, what can I do now to try to understand why that file is not filled in by nouveau?

monitor-edid talks about some different ways to get the edid: VBE (through BIOS interruption 10h), ACPI 2.0, Open Firmware, Kernel mode-setting (which is not working in our case). Another tool, read-edid (http://polypux.org/projects/read-edid/) seems to use the i2c interface, but I've not tried to see if it works.

Looking at the monitor-edid output, it seems like it's using the VBE mode to correctly get this information, but I have to do a "setsebool mmap_low_allowed 1" previously to make it actually work. Could this be somewhat related to the fact that nouveau can't get the information?
Comment 14 Ilia Mirkin 2014-01-30 21:47:31 UTC
(In reply to comment #13)
> I see... so, what can I do now to try to understand why that file is not
> filled in by nouveau?

Try to follow the code and see where things go wrong. Boot with nouveau.debug=trace perhaps someone left some interesting nv_debug/nv_trace statements somewhere. Also throw in drm.debug=0xe for good measure -- a lot of the pre-nv50 code still relies on that being set to emit debug statements.

> 
> monitor-edid talks about some different ways to get the edid: VBE (through
> BIOS interruption 10h), ACPI 2.0, Open Firmware, Kernel mode-setting (which
> is not working in our case). Another tool, read-edid
> (http://polypux.org/projects/read-edid/) seems to use the i2c interface, but
> I've not tried to see if it works.
> 
> Looking at the monitor-edid output, it seems like it's using the VBE mode to
> correctly get this information, but I have to do a "setsebool
> mmap_low_allowed 1" previously to make it actually work. Could this be
> somewhat related to the fact that nouveau can't get the information?

Nope, pretty sure selinux is just about what userspace can do.

Unfortunately this is getting well outside of my knowledge area. But I think that VBE is something emulated by the card, and perhaps part of VESA. (int 10h is unlikely to be involved directly though, as the system has by then gone into 32-bit protected mode, and overwritten the IDT. int 10h and all the BIOS service interrupts can really only work in 16-bit real mode.) nouveau tries to use the "real" interfaces to access the data, and probably gets it a little wrong in your case. I do know for sure that my TNT2 was able to work with my 1920x1200 monitor without issue (at least not relating to detection).
Comment 15 Mauro Molinari 2014-01-31 08:20:59 UTC
(In reply to comment #14)
> Try to follow the code and see where things go wrong. Boot with
> nouveau.debug=trace perhaps someone left some interesting nv_debug/nv_trace
> statements somewhere. Also throw in drm.debug=0xe for good measure -- a lot
> of the pre-nv50 code still relies on that being set to emit debug statements.

So, tell me if I understood it correctly. I must add two boot parameters (nouveau.debug=trace and drm.debug=0xe) by changing my GRUB configuration. Then, I reboot and look at the logs (dmesg, I suppose? Or maybe also Xorg.0.log?). Then I give a look to the nouveau source code to see if I find some suspect. Am I right?
Please note, however, that I'm a Java developer and I know nothing about Linux programming. So I don't think I will be able to understand too much from the nouveau source code :-P

> Unfortunately this is getting well outside of my knowledge area. But I think
> that VBE is something emulated by the card, and perhaps part of VESA. (int
> 10h is unlikely to be involved directly though, as the system has by then
> gone into 32-bit protected mode, and overwritten the IDT. int 10h and all
> the BIOS service interrupts can really only work in 16-bit real mode.)
> nouveau tries to use the "real" interfaces to access the data, and probably
> gets it a little wrong in your case. I do know for sure that my TNT2 was
> able to work with my 1920x1200 monitor without issue (at least not relating
> to detection).

So, put in other words: could it be useful to look at the monitor-get-edid source code to try to understand why it is working while nouveau is not?
Comment 16 Mauro Molinari 2014-01-31 09:21:36 UTC
Created attachment 93111 [details]
dmesg output with debug options enabled

Here is the dmesg output after I applied the debug options. Unfortunately I can't see any clue of what is going on, maybe you understand something more. No interesting info in Xorg.0.log, instead.

This dmesg output does not show any info related to either EDID or DDC. The first lines about connectors and modelines are those that print the usual standard modelines (being 1024x768 the higher one).

I had a look to nouveau_connector.c, but, sorry, I can't follow it too much. What I have seen is that I don't see any debug output there, unfortunately, but also that I don't see in my logs some error messages like the one that is produced at this line:

NV_ERROR(drm, "DDC responded, but no EDID for %s\n",
                                 drm_get_connector_name(connector));

which seems to be releted to a problem acquiring the EDID. So, the code flow must follow another path...

Any idea?
Comment 17 Ilia Mirkin 2014-01-31 16:44:45 UTC
These are the relevant bits:

[    3.230395] nouveau  [     DRM] Setting dpms mode 3 on vga encoder (output 0)
[    3.230410] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:10:VGA-1]
[    3.249836] nouveau  [     DRM] Load detected on head A
[    3.249861] nouveau  [     DRM] native mode from largest: 0x0@0

You'll have to throw in a bunch of extra prints to figure out what's going on, I'm afraid.
Comment 18 Mauro Molinari 2014-01-31 16:53:30 UTC
(In reply to comment #17)
> These are the relevant bits:
> 
> [    3.230395] nouveau  [     DRM] Setting dpms mode 3 on vga encoder
> (output 0)
> [    3.230410] [drm:drm_helper_probe_single_connector_modes],
> [CONNECTOR:10:VGA-1]
> [    3.249836] nouveau  [     DRM] Load detected on head A
> [    3.249861] nouveau  [     DRM] native mode from largest: 0x0@0
> 
> You'll have to throw in a bunch of extra prints to figure out what's going
> on, I'm afraid.

Ok. Could you please provide a patch with the relevant prints you think are needed, so that I can then apply it, recompile the kernel and test?
Comment 19 Martin Peres 2019-12-04 08:42:39 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/89.

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.