[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-
os.org/browser/haiku/trunk/src/add-
ons/kernel/drivers/graphics/nvidia/nvidia.settings?rev=40799
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-
os.org/browser/haiku/trunk/src/add-
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
http://dev.haiku-os.org/ticket/6716#comment:8
.. 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:
