Intel Extreme does not support DisplayPort output

[tqh]

Only getting black screen on my laptop. Backlight is on. Providing syslog and can test patches..

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device [1043:1507]
	Flags: bus master, fast devsel, latency 0, IRQ 29
	Memory at f7400000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915

[tqh]

Syslog (ignore some other wip driver stuff)

[tqh]

Needs implementation for

DisplayPort::SetDisplayMode(display_mode* target, uint32 colorMode)

in src/add-ons/accelerants/intel_extreme/Ports.cpp

[pulkomandy]

From the log, it seems to fail even earlier, as all attempts to get the EDID info failed.

Your laptop appears to use DisplayPort internally to connect the display, and the modesetting attempt ends in a "TODO DisplayPort" entry. I guess someone didn't finish implementing this.

[tqh]

Yes, that is the function I'm referencing and that needs an implementation. The log entries you talk about come from it's TODO and the returned B_ERROR.

[kallisti5]

Laptop displays attached internally via DP is getting a lot more common. Radeon HD has better DP code done, but it doesn't work either. DP training is pretty tricky since DP devices can be daisy chained. Radeon HD is a bit easier to work with as I keep an inventory of ports + connected displays. Post-rewrite it should be possible to manage Intel DP devices like this as ports are better abstracted... but lack of time on my part means it'll likely be a while unless someone wants to take the lead on it.

[kallisti5]

The DisplayPort specifications are not public, however I have access to them via my Xorg membership. If you're interested in working on DP support within our accelerant common code / Intel / Radeon HD / let me know and I can let you "borrow" them with a big red "do-not-redistribute" attached.

[kallisti5]

My Asus Zenbook has the same chipset. Also a black screen as of hrev52730

[tqh]

No change in hrev53543.

What I forgot to mention in the ticket is that the Intel driver actually did have a working display long ago, probably it didn't reset whatever the fw setup.

[pulkomandy]

In that case, could you try with ​https://review.haiku-os.org/c/haiku/+/1899 ?

[tqh]

I don't have any build machine. So I need it in a nightly or similar.

[tqh]

No change in hrev53605.

[vercu]

I did report #13478. Now I tested the V4 driver on X64 from rudolfc.

Notebook: Lenovo X1 1st Gen, Ivy Bridge , with Intel HD Graphics 4000 external monitor: Lenovo Q27q, native res is 2.560 x 1.440

mini dp port cable to dp port at the external monitor --> no picture mini dp port cable to hdmi adapter and then to hdmi port at the monitor gave the picture attached above. Syslog will follow.

[vidrep]

I took the liberty of re-assigning to rudolfc since this issue is what he is currently investigating.

[rudolfc]

