Created attachment 92961 [details]
Output of "xrandr -q"

Created attachment 92962 [details]
Output of "xrandr --verbose"

Created attachment 92963 [details]
Output of "monitor-get-edid -v | monitor-parse-edid -v"

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.

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).

Created attachment 92970 [details]
Output of "grep . /sys/class/drm/card*-*/*"

/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.

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

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?

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.

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...)

(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.)

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?

(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).

(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?

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?

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.

(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?

-- 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.