Blank screen after boot on Radeon Mobility 4670 HD

[kvark]

I'm running Haiku A3 on MSI EX625 laptop, which has Radeon Mobility 4670 HD on board. The PCIID for this card was added to radeon_hd driver listing very recently. I've built radeon_hd driver and the accelerator as of "hrev43937", and put them in places of the original files:
/system/add-ons/kernel/drivers/bin/radeon_hd
/system/add-ons/accelerants/radeon_hd.accelerant

With new radeon_hd I'm getting a bright garbage-looking screen on boot (screenshot to be attached). I can boot fine with fail-safe video mode (which forces VESA and disables radeon_hd).

It might be relevant that "connector_read_mode_lvds" sees my native resolution as 1400x900, where the actual screen resolution is 1366x768. However, I get the same white garbage if I try to boot with a forced 1024x768 resolution (via the boot option), which works fine with VESA driver.

[kvark]

Device list

[kvark]

Driver image list

[kvark]

System log

[anevilyak]

Just for future reference, the list of resolutions in the boot loader only applies to fail-safe (aka VESA) video mode, it has no impact when an actual graphics driver is handling the display.

[kvark]

Thank you anevilyak. It would be very useful if I could really force the resolution from the boot menu, regardless of the driver used. Also, the syslog attached is from the VESA-booted system. I'm not able to get the syslog from radeon_hd driven system. Please let me know If there is any way to get it saved.

[kvark]

My mistake: the native resolution detected by "connector_read_mode_lvds" is 1400x1050. Also, I'm playing with radeon_hd accelerant code, and all the modes above the "native" one (which is not actually native) are marked BAD in the mode list, which is not the case for the original radeon_hd code. Sorry for the confusion.

[kvark]

Desktop right after the boot

[anevilyak]

Replying to kvark:

Thank you anevilyak. It would be very useful if I could really force the resolution from the boot menu, regardless of the driver used.

The reason it doesn't work that way is because it can't really. In the case of VESA the BIOS gives you a list of resolutions to choose based on an index value you pass in, and takes care of all the rest from there since it's all standardized. When using the actual driver, you no longer have the benefit of that, and consequently the driver has to actually compute the modelines, which entails computing constraints based on the monitor, etc., and consequently a lot more information potentially has to be supplied.

[kvark]

Desktop a minute after the boot

[kvark]

Replying to anevilyak:

The reason it doesn't work that way is because it can't really. In the case of VESA the BIOS gives you a list of resolutions to choose based on an index value you pass in, and takes care of all the rest from there since it's all standardized. When using the actual driver, you no longer have the benefit of that, and consequently the driver has to actually compute the modelines, which entails computing constraints based on the monitor, etc., and consequently a lot more information potentially has to be supplied.

No, of course, we do not want to compute the modelines. The driver generates a list of modes that are valid. All it needs to do is to find a mode in the list that matches the requested mode, if there is any.

[kallisti5]

building the accelerant and driver and dropping into the folder may not be a good test... a lot has changed in the image since A3. Could you test the latest nightly from an iso or dd'ed onto a usb drive?

radeon_hd: connector_read_mode_lvds: 108000 1400 1444 1556 1684 1050 1051 1054 1066

That shows AtomBIOS is actually reporting a lvds mode of 1400x1050 for this card. Is 1400x1050 the correct native resolution? We pass that value back to Haiku as the preferred mode if a preferred mode is found.

[kallisti5]

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/display.cpp#n270 shows the code path to pull lvds info.

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/mode.cpp#n87 is what passes it back to Haiku.

[kvark]

Replying to kallisti5:

building the accelerant and driver and dropping into the folder may not be a good test... a lot has changed in the image since A3. Could you test the latest nightly from an iso or dd'ed onto a usb drive?

Sure, I will do that and post in a moment.

That shows AtomBIOS is actually reporting a lvds mode of 1400x1050 for this card. Is 1400x1050 the correct native resolution? We pass that value back to Haiku as the preferred mode if a preferred mode is found.

As was mentioned before (here and on your blog), my native screen resolution is 1366x768. That is what WinXP, Win8, and Linux used to detect, at least. I have no idea why Haiku's LVDS queries give a different result.

[kallisti5]

AAh... this looks like a stupid bug on my part...

​http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/connector.cpp#n170 ​http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/connector.cpp#n223

That memory allocated on 170 isn't guaranteed to exist after the function exits... consider it me not knowing any better.