Thank you. So did you try booting with the external monitor connected with the adapter that gave this picture? if not, could you try that and upload a syslog from that attempt? (if you must reboot blindly. try the power button for a normal shutdown, or pres 'alt'+'ctl'+'del' shortly after boot completes: then hit that once more for say 10 seconds. The system will reboot then as well if all is right. If you now reboot in a way you get a picture you can upload the 'previous syslog': that should contain the info from the boot attempt with the external monitor.

It would be cool if you could also do a boot without the adapter (so dp port directy) and upload a syslog from that as well. I'm curious if/what the differences will be.

One more question: is the adapter a passive or a active adapter, would you know that?

Thanks!

[vercu]

I have a 2nd Haiku 32 install on that notebook. Deleted the syslogs on the 64 bit install. Then booting with the hdmi adapter. Got the same distorted picture as before. Then using the dp port cable directly there is no picture. The adapter is a passive Lenovo Mini-DisplayPort to HDMI Adapter PS8402A 0B58409 03X6594.

[rudolfc]

Hi, So indeed with the adapter your screen is driven in HDMI mode. With the mini DP-to-DP cable however, it's displayport mode and therefore the driver does not see the monitor and also cannot program it. Since yesterday this is a known limitation to me which I hope to adress soon, but it will take some time and effort. I'll get back to you on this. Thanks!

[rudolfc]

Another comment: So with the HDMI adapter I see that both FDI links (A and B) seem correctly and individually programmed/accessed. You can see that the internal panel uses a single lane, where the HDMI connection uses 2 (1920x1080 should be possible there that way).

But I am missing panelfitter messages in the syslog, so are you sure you installed the V4 driver correctly? You are running on the current git version from the looks of it?

If you have the V4 correctly installed, and you set a mode that should be compatible for both screens, you might have a correct desktop on the external screen.

Note however that dualscreen output is not yet supported (did not explicitly look into that yet) so on a laptop it's a bit unsure how this all works out for now.

If you do more tests, post info here I'd say. Can you BTW in the bootmenu (so before the icons screen) set your external screen's native resolution? or does this menu not offer that? Anything above 1920x1080?

If so, I'd love a syslog from that to see what it does for the lanes (HDMI adapter). But, don't use it too long, since it's not supported by your internal panel. You should in the end set a mode that's compatible for both screens at the same time (so lower or at native internal screen resolution).

[vercu]

Set other res in the screen prefs: 1920x1080x32 and 1280x1024x32 did not work. But 1280x720x32 gave an undistorted screen, see picture attached. It did not fit the screen though. Could not switch back to the notebook native 1600 x 900 x 32 afterwards. Had to delete the V4 driver. I think the V4 driver is installed correctly before. It is not possible to change the res in the bios.

[rudolfc]

Hi, could you test with hrev55159 or later with the HDMI adapter to see if the situation changed for you? Panelfitter programming and a modified setup for internal panels sits in git now.. No need for a seperate testdriver this time.

[vercu]

OK, updated to hrev55164 x86_64. With hdmi adapter: 1600x900 looks very good on the external screen. 1920x1080 and 1680x1050 do not work. No luck with the DisplayPort cable. I call it a success already. From no picture to a useable screen on the external monitor. Thank you very much.

[rudolfc]

Hi again, nice! Could you also test hrev55168 for me, with both the HDMI adapter -and- the DP connection? If all is right you should now have a picture also via the DP connection I hope..

Please post a syslog again and tell me what is changed in the driver behaviour..

Thanks!

[vercu]

Did test hrev55168 x86_64. Native 1600x900 for the notebook. Unfortunatelly no picture on the external monitor. No matter with hdmi adapter or with DP cable. That did work before at least with the hdmi adapter. Note: with this notebook and monitor connected via DP cable Windows booted directly to the native res of the monitor 2.560 x 1.440.

[rudolfc]

OK. Thank you. Do you also have a log for the HDMI adapter try? Please upload it as well (syslog). Thanks.. :-)

[rudolfc]

Hi it might be that on current nightly (or beta3) the behaviour has changed. could you doublecheck it to see how it behaves now compared to last test you did?

On a 'sidenote' I am seeing some progress here on 'wild' tests with displayport on my IvyBridge, I was able to set all modes there via the scaler keeping the panel in native mode: looking very nice. I don't know if and how to make this autodectecting the current setup yet so it's of no use to you yet..

For two heads via HDMI might come soon though, that's looking good on Ivy. Don't know if it works the same way for laptops, so that will just have to be tried when it's ready. Hopefully I can upload that patch within a week or so.

[vercu]

Updated to hrev55186 x86_64. External screen connected via DisplayPort cable. No picture. The behavior did not change.

[rudolfc]

Hi, please try hrev55189 or later.. Pipe assignment has changed, I'm very curious how it holds up. Please also try the external monitor again, preferably connected in various ways. Thank you!

[vercu]

No new hrev via Softwareupdater, sorry. I am also very interested to test.

[rudolfc]

Yes, i saw no updates either unfortunately. I will post the compiled driver as a workaround in a bit. I'm curious for the results as wel :-)

[rudolfc]

OK, you can grab it here: ​http://rudolfs-place.nl/Haiku/Downloads/Intel_extreme_drv_v5_hrev55189.zip

Instructions for installation are here (scroll down to Haiku part) ​http://rudolfs-place.nl/BeOS/NVdriver/setinst.html#installation

Thanks!

[vercu]

Copied your driver to the non-packaged folder as noted in your guide. External screen connected via DisplayPort cable. No picture. The same with the hdmi adapter.

[rudolfc]

Hello again, thank you. Looking at the last syslog (hdmi adapter) I see that initially your HDMI display is detected: KERN: intel_extreme: CALLED status_t Port::SetPipe(Pipe*) KERN: intel_extreme: SetPipe: Assigning HDMI B (0x5001140) to pipe A

But during setmode it is nolonger 'connected'.

Assuming you had the connectors firmly in place I have to update the driver once again, as the hardware logic must be working even more complex than I already thought. Although it's a HDMI connection the DPMS shuts off the 'link-bit' which I did not expect.

I have to add some link detection buffering in the driver instead of always polling this bit..

After I have this added, I'll ask you for a retest.

For now can you confirm the cables were firmly in place, just to be absolutely sure about this for me?

Thanks!

[vercu]

Isn't it a good indication that there is no problem with the connection when I see POST, bootmanager and Haiku boot icons on the external screen. That was always the case.

[rudolfc]

Ah OK, Yes I agree :-)

[rudolfc]

Hi again,

Could you please test: ​http://rudolfs-place.nl/Haiku/Downloads/Intel_extreme_drv_v6_hrev55200.zip

I disabled DPMS powering off ports for most digital screens (Excluding Sandy Bridge laptop panels) until is's resetup (it's not functioning correctly atm)

I'm very curious if you -now- get a screen on the external monitor together with the internal panel. Try both the HDMI and DP connection and upload syslogs again..

Thank you!

[vercu]

Still no joy with the V6 driver. Tried different resolutions without success. I see the boot icons on the external monitor and afterwards a black screen.

[rudolfc]

Thank you. The with hdmi adapter log shows all connections: with dp, single, and with hdmi. The HDMI connection is still lost as it was before, which leads me to think you did not correctly install the V6 testdriver? Can you please doublecheck that..

Note to self: All in all, I think I'll add a version number string to the driver (after all) so I can see from the log without any doubt which version is running..

[rudolfc]

Oh yes, so please doublecheck again. A test with the HDMI adapter is enough now, I should see different behaviour there..

[vercu]

double checked --> still no signal with the hdmi adapter. Please check the location and the date of the driver in the atached screenshot.

[rudolfc]

Hmm. In that case I have to doublecheck the source (but did that before committing). I can only think of one thing atm: recompile over here (I have a clock issue which might have prevented a new object file from being created before linking..)

[rudolfc]

Hi again, since now nightlies are built again could you please test hrev55202 (or later) to rule out I had compile trouble? Looking at the source it really seems OK atm.. With HDMI adapter is enough. Please upload a syslog from that attempt once more..

[vercu]

hrev55202 installed. Files in non-packaged deleted. Got "no signal" after the Haiku icons on the external monitor.

[rudolfc]

Hi again, Thank you! Could you please also test with the HDMI adapter? (this latest attempt from you was with DP link up from the looks of it, which btw behaved as intended, good to see :-)

[rudolfc]

Thanks again :-) OK, so the driver functions as expected concerning processing the connected screens. The V6 driver did not work correctly on your system somehow.

So, no picture still on the HDMI connected screen? Maybe try a few modes if possible which that monitor is likely to support?

[vercu]

Tried all the resolutions which are available when pressing the space bar during boot. No picture. Only at 800x600 and lower are blue flickering screen. See picture.

[rudolfc]

Interesting.. I wonder what would happen if you boot in failsafe graphics mode with the screen connected this way, set 800x600 with Screenprefs, and reboot, this time without going to the bootmenu. If all is right (at least this is what I see most of the time) the booticons screen will be in 800x600, and the desktop as well. There's probably a small chance this screen would show more in this case.. ;-)

[vercu]

boot in failsafe graphics mode with the screen connected this way, set 800x600 with Screenprefs, --> that works indeed. I see the desktop on the external monitor.

