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