[haiku-bugs] Re: [Haiku] #7655: Resolution 640x480 the only one available

  • From: "ttcoder" <trac@xxxxxxxxxxxx>
  • Date: Thu, 30 Jun 2011 16:56:28 -0000

#7655: Resolution 640x480 the only one available
   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:  0                        |   Platform:  All

Comment (by ttcoder):

 Boy, graphics drivers are complex things, took some navigating the code to
 finally understand who called who, who has the EDID info retrieved and
 stored in ::si and then passed to ProposeMode ..etc, then hacked that part
 to accept my monitor's resolution, which makes it much more comfortable to
 be in Haiku now :-)

 Turns out my monitor's EDID does not list its native resolutions in ''case
 EDID1_IS_DETAILED_TIMING'' (the third section) but only in the first 2
 sections.. (especially section 2, "Supported VESA Video Modes")... I have
 recompiled the driver with extra logging, and found out... (could have
 guessed by reading the log in the first place, but then I didn't know what
 EDID is, reading the driver taught me that :-)

 Windows seems to be fine with it -- it proposes 1024x768 so I guess it
 probably uses the info in "Supported VESA Video Modes" section.

 I can imagine 4 ways to resolve and close this ticket now:

 - close a Invalid/Will-not-fix (and I continue using my hacked driver)
 - implement a new setting in [http://dev.haiku-
 nvidia.settings] that allows to disable EDID completely, allowing to pick
 any resolution at all in Screen preflet; close as fixed
 - implement a new setting in nvidia.settings that allows to override the
 virtual_w/virtual_h used in ProposeMode.cpp; close as fixed
 - try to be nimble and exploit the other two EDID sections (which are
 currently unused by Haiku apparently), like MS Winders presumably does..
 :-). There is more potential for regression if I don't "get it right" with
 my patch, but it could be worth the extra effort.. Depends if other people
 are affected by this EDID "scarcity of info" problem or if it's just this
 one Hyundai CRT dinosaur..

 Anyway that's where I'm standing now, I'll stop updating this ticket and
 stop digging.. Though I did not succeed in finding ''all'' the information
 I wanted: I meant to explore the vesa/accelerant code and find out why
 that one goes to 800x600 (not lower, nor higher, even, that's odd!) but
 got blocked in there: couldn't find how it retrieves the EDID info if any;
 most close thing I found to EDID in vesa was [http://dev.haiku-
 ons/kernel/drivers/graphics/vesa/vesa.cpp?rev=40799#L356 this one] , which
 is a dead-end for me (Trac does not allow to search the source for a
 symbol name it seems).

 Anyhow this is probably a ''priority=Low'' ticket, if anyone cares to
 change that property of it.

 '''UPDATE''':  turns out that I'm not alone with this symptom, and my
 conclusions were already reached in

 .. where Rudolf says there are several different patches that could be
 done to solve this (and other similar) tickets..

 Shout-out -- any chance the patch could be applied, if I write one ? For
 instance the "do like winders does" concept?

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

Other related posts: