[haiku-commits] Re: r41411 - in haiku/trunk: build/jam headers/private/graphics/radeon_hd src/add-ons/accelerants/radeon_hd src/add-ons/kernel/drivers/graphics/radeon_hd
- From: kallisti5 <kallisti5@xxxxxxxxxxx>
- To: <haiku-commits@xxxxxxxxxxxxx>
- Date: Tue, 10 May 2011 12:26:19 -0500
On Tue, 10 May 2011 17:15:51 +0200 (MEST), Axel Dörfler wrote:
Stephan Aßmus<superstippi@xxxxxx> wrote:
I have no clue what brought Alex to his conclusion, but if he is
right,
it would be a driver issue after all. One which would be worth
fixing
since it allows picking the correct native resolution with the VESA
driver on graphics cards which exhibit this behaviour.
And since you can obviously reproduce it, I would at least welcome an
investigation of the matter -- no matter what Alex originally
intended
to say ;-))
Jeesh, you guys should know better then to look too closely at what I
type at 1am :)
The VESA driver gets the EDID supplied timings via the boot loader and
stores it in the sharedInfo space. The accelerant passes it to Axel's
create_display_modes which creates a mode list for the display based on
what the monitor provides. Every mode create_display_modes finds is
validated via a callback to the accelerant (in this case,
is_mode_supported)
http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/accelerants/vesa/mode.cpp#L48
The vesa drivers is_mode_supported verifies the modeline is one of the
standard vesa modes as setting a non-vesa mode in the generic vesa way
may
or may not work (only modes following the vesa standard are guaranteed
to
work this way)
In the radeon HD driver, I just return true for the moment on the
is_mode_supported callback. As we are using radeon hd specific register
calls to set the mode, we are not limited to the restraints of the
vesa guidelines.
In short, this is the proper way until AtomBIOS support is complete...
Hopefully I used the right wording this time.
Thanks!
-- Alex
Other related posts:
