[haiku-bugs] Re: [Haiku] #7655: Resolution 640x480 the only one available -- driver using own EDID interp. instead of (more complete) common code's EDID interpretation (was: Resolution 640x480 the only one available)

From: "ttcoder" <trac@xxxxxxxxxxxx>
Date: Fri, 01 Jul 2011 13:12:38 -0000

#7655: Resolution 640x480 the only one available -- driver using own EDID 
interp.
instead of (more complete) common code's EDID interpretation
---------------------------------------+----------------------------
   Reporter:  ttcoder                  |      Owner:  rudolfc
       Type:  bug                      |     Status:  new
   Priority:  normal                   |  Milestone:  R1
  Component:  Drivers/Graphics/nVidia  |    Version:  R1/Development
 Resolution:                           |   Keywords:
 Blocked By:                           |   Blocking:
Has a Patch:  1                        |   Platform:  All
---------------------------------------+----------------------------

Comment (by ttcoder):

 Replying to [comment:8 axeld]:
 > I am not sure if the nvidia driver is using create_display_mode() at
 all. Older drivers tend to implement this bit on their own with their own
 mode list. That would be the first thing to test.


 Indeed:

 {{{
 ~/develop_haikusrc/accelerants/nvidia> grep create_display_modes *
 acc_std.h://#include <create_display_modes.h>
 Binary file libaccelerantscommon.a matches
 ~/develop_haikusrc/accelerants/nvidia> grep create_display_modes */*
 engine/nv_std.h://#include <create_display_modes.h>
 }}}

 In fact InitAccelerant.c's INIT_ACCELERANT() calls ProposeDisplayMode.c's
 custom function create_mode_list(), which itself calls
 PROPOSE_DISPLAY_MODE() with its own local list of hardcoded modes..

 And that latter function makes its decisions based on the restricted
 (incomplete) EDID "native specs" previously calculated by
 engine/nv_i2c.c's   i2c_ExtractSpecsEDID() (that's the one which
 interprets only section 3 of EDID and ignores section 1 and section 2).

 So IIUC instead it should be like this:

 INIT_ACCELERANT() should call common/'s create_display_modes() : That one
 includes its own routine to interpret EDID Specs from ''all 3'' EDID raw
 sections, and thus fill out correctly the
 ''si->ps.crtc1_screen.timing.h/v_display'' fields whatever section their
 value comes from, and thus the enforcing of these fields would not need to
 be commented out any more (as I proposed they be in my, quote, unquote,
 "patch" :-).


 What's more, ProposeDisplayMode.c indeed has its ''own'' copy of modes:
 {{{
 /* Standard VESA modes,
  * plus panel specific resolution modes which are internally modified
 during run-time depending on the requirements of the actual
  * panel connected. The modes as listed here, should timing-wise be as
 compatible with analog (CRT) monitors as can be... */
 //fixme: if EDID monitor found create list via common EDID code...
 static const display_mode mode_list[] = {
 ...
 }}}
 and this one does have the 2048x1536 I see in Screen prefs indeed.


 So, I'm glad I picked your brain to find out exactly where the problem is
 :-)

 That driver needs to indeed call create_display_modes() (from common/) to
 make sure EDID data is interpreted correctly in all cases.

 I don't have enough time to work on such a significant change myself, but
 at least if others pick up this ticket later they'll know where to start
 from.

 P.S. I cannot uncheck the "has Patch" box, it's grayed out, need someone
 with edit privileges to do it.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/7655#comment:9>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

[haiku-bugs] Re: [Haiku] #7655: Resolution 640x480 the only one available -- driver using own EDID interp. instead of (more complete) common code's EDID interpretation (was: Resolution 640x480 the only one available)

Other related posts: