https://bugs.freedesktop.org/show_bug.cgi?id=74164
--- Comment #14 from Ilia Mirkin <[email protected]> --- (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.
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