I'm working on a fix and will push it shortly.

[kallisti5]

Try again post hrev43982 :)

[kvark]

Replying to kallisti5:

That memory allocated on 170 isn't guaranteed to exist after the function exits... consider it me not knowing any better. I'm working on a fix and will push it shortly.

Could you explain the fix for me? "timing" is a structure that was allocated on the stack:

display_timing timing;

Upon assignment to "mode->timing" the default copy operator will be called, and the memory will be copied. There is no memory leak here:

mode->timing = timing;

Hence, despite the fact there is a logic in your fix (why create a variable on the stack if you can fill the destination via a pointer), it does not change the functionality.

[kvark]

Tried booting hrev43980 from CD - got the same blank screen.

[kvark]

Radeon AtomBIOS dump

[kallisti5]

should be fixed in hrev44056 :D

Please test.

[kvark]

Just booted ISO rev 44058. Haiku still shows garbage screen after loading, maybe a little different garbage, but very similar to screenshots I provided...

[kallisti5]

Bah. Let me re-check the circumstances we pull the LVDS preferred mode... this just doesn't make sense. (That or this card has a known quirk)

[kvark]

It would be great if you could take a look at the AtomBIOS dump I provided... Also, I assume there are logs from other OSes (like Linux, FreeBSD) that could be useful to investigate the case. If you have anything I can gather in mind, let me know.

[kvark]

I've noticed 2 important messages in the syslog:

1) VESA knows about the native panel mode (1366x768), which is a single mode reported under additional modes section. I have a feeling that these additional (or "detailed") modes should be marked somehow on our end, because they are always relevant (in contrast to ones in the standard mode list).

2) radeon_hd does not even attempt to set the incorrectly detected mode (1400x1050). Instead, it tries to switch to 1024x768. As far as I got, it's the app_server that calls the accelerant to switch to this mode. I have no idea why that happens, and will look into that; however, it's all new to me, so the digging process is very slow :(

Any help and thoughts on the matter are very welcome!

[kallisti5]

You may want to test again on hrev45325 or later.

A lot of stuff has changed recently and this issue may be resolved.

Thanks!

[kvark]

I tested the hrev45325 anyboot image on USB, and the issue is clearly still unfixed.

[kvark]

Tested on hrev45805 anyboot USB - not fixed still.

[kvark]

Dmesg log of linux with 3.9 kernel

[kvark]

Please check the dmesg log from Linux-3.9 (attached). Some "drm" output may be useful, i.e. LVDS encoder id=21 (INTERNAL_UNIPHY2).

[kallisti5]

Could you also grab a new set of logs from the Haiku machine?

Boot with radeon_hd, wait 30 seconds, then hold ctl+alt+delete for 5 seconds to reboot.

After you reboot, press space repeatedly before the haiku boot screen shows up and select "Failsafe video (vesa)"

finish booting, and grab /var/log/syslog.

Thanks!

-- Alex

[kvark]

Syslog from revision 45805

[kallisti5]

Thanks :)

These are mostly notes to myself..

based on ​radeon_atombios_get_lvds_info

• check usage of lcd_misc
• look into lcd patch table records (that we ignore for the moment)
  • LCD_FAKE_EDID_PATCH_RECORD_TYPE looks suspect

[kallisti5]

Seems like there is some kind of hidden EDID patch (cough hack) in the atombios tables we need to apply over what atombios *just* told us the lvds mode was. Likely not used often as not many people see this issue.

[kallisti5]

Ha.. this confirms i'm not crazy. If we disassemble (​http://cgit.freedesktop.org/~mhopf/AtomDis/) the atombios you provided...

