Nouveau - Jan 2014 - [Bug 74164] New: [NV04] Native monitor resolution missing

https://bugs.freedesktop.org/show_bug.cgi?id=74164

          Priority: medium
            Bug ID: 74164
          Assignee: nouveau at lists.freedesktop.org
           Summary: [NV04] Native monitor resolution missing
        QA Contact: xorg-team at lists.x.org
          Severity: major
    Classification: Unclassified
                OS: Linux (All)
          Reporter: mauromol at tiscali.it
          Hardware: x86 (IA32)
            Status: NEW
           Version: unspecified
         Component: Driver/nouveau
           Product: xorg

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 at 60" 108 1280 1328 1440 1688 1024 1025
1028 1066
+hsync +vsync
xrandr --addmode VGA-1 1280x1024 at 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140128/5b566605/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #1 from Mauro Molinari <mauromol at tiscali.it> ---
Created attachment 92961
  --> https://bugs.freedesktop.org/attachment.cgi?id=92961&action=edit
Output of "xrandr -q"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140128/11a2b8de/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #2 from Mauro Molinari <mauromol at tiscali.it> ---
Created attachment 92962
  --> https://bugs.freedesktop.org/attachment.cgi?id=92962&action=edit
Output of "xrandr --verbose"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140128/46d52fec/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #3 from Mauro Molinari <mauromol at tiscali.it> ---
Created attachment 92963
  --> https://bugs.freedesktop.org/attachment.cgi?id=92963&action=edit
Output of "monitor-get-edid -v | monitor-parse-edid -v"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140128/5730f19a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #4 from Mauro Molinari <mauromol at tiscali.it> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140128/864a0fec/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #5 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140129/d8229dd1/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #6 from Mauro Molinari <mauromol at tiscali.it> ---
Created attachment 92970
  --> https://bugs.freedesktop.org/attachment.cgi?id=92970&action=edit
Output of "grep . /sys/class/drm/card*-*/*"

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140129/3a79126c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #7 from Mauro Molinari <mauromol at tiscali.it> ---
/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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140129/bdf68acc/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #8 from Mauro Molinari <mauromol at tiscali.it> ---
Created attachment 92971
  --> https://bugs.freedesktop.org/attachment.cgi?id=92971&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140129/7e647c7a/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #9 from Mauro Molinari <mauromol at tiscali.it> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140129/dc94863a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140129/ebcf7b60/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #11 from Mauro Molinari <mauromol at tiscali.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...)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140130/1cd8cbb1/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #12 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140130/7ddd55d9/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #13 from Mauro Molinari <mauromol at tiscali.it> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140130/80dc0eec/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #14 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140130/964f2eab/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #15 from Mauro Molinari <mauromol at tiscali.it> ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140131/351869e4/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #16 from Mauro Molinari <mauromol at tiscali.it> ---
Created attachment 93111
  --> https://bugs.freedesktop.org/attachment.cgi?id=93111&action=edit
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140131/68628454/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #17 from Ilia Mirkin <imirkin at alum.mit.edu> ---
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 at 0

You'll have to throw in a bunch of extra prints to figure out what's
going on,
I'm afraid.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140131/9f363c89/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

--- Comment #18 from Mauro Molinari <mauromol at tiscali.it> ---
(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 at 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140131/ecbc4e35/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74164

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #19 from Martin Peres <martin.peres at free.fr> ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/4d785a83/attachment.html>