and reboot, this time without going to the bootmenu. --> that did not work :-(

[rudolfc]

Ok, nogo then for that atm. Next up try the next nightly hrev55203 or later, only this time with the external screen using the DP connection, let's see what happens there.. if you don't get a picture I'd like the syslog anyway (dumping a few related register contents ;-)

Thanks for your time and efforts again!!

[vercu]

hrev55203 is installed. Tested all available resolutions via displayport cable. No signal after the boot icons.

[vercu]

Note: in fail safe gaphics mode i got native resolution 2560x1440 on the external screen via displayport cable.. Wow, is new to me.

[rudolfc]

Ah, that's nice to know (native in failsafe). Can you please try the syslog once more? I'm afraid its way too small and misses all required info (sometimes that happens with haiku, I've seen that too occasionally)

Thank you..

[rudolfc]

BTW: Did you by any chance find the 2560x1440 mode in the bootoptions when you booted a 32bit version of Haiku? In that case: retry with a 64bit version. I bet you it's not there this time.. ;-) I think there might be a problem in Haiku somehow since I had expected that the options here should be identical..

Unless maybe this is already 64bit code and we cannot (fully) access the cardBIOS. This BIOS surely always has the same options with the same monitor connected..

[rudolfc]

When available as a nightly, can you please also test hrev55204? who knows.. Displayport (not HDMI) programming is updated especially for dual screens. Would you have a picture now?

[kallisti5]

Just some quick feedback checking for regressions...

Dell Vostro V130 (Intel IronLake):

• haiku-r1beta3-hrev55181_16-x86_64 - Onboard LCD - OK
• hrev55204 - Onboard LCD - OK

[vercu]

hrev55204 is installed. Tested all available resolutions via displayport cable. No signal after the boot icons.

[vercu]

I do find a 2560x1440 mode in the bootoptions when booted a 32bit version of Haiku. It is still there when booting the 64bit version afterwards.

Replying to rudolfc:

BTW: Did you by any chance find the 2560x1440 mode in the bootoptions when you booted a 32bit version of Haiku? In that case: retry with a 64bit version. I bet you it's not there this time.. ;-) I think there might be a problem in Haiku somehow since I had expected that the options here should be identical..

Unless maybe this is already 64bit code and we cannot (fully) access the cardBIOS. This BIOS surely always has the same options with the same monitor connected..

[rudolfc]

Thank you kallisti5: so no regressions found I take it?

Vercu, ah ok thanks. I'll keep an eye out over here to see if I can tune-in a bit more on this aspect on my systems then.

[kallisti5]

Thank you kallisti5: so no regressions found I take it?

Nah. Everything working still :-) I merged your work so far into R1/beta3. No pressure!

[rudolfc]

Nice! Thank you :-)

[rudolfc]

BTW I'll now have a break with the driver for approx. a week ;-) Did add displayport support in dualhead clone (and single) on generation 4/G45 systems, working nicely except that native mode filters still which should be turned of for the sharpest image. I'll try to fix that later. And on SAndybridge currently dualscreens does not work with HDMI and VGA together: display on just one screen. That's a bit of a regression, has to do with pipeswitching. Will check that in a week approx, and update driver again. Since single connected screens, or with dual connected screens the desktop normally appears, I would say this is no problem for now ;-)

[tqh]

Tried hrev55214, and it gives a black screen. There are some shorter white noise lines when going black. Attaching syslog..

[rudolfc]

tqh, what type of panel resolution does this laptop have? app_server sets 1920x1080. is that above native for you? If so, try booting with vesa, set a mode that is supported by the panel, and reboot with the intel driver. the driver cannot yet see what the panel specs are because displayport ddc/edid doesn't work yet for this connection type. another observation: the BIOS seems to use pipe B whereas the driver tries to use pipe A. Maybe I should update the driver to look at that and select the same one (for now)..

[tqh]

It's 1920x1080 display. It also has a second nvidia graphics chip. UEFI sets it up at 1920x1080 so already at boot everything should be setup in working condition. In very old code it booted to desktop that way. I never managed to find exactly when it broke, but it was working with Axel's initial driver.

[tqh]

New syslog, some spam log messages related to AGP/GART that can be ignored as it is working. Interesting part is DP display setup but resulting in black screen.

[rudolfc]

tqh, could you test what happens if you:

• remove the vesa settings file
• remove the app_server settings file
• remove all secondary displays, so only leave the laptop panel connected
• reboot and enter boot menu
• select a mode from the list, I'd say highest one available (Which is that for you? 1920x1080?)
• don't select failsafe graphics, just a custom mode
• continue boot and see if you have a desktop at that specific resolution

at least I understand that the panel uses DP? Or did you mean an external screen?

[tqh]

I tried to follow your instructions with hrev55673, still goes black at Desktop. It is laptop screen, I think edp. UEFI so boots in native 1920*1080 32 bit. I picked it in boot menu just in case.

[rudolfc]

Hi there tqh,

Can you please retry with hrev55712 or later and upload a syslog again? There's a patch for the BIOS scanning code that might reveal the native mode of your internal panel where it did not do that upto now (there's a fault message in the last log indicating this).

Please also let me know your observations again :-)

Thanks!

[tqh]

Still black screen unfortunatly.