kallisti5@houvonglucka01 AtomDis :( $ ./atomdis ~/radeon_hd_bios_1002_9488_0.bin d 0006
Read 20000 bytes of data from /home/kallisti5/radeon_hd_bios_1002_9488_0.bin

data_table  0000acf0  #06  (LVDS_Info):

  Size         0036
  Format Rev.  01
  Param Rev.   00
  Content Rev. 02

  00000000:            302a 7805  1c01 1a04  1000 2c00        0*x.......,.
  00000010: 7000 0100  0300 0000  0000 0000  0600 0000    p...............
  00000020: 0000 2000  f401 0324  4d3c 0101  0000 0000    .. ....$M<......
  00000030: 0030 0000  0000                               .0....          

  0000:  ATOM_COMMON_TABLE_HEADER sHeader                    :
    0000:  USHORT usStructureSize                              = 0x0036     (54)
    0002:  UCHAR ucTableFormatRevision                         = 0x01       (1)
    0003:  UCHAR ucTableContentRevision                        = 0x02       (2)
  0004:  ATOM_DTD_FORMAT sLCDTiming                          :
    0004:  USHORT usPixClk                                     = 0x2a30     (10800)
    0006:  USHORT usHActive                                    = 0x0578     (1400)
    0008:  USHORT usHBlanking_Time                             = 0x011c     (284)
    000a:  USHORT usVActive                                    = 0x041a     (1050)
    000c:  USHORT usVBlanking_Time                             = 0x0010     (16)
    000e:  USHORT usHSyncOffset                                = 0x002c     (44)
    0010:  USHORT usHSyncWidth                                 = 0x0070     (112)
    0012:  USHORT usVSyncOffset                                = 0x0001     (1)
    0014:  USHORT usVSyncWidth                                 = 0x0003     (3)
    0016:  USHORT usImageHSize                                 = 0x0000     (0)
    0018:  USHORT usImageVSize                                 = 0x0000     (0)
    001a:  UCHAR ucHBorder                                     = 0x00       (0)
    001b:  UCHAR ucVBorder                                     = 0x00       (0)
    001c:  ATOM_MODE_MISC_INFO_ACCESS susModeMiscInfo          :
      001c:  (union) ATOM_MODE_MISC_INFO sbfAccess               :
               USHORT HorizontalCutOff:1                           = 0x0000     (0)
               USHORT HSyncPolarity:1                              = 0x0001     (1)
               USHORT VSyncPolarity:1                              = 0x0001     (1)
               USHORT VerticalCutOff:1                             = 0x0000     (0)
               USHORT H_ReplicationBy2:1                           = 0x0000     (0)
               USHORT V_ReplicationBy2:1                           = 0x0000     (0)
               USHORT CompositeSync:1                              = 0x0000     (0)
               USHORT Interlace:1                                  = 0x0000     (0)
               USHORT DoubleClock:1                                = 0x0000     (0)
               USHORT RGB888:1                                     = 0x0000     (0)
               USHORT Reserved:6                                   = 0x0000     (0)
      001c:  (union) USHORT usAccess                             = 0x0006     (6)
    001e:  UCHAR ucInternalModeNumber                          = 0x00       (0)
    001f:  UCHAR ucRefreshRate                                 = 0x00       (0)
  0020:  USHORT usExtInfoTableOffset                         = 0x0000     (0)
  0022:  USHORT usSupportedRefreshRate                       = 0x0020     (32)
  0024:  USHORT usOffDelayInMs                               = 0x01f4     (500)
  0026:  UCHAR ucPowerSequenceDigOntoDEin10Ms                = 0x03       (3)
  0027:  UCHAR ucPowerSequenceDEtoBLOnin10Ms                 = 0x24       (36)
  0028:  UCHAR ucLVDS_Misc                                   = 0x4d       (77)
  0029:  UCHAR ucPanelDefaultRefreshRate                     = 0x3c       (60)
  002a:  UCHAR ucPanelIdentification                         = 0x01       (1)
  002b:  UCHAR ucSS_Id                                       = 0x01       (1)
  002c:  USHORT usLCDVenderID                                = 0x0000     (0)
  002e:  USHORT usLCDProductID                               = 0x0000     (0)
  0030:  UCHAR ucLCDPanel_SpecialHandlingCap                 = 0x00       (0)
  0031:  UCHAR ucPanelInfoSize                               = 0x30       (48)
  0032:  UCHAR ucReserved                                [0] = 0x00       (0)
  0033:  UCHAR ucReserved                                [1] = 0x00       (0)

  Total data structure size:  0034

it definitely tells us:

usHActive = 0x0578 (1400) usVActive = 0x041a (1050)

Your LVDS_Info table is 1.2:

0006: acf0 Len 0036 Rev 01:02 (LVDS_Info) (struct size 0034)

Which means it shouldn't (and doesn't) contain a usModePatchTableOffset.

[kvark]

Thanks for the info. I don't think the patch table needs to be looked into as it is not about usHActive or usVActive. What I think we should focus on is finding out how Linux/BSD gets the native mode.

[kvark]

LCDPANEL_CAP_READ_EDID seems like it would be the answer, though the AtomBIOS dump shows ucLCDPanel_SpecialHandlingCap to be 0 :(

-//Definitions for ucLCDPanel_SpecialHandlingCap:
-
-//Once DAL sees this CAP is set, it will read EDID from LCD on its own instead of using sLCDTiming in ATOM_LVDS_INFO_V12. 
-//Other entries in ATOM_LVDS_INFO_V12 are still valid/useful to DAL 
-#define	LCDPANEL_CAP_READ_EDID                  0x1
-
-//If a design supports DRR (dynamic refresh rate) on internal panels (LVDS or EDP), this cap is set in ucLCDPanel_SpecialHandlingCap together
-//with multiple supported refresh rates@usSupportedRefreshRate. This cap should not be set when only slow refresh rate is supported (static
-//refresh rate switch by SW. This is only valid from ATOM_LVDS_INFO_V12
-#define	LCDPANEL_CAP_DRR_SUPPORTED              0x2
-
-//Use this cap bit for a quick reference whether an embadded panel (LCD1 ) is LVDS or eDP.
-#define	LCDPANEL_CAP_eDP                        0x4

[kvark]

I'm going to work on a patch that adds the following check box to the fail-safe video modes list in the boot menu: "Prefer additional VESA mode, if provided", checked by default.

In case of my setup, that would be exactly 1366x768 that I need:

KERN: Additional Video Mode (1366x768@59Hz):
601	KERN: clock=72.33 MHz
602	KERN: h: (1366, 1414, 1446, 1526)
603	KERN: v: (768, 770, 775, 790)

It is going to be a workaround, which would at least allow me to work on Haiku comfortably, including finding the solution for radeonhd initialization.

[kallisti5]

Replying to kvark:

LCDPANEL_CAP_READ_EDID seems like it would be the answer, though the AtomBIOS dump shows ucLCDPanel_SpecialHandlingCap to be 0 :(

Already looked at this.. the linux drm driver doesn't use that table.

Replying to kvark:

I'm going to work on a patch that adds the following check box to the fail-safe video modes list in the boot menu: "Prefer additional VESA mode, if provided", checked by default.

That seems like a fairly hacky hack. Wouldn't it be better to just boot from failsafe (vesa)?

I'd focus on the drm driver to try and figure out what it is doing different. I've reviewed the code and don't see anything different. Let me ping AMD and see what they think.

[kvark]

I'm going to work on a patch that adds the following check box to the fail-safe video modes list in the boot menu: "Prefer additional VESA mode, if provided", checked by default.

That seems like a fairly hacky hack. Wouldn't it be better to just boot from failsafe (vesa)?

That's what I'm talking about. When booting with VESA as a fallback, people (like me) would still like to use their native resolution, and this resolution is exactly specified in the Additional VESA modes section, as far as I can see.

I'd focus on the drm driver to try and figure out what it is doing different. I've reviewed the code and don't see anything different. Let me ping AMD and see what they think.

That would be great. Thanks for your effort!

[kallisti5]

Well, there ya go. Looks like a bug in your laptop's bios :)

We think DRM looks for an EDID from the LVDS panel before going to the LVDS_Into table. That is likely the difference.

21:08 <kallisti5> Good morning.  Super quick question.  Do you know the case to ignore the AtomBIOS LVDS_Info off the top of your head? 
21:09 <AMD> it should always be correct
21:09 <kallisti5> I have a user with a Radeon HD Mobility 4670. usHActive is 1400 and usVActice is 1050. however the native resolution of the lcd is 1366x768
21:09 <kallisti5> hmm
21:10 <AMD> is it a mac?
21:10 <kallisti5> I did see the LVDS patch table, but it doesn't seem to exist in the later table version (1.2)
21:10 <kallisti5> not that i'm aware of... good question though
21:10 <AMD> or did the user hack their system and install a non-standard panel?
21:10 <kallisti5> nope. "MSI EX625 laptop"
21:11 <kallisti5> well.. vesa has the correct perferred mode
21:11 <kallisti5> KERN: Additional Video Mode (1366x768@59Hz):
21:11 <AMD> if the panel has an EDID you can check that first
21:11 <kallisti5> I thought lvds didn't have edid?
21:11 <AMD> usually does
21:11 <AMD> only on really old laptops
21:12 <AMD> does it not
21:12 <AMD> the sbios usually patches the vbios LCDInfo table with the values from the EDID at boot
21:12 <kallisti5> ah. ok.  that helps :D  We can check for edid, else look for lvds_info
21:12 <AMD> which is how the values get there
21:12 <kallisti5> aah.  It maybe a quirk
21:13 <AMD> could be a funky oem bios
21:13 <kallisti5> 99% of the time it's been fine... just this one machine
21:13 <kallisti5> thanks :)
21:13 <AMD> np  

[kallisti5]

Your LVDS panel does have a GPIO hardware pin:

KERN: radeon_hd: Connector #0)
2138	KERN: radeon_hd:  + connector:          LVDS Panel
2139	KERN: radeon_hd:  + gpio table id:      6
2140	KERN: radeon_hd:  + gpio hw pin:        0x96
2141	KERN: radeon_hd:  + gpio valid:         true
2142	KERN: radeon_hd:  + encoder:            LVDS
2143	KERN: radeon_hd:    - id:               33
2144	KERN: radeon_hd:    - type:             Internal Kaleidoscope UNIPHY2
2145	KERN: radeon_hd:    - enumeration:      1
2146	KERN: radeon_hd:    - is bridge:        false
2147	KERN: radeon_hd:    + external encoder: none
2148	KERN: radeon_hd:  + flags:
2149	KERN: radeon_hd:    * device LCD1 support

Your logs show we are jumping directly to the LVDS_Info table.

KERN: radeon_hd: detect_displays: connector(0): found LVDS preferred mode

So! The logic should be changed. Instead of jumping directly to that table, we should try to bit-bang an EDID from the LVDS gpio pin... if that fails to produce a valid EDID, use the LVDS_Info (if it is an LVDS panel)

I can make the change, it may be a few days though as my free time is short lately.

[kvark]

That's awesome! When you are ready with the fix, please provide binaries as well, because I don't have the dev environment set up at this point. That in case you'd like to test it before submitting... Otherwise, I'll just wait for the nightly build.

[kallisti5]

actually.. the fix was easier than I thought.. do you need gcc2 or gcc4 binaries to test?

[kvark]

Nice! I'm using a nightly image, so "x86 GCC 2 Hybrid" binaries are needed.

[kallisti5]

patched radeon_hd accelerant

[kallisti5]

patched radeon_hd driver

[kallisti5]

gcc2 accelerant and driver attached. The only changes were in the accelerant, but update both to be safe.

[kvark]

Thanks! I'll be able to test it in about 4 hours. I assume I can just overwrite these files under working Haiku and reboot.

[kallisti5]

yeah. Should be able to without any issues. If you have any trouble, grab another syslog as it will show what the result of the ddc bit-banging was.

[kvark]

Syslog with a patched radeon_hd

[kvark]

A patched system booted into a black screen. As if it wasn't powered on at all. Please see syslog-patched attachment for details. It did try the correct resolution (1366x768), so there must be some other bit missing.

[kallisti5]

sigh... your laptop is buggy :P Partial fix applied in hrev45812

As for the black screen... I noticed the modeline calculations were a little odd.

KERN: radeon_hd: radeon_set_display_mode: pll 0 selected for connector 0
3290	KERN: radeon_hd: pll_setup_flags: CRTC: 0, PLL: 0
3291	KERN: radeon_hd: pll_setup_flags: Spread Spectrum is 8%
3292	KERN: radeon_hd: pll_setup_flags: using Spread Spectrum reference divider. refDiv was: 0, now: 98
3293	KERN: radeon_hd: pll_adjust: table 1.2
3294	KERN: radeon_hd: pll_adjust: was: 72330, now: 72330
3295	KERN: radeon_hd: pll_compute_post_divider: vco = 1200000
3296	KERN: radeon_hd: pll_compute_post_divider: postDiv = 16
3297	KERN: radeon_hd: pll_compute: using AtomBIOS reference divider
3298	KERN: radeon_hd: pll_compute: using AtomBIOS fractional feedback divider
3299	KERN: radeon_hd: pll_compute: pixel clock: 72330 gives: feedbackDivider = 2049.0; referenceDivider = 98; postDivider = 16
3300	KERN: radeon_hd: pll_compute: pixel clock 72330 was changed to 35282
3301	KERN: radeon_hd: display_crtc_ss
3302	KERN: radeon_hd: pll_set: table 1.3
3303	KERN: radeon_hd: pll_set: set adjusted pixel clock 35282 (was 72330)
3304	KERN: radeon_hd: display_crtc_set_dtd called to do 1366x768
3305	KERN: radeon_hd: display_crtc_fb_set: Framebuffer at: 0x0
3306	KERN: radeon_hd: display_crtc_fb_set: Set SurfaceAddress High: 0x0
3307	KERN: radeon_hd: display_crtc_fb_set: Set SurfaceAddress: 0x0
3308	KERN: radeon_hd: display_crtc_fb_set: fb: 1366x768 (32 bpp)
3309	KERN: radeon_hd: display_crtc_fb_set: fb pitch: 1376
3310	KERN: radeon_hd: display_crtc_fb_set: fb width aligned: 1376

This is the first time i've ever seen Spread Spectrum used. The feedbackDivider is changed into something really incorrect.

[kallisti5]

*sigh* lvdsSpreadSpectrumID is populated by connector_read_mode_lvds. As we never call it... it never gets populated so we match incorrect SS data.

[kallisti5]

patched radeon_hd accelerant version 2

[kallisti5]

patch

[kvark]

Syslog with patched-2 accelerant

[kvark]

With the second accelerant and an original kernel driver I'm getting the same picture as without patches at all - screen is corrupted. Please see syslog-patched2 attached. I noticed that the pitch is 1376, which doesn't match the width, though I'm not sure if that's the problem.

[kvark]

Confirmed it's still broken on latest. Also, investigated my options on using VESA. Despite the fact EDID reports proper timings for 1366x768, this mode is not a valid VESA mode :(. Hence, we'll have to push radeon_hd into supporting it properly.

[kvark]

Looking through the last attached syslog I found a lot of differences with the DRM log. Haiku:

KERN: radeon_hd: display_crtc_fb_set: Framebuffer at: 0x0 KERN: radeon_hd: display_crtc_fb_set: Set SurfaceAddress High: 0x0 KERN: radeon_hd: display_crtc_fb_set: fb pitch: 1376

Linux:

[drm] fb mappable at 0xD0142000 [drm] vram apper at 0xD0000000 [drm] size 4325376 [drm] pitch is 5632

Clearly, the framebuffer address is invalid (0x0), and the pitch is totally wrong. Firstly, because it doesn't take into account 4 bytes per pixel. Secondly, because of a smaller alignment (DRM's 5632 = 4 * 1408).