[rudolfc]

Thank you. OK, all in all it seems that the BIOS was never mapped to the legacy adress range to begin with. I will look more into this and get back at you..

[rudolfc]

Hi there tqh, Could you please see what hrev55823 (or later) does for your laptop internal panel? With luck you could have a picture now.. but at least I'd love to see another syslog again :-)

If you try, please upload a syslog from the attempt. Thank you!

(still not looked at mapping the BIOS better, so the driver will not yet know your native mode I expect, but eDP programming has a chance to be working OK now: if possible try setting the native mode, or close, via the bootmenu pre-booting as an extra test.)

[tqh]

It still goes to a black screen unfortunately.

[rudolfc]

Ok, can you try again with hrev55835 or later and upload a syslog again? A few more updates were done, and a logging update. I guess it will not work yet, but I'd love the log and your comment again :-)

[rudolfc]

Hello, I just committed hrev55845, which has a chance to improve your situation. Please test it and upload the syslog once more, with VESA dump, and with your comments :-)

One thing that is new is that the driver should now at least have EDID info for your screen (it will be fetched from the boottime detection if all is right, this is a newly added fallback which in your case should do something)

Thanks a lot!

[rudolfc]

Hi, in the meantime Sandy and Ivybridge internal eDP panels should work correctly: checked OK on two Sandybridge systems already. Can you please test a current nightly and let me know if it works ok now? (upload a syslog as well)

Thank you!

[tqh]

Still the same problem in hrev55897.

[rudolfc]

Thanks for testing! I think I first need to come up with another method of mapping the BIOS, since the driver at least still (logically) fails on that. I'll get back on this specific part at least.

I checked the eDP port bits dumped in the log: OK, found an error: your system is the first one I see using PipeC by default by the cardBIOS. While I have updated a lot of code to support that already: the pipecnt still needs to be updated from 2 to 3: I'll do that as first item. After that it could well be that the complete mode is set correctly, apart from the problem caused by the still unknown screen resolution/modeline. (BIOS)

Some questions:

• Can you tell me the internal panel's resolution?
• Do you have options to set a mode pre-boot? (bootmenu) if that is possible and you can select the native mode of the panel you might get a picture: it's interesting to know if you would get that picture in that situation or not.

Well: actually, all in all good news, looks like just 2 problems to solve:

• support 3 pipes in the driver (almost complete)
• map BIOS another way to fetch the modeline for the display.

So: same problem, but closer to solution indeed! :-)

[rudolfc]

Hello again, I just committed another update to the driver. While I expect no picture yet, it is very interesting to see the log from it: I would like to confirm pipeC is now indeed in use.

If that's the case, only the BIOS access issue remains I think..

Can you test the latest nightly? Be sure to test a clean system, since a power call is done in the kerneldriver this hook needs to exist indeed, otherwise you'll end in KDL. At least: that was what I saw tonight before I updated all my partitions..

Thank you!

[rudolfc]

Oh, that would be a nightly with at least hrev55916..

[tqh]

This is clean boot after updating to latest nightly with SoftwareUpdatr.

[rudolfc]

Looking good! The mode is actually programmed and it looks like the route is used the BIOS also uses. If you would be able to force app_server to load your native mode I expect you have a picture.

For the driver I'll now focus on the BIOS mapping. I'll get back to you on that!

[rudolfc]

Hi again, please try hrev55927 or later to see how the driver behaves now. Please upload a new syslog along with your observations. If you have a picture, also try some other resolutions and see if GLTeapot spins with approx 60fps / at all.

I have added a method to fetch the panel's native modeline 'officially' via a PCI config space register. This method takes precendence over the already existing ROM grab and scan feature, which now only functions as a backup if the preferred method fails.

I'd also like it if you add a file called 'intel_extreme' in home/config/settings/kernel/drivers folder: this file needs to contain one line with:

dump_rom true