kallisti5, could you comment on that?

[kallisti5]

The vram start (vram appear per drm above) is actually provided by the card if it is flagged as IGP. fbAddress is set by gInfo->fb.vramStart which is set by radeon_gpu_mc_init.

The logic for that likely needs reviewed as most of the logs at hand have the fb_base at 0xD0000000 - 0xE0000000

[kallisti5]

Try the patch attached. I just can't find the logic why I was checking for IGP before reading that register. Please give it a try and let me know.

This change has the potential to break cards, so if it works for you I need to do some testing.

[kallisti5]

patch to fix vram base? revision 1

[kvark]

Thanks kallisti5, I'll test it in a couple of hours. I'm still convinced the pitch is not passed correctly though: Write32(CRT, regs->grphPitch, widthAligned);

Shouldn't it look like that instead?: Write32(CRT, regs->grphPitch, widthAligned * bytesPerPixel);

Also, the pitchMask computation should be changed to match this one: ​http://kerneldox.net/kdox-linux/d2/db3/radeon__fb_8c.html (look for radeon_align_pitch()) With this code it would produce widthAligned==1408, exactly like on DRM.

[kvark]

The patch doesn't seem to affect anything, the framebuffer is still reported as 0x0.

[kallisti5]

ok. I wouldn't use the patch then :D

I just remembered the reason for that check. Linux is reporting the framebuffer address from the point of view of the host. Haiku's framebuffer address is the location from the perspective of the GPU

[kvark]

Ok I see... What about the pitch then?

[kallisti5]

try this one.

[kvark]

No luck with this one either...

[kvark]

Syslog taken with a patch that uses EDID of the first monitor

[kvark]

I also tried fixing the alignment and the pitch (to match DRM ones), but that didn't help.

[kvark]

Checked on hrev46653, the system boots straight into VESA 1024x768, and I see no mentions of 'radeon' in the syslog. Is this expected?

[zelenoviy]

Same issues on Asus K52Jr (Mobility Radeon HD 5470,1366x768), hrev57330