in it. After a reboot the content of the preferred method, or the fallback method will be dumped to a file called intel_extremexxxxxxx.rom (the x-es will be the physical location of the card, including it's ID).

Please also upload the resulting file (8kB preferred method, or 64kb if fallback is operational) here as well.

Thank you!

[rudolfc]

Update: ah the settings file need to read that line as follows:

dump_rom true

so with the underscore added.

Thanks!

UPDATE 2: I corrected the folder info for the settings file in the post above! (sorry for the noise)

[tqh]

Still same black screen, seems it is not using 1920x1080 as UEFI boots with. It decides to set a lower res.

[rudolfc]

Are you sure about the resolution? your system reports:

• KERN: intel_extreme: VBT signature "$VBT SNB/IVB-MOBILE ", BDB version 165
• KERN: intel_extreme: panel type: 7
• KERN: intel_extreme: LFP info terminator 301e
• KERN: intel_extreme: found LFP of size 1366 x 768 in BIOS VBT tables

Are you absolutely sure the panel is -not- 1366 x 768? Check microsoft windows settings for example?

From the looks of it the driver behaves a whole lot better than before, so we are absolutely closer to the solution..

[tqh]

Yes it is 1920x1080. UEFI (when not in compability mode) boots in native res and it uses 1920x1080. Linux /sys/class/drm/card0-eDP-1/modes is reporting only 1920x1080 and is the res I use.

This seems like some default VESA mode? The mode list in Linux doesn't even list that resolution.

[rudolfc]

Hi, Ah interesting: so if you're running the i915 driver on Linux, try to find the text:

$VBT SNB/IVB-MOBILE

As that driver should report exactly the same thing.. Then see what modeline goes with that. Since the info dumped here in Haiku is what your BIOS is publishing after/during post so to speak, the idea is that this info is naturally correct. It would be a very bad thing if this is not the case, and exactly that is what it looks like seeing your report.. Did you ever flash the BIOS to a newer version for example? or is this laptop completely original still?

Seems like I need to expand searching for the modeline again by

• first looking at what is actually programmed in the cards registers
• if invalid, use the published info
• if that fails, use BIOS dump directly
• if that fails, just panic ;-)

[rudolfc]

'EDIT': you could upload a part of the i915 log here so we can see what is happening there. Also please see if you can upload the 8kb ROM file from Haiku in the home folder: another idea would be to manually parse that to see if we still have a fault in the parsing code.

[tqh]

I don't have any VBT command in Debian Buster, I use the drivers that come as default.

My guess is that bios info is not to be trusted on UEFI. With UEFI there is only the GOP driver that does graphics. ​https://wiki.osdev.org/GOP

Since Intel added ACPI functions for its graphics cards, I think the correct way is to get the data from the _DDC in ACPI: ​https://uefi.org/specs/ACPI/6.4/Apx_B_Video_Extensions/acpi-extensions-for-display-adapters-introduction.html?highlight=display

[rudolfc]

Interesting docs, I guess I'll look a bit closer. Though I save the info in a file named ROM: the info that is stored there in your case is actually from the UEFI interface ;-)

That's why I am wondering what's going on here. So, please upload that file..

[rudolfc]

Ah, I meant ACPI of course.

Update: it's the ASLS (ASL Storage) region, OpRegion. The info in that thing is described in a file called: acpi_igd_opregion_spec_0.pdf from intel.

[korli]

On Linux, I think debugfs provides a 8K binary file in /sys/kernel/debug/dri/0/i915_opregion

[rudolfc]

That should have the same content as the rom file that gets saved on Haiku in the home folder (also 8k), if enabled. So now I'd like to see both files :-)

[tqh]

I'll give it a try tonight.

[rudolfc]

Thank you. I am still looking it them: but they indeed seem to have the same content, in the area of interest.. Strange! Anyhow, I'll search a bit more and report back here.

[korli]

hi tqh, please test with a nightly hrev56088 or upper.

[tqh]

I tried it and the changes up to this weekend, but it is still the same. I plan to upload logs but you always have new changes that I want to try first before uploading logs. (Uploading logs is a bit of a hassle from that computer at the moment.) I see there is an interesting PR in the works as well :)

[korli]

Thanks. I've something in the works for the DpAux support on Haswell/SandyBridge. Getting the EDID is required when booting with EFI.

[korli]

tqh, here is the change: ​https://review.haiku-os.org/c/haiku/+/5319

Can be tested: ​https://haiku.movingborders.es/testbuild/I045b3c03f6b37bbffb3d8688658ffaa2a97311ae/1/hrev56112/x86_64/

[tqh]

I don't have any build environment so can it be merged so I can test a nightly?

[korli]

The movingborders URL proposes a pre-built anyboot image for such tests. I merged anyway in hrev56113. Please check and provide a syslog.