Intel NUC 8: No video output

[beaglejoe]

When booting, the icons display and light up, then display goes blank. After a few seconds, the monitor displays "no input"

This started around hrev55674

hrev55671 boots to desktop

Fail-safe video mode works ok

Status dec 2021: driver works OK, with occasionally blank screen (lost connection) after switching mode, restart needed to regain screen, while OS keeps working.

[beaglejoe]

Maybe a hint at Line 135 of syslog: KERN: intel_extreme: bad VBT signature: (garbage)

Also, Screen preferences shows nan Hz. Older hrevs showed 60 Hz.

[korli]

you might attach both syslog and syslog.old because the syslog.old contains the first part of the boot process.

[rudolfc]

Thanks for reporting!

• The line you mentioned should not be a problem I expect, there's a checksum/crc error or so on most chipsets, which of course should be solved at some point. Upto now at least the info gathered was still correct (I'll have a look at your setup anyway)
• the screenshot you provided is not while running the intel driver, it's framebuffer. nan Hz must be coming from there somehow, this would be a seperate problem.
• what -is- a problem, is that the driver detects 8 lanes in use for your panel, which must be in error as there are four max afaik. This results in wrong calcs for the refreshrate so your panel might be shutting off because of that.
• another thing I did not see yet is that no pipes were preconfigured by the card's BIOS, that might also be a source of trouble.

I'll start at looking for the number of lanes suspected error first and apply a patch for that to see if that would already help you.

[rudolfc]

BTW let me know please:

• is this a laptop?
• is only the internal display connected?
• what's the panel's native resolution?

Thanks in advance :-)

[beaglejoe]

Replying to rudolfc:

BTW let me know please:

• is this a laptop?
• is only the internal display connected?
• what's the panel's native resolution?

Thanks in advance :-)

It is an Intel NUC (BOXNUC8i5BEH1)

uses laptop hardware, but is a small form factor PC.
uses Intel Iris™ Plus Graphics 655

No internal display, connected via HDMI to AOC M24G1C monitor.
Native resolution is 1920 x 1080 @ 60 Hz

[beaglejoe]

Replying to rudolfc:

<snip>

I'll start at looking for the number of lanes suspected error first and apply a patch for that to see if that would already help you.

I can build and test here, if or when you have patches. Thanks for looking into this!

[rudolfc]

Thanks for the additional info, interesting piece of hardware you have there! Love those tiny formfactors..

OK, so it's normal no internal panel is found, good to know. I'll get back on this asap (today or tomorrow). I think I'll do a doublecheck on docs as first thing :-)

[rudolfc]

Hi beaglejoe, please try hrev55687. There was an error in determining the number of DP lanes in use. Will now detect 4 instead of 8 for you which fixes the link rate calculations and rate.

Questions:

• do you have a desktop now?
• can you switch between different resolutions?
• please check if the connected screen reports the same refreshrate as Screenprefs reports..
• please upload a syslog..

Thanks!

[beaglejoe]

Replying to rudolfc:

Hi rudolfc,
I built hrev55687

Questions:

• do you have a desktop now?

Yes, the original boot from USB came up in 1024 x 768 x 32 (60 Hz) see screenshot1.png

• can you switch between different resolutions?

Yes, I can switch to some of the listed resolutions, but not all of them work. I think that is to be expected though. 1920 x 1080 x 32 (60 Hz) works. see screenshot2.png

• please check if the connected screen reports the same refreshrate as Screenprefs reports..

I cannot find where to get this info from the monitor. The on-screen menu shows 135 Khz horizontal and 120 Hz vertical when using 1920 x 1080 @ 60 Hz. Don't know if that helps at all.

• please upload a syslog..

Attached as syslog-usb-boot

Thanks for fixing this!

Let me know if I can get any other info for you. Ticket is fixed if you want to close it.

[korli]

Please upload the PCI list part of the syslog (should be in syslog.old)

[korli]

Looks like missing. Please attach the output of listdev. Nothing in this ticket identifies the device exactly

[rudolfc]

Thanks for all your info. Looking good indeed :-) So still open could be considered:

• more external displays: what connectors do you have and would they work?
• you are one of the few people actually using a actual DP connection (so run that protocol, a lot of screens run DVI/HDMI over the belonging connector). Still open for DP specifically is fetching EDID info over the advanced controller piggybacking on the DP connection. This requires (in the end) a partial rewrite of the common functions Haiku has for this, so I am still postponing this a bit.

If you are OK with the current status we can close the ticket and maybe re-open it later. If you might do external screen tests please upload syslog and your observations along.

Every bit of info is usefull, even if your personal goal was already reached ;-)

[rudolfc]

Oh BTW I think the 120Hz might be it, and I wonder if that's OK. Please do one more test: try for instance 50Hz refresh (or 55, 65,70 whatever works) and see if you always see the double rate on that screen..

[rudolfc]

Oh, and double-check on Linux or windows maybe: that would tell you indeed if that number is the one and if we should do more work..

[beaglejoe]

I upgraded my main install via SoftwareUpdater. After removing the blocklist I used to force framebuffer use, it still boots to a blank screen.
Is there some settings file I need to modufy or remove?

[rudolfc]

Try booting framebuffer and remove the vesa and app_server_settings file, then reboot.

If you were in native mode and we'd have 120hz, the display would probably refuse service.

[beaglejoe]

Replying to rudolfc:

Try booting framebuffer and remove the vesa and app_server_settings file, then reboot.

File locations ??

[beaglejoe]

Replying to rudolfc:

Oh BTW I think the 120Hz might be it, and I wonder if that's OK. Please do one more test: try for instance 50Hz refresh (or 55, 65,70 whatever works) and see if you always see the double rate on that screen..

I think you might be right about the doubling. Possibly, vertical and horizontal might be inverted, also.

So far, I have tested:

1024 x768x32 @60 no reset

1440 x 900 x 32 @48  OK  h 88 v 96 via slider
1440 x 900 x 32 @55.2  OK  h 102 v 110 via slider

1440 x 900 x 32 @60  OK h 111 v 120
1440 x 900 x 32 @70  OK  h 131 v 140
1440 x 900 x 32 @72  OK  h 135 v 144
1440 x 900 x 32 @75 "input not supported" reverts
1440 x 900 x 32 @80 "input not supported" reverts

1440 x 1050 x 32 @60 blank reverts

1920 x 1080 x 32 @48  OK  h 106 v 96 via slider

The number h xxx and v xxx are as reported from On-screen monitor menu.

Windows shows h 67 v 60 for a 1920 x 1080 x 32 @60 Hz (connected to identical monitor via VGA cable) Windows shows h 67 v 60 for a 1920 x 1080 x 32 @60 Hz (connected to same monitor via HDMI cable) Windows shows h 56 v 50 for a 1920 x 1080 x 32 @50 Hz (connected to same monitor via HDMI cable)

[rudolfc]

I am -very- curious what type of screen you have there, seems quite special in that it accepts a lot..

Ok, I'll dig into the specs for your card once more. Maybe the ref frequency differs.

[beaglejoe]

Replying to rudolfc:

I am -very- curious what type of screen you have there, seems quite special in that it accepts a lot..

Ok, I'll dig into the specs for your card once more. Maybe the ref frequency differs.

I have a PDF manual (don't remember where I downloaded from). It has pinouts for the connectors and a table of Preset Modes. I can put it on my DropBox if you want.

[beaglejoe]

I found this curious:

1280 x 800 x 32 @56.5  Set via slider: mode changes OK
1280 x 800 x 32 @59.7  Set via slider: mode changes OK

1280 x 800 x 32 @60    Picked from refresh rate list: Sreen goes blank, reverts after timeout.

1280 x 800 x 32 @60.4  Set via slider: mode changes OK
1280 x 800 x 32 @63    Set via slider: mode changes OK

There are also some modes that don't work and also don't timeout and revert, requiring a power button restart.

[beaglejoe]

Replying to beaglejoe:

Replying to rudolfc:

Try booting framebuffer and remove the vesa and app_server_settings file, then reboot.

File locations ??

I removed these, but still booting to framebuffer

~/config/settings/system/app_server

~/config/settings/kernel/drivers/vesa

[rudolfc]

Hi again, yes the PDF would be interesting to see, thanks :-)

In the meantime, can you test hrev55688 for me? Please upload a syslog again. I removed one dependancy that was presumed fixed, which is now read from your DDI link config: the colordepth set there by the BIOS. I presumed 24bit, which mostly is OK, but not always (laptops often 18bits panels..).

In your case it might even be 12bit depth, which would be active in a non-RGB mode. (EDIT: hmm, I am mixing a few things up here, but please test anyway..)

IF that does not help, we need to fiddle with the reference clock on that link. I have already searched for the details on that, but this is difficult to determine and it looks like I need to add more code to fetch it from the config done by the BIOS. (will try if needed of course).

So please test, upload a syslog again, and tell me what your screen says for the vertical refresh.. :-)

Thanks in advance!

[beaglejoe]

Replying to rudolfc:

Hi again, yes the PDF would be interesting to see, thanks :-)

​https://us.aoc.com/en-US/gaming/products/monitors/c24g1/downloads pages 52-54

In the meantime, can you test hrev55688 for me? Please upload a syslog again. I removed one dependancy that was presumed fixed, which is now read from your DDI link config: the colordepth set there by the BIOS. I presumed 24bit, which mostly is OK, but not always (laptops often 18bits panels..).

In your case it might even be 12bit depth, which would be active in a non-RGB mode. (EDIT: hmm, I am mixing a few things up here, but please test anyway..)

IF that does not help, we need to fiddle with the reference clock on that link. I have already searched for the details on that, but this is difficult to determine and it looks like I need to add more code to fetch it from the config done by the BIOS. (will try if needed of course).

So please test, upload a syslog again, and tell me what your screen says for the vertical refresh.. :-)

Thanks in advance!

Syslogs attached (they end in -hrev55688) Tested a few modes. It appears so far to be the same as hrev55687. The driver works, but vsync seems doubled?

I still can't get my main partition to use the new driver. Am I removing the wrong settings files? It still using framebuffer.

[rudolfc]

Hi, Yesyes, that -is- a very interesting screen you have there. Indeed, looks like refresh is doubled, this screen simply -does- 144Hz(!).

About you being unable to get the driver to work: I think this is a UEFI system, and Haiku simply does not load the user unpackaged hierarchy in time for app_Server to pick it up during it's scan for a graphics card driver.

Therefore you -must- have it in the system hierarchy in order to work.. So it must be inside the package that contains the drivers, which is a big handycap for me while working on this as well..

EDIT: indeed your panel link runs in 24bit color (3x8), so this wasn't the fault. In the meantime I think I know where to fetch the baseclock, currently testing with it and poking around on my own system to get it confirmed..

[rudolfc]

BTW I did create a ticket for this problem already ;-)

[rudolfc]

Another update done: hrev55690. You'll get that with the next nightly at once. In the meantime I found out that post skylake systems have more differences than was expected: the PLLs are different again, which could be the explanation for the trouble on external screens for a lot of people, and also for the to high refresh on your screen.

Anyhow, each update gets us closer to a correctly working system ;-)

[beaglejoe]

Replying to rudolfc:

Hi, perfect. Another update done: hrev55690 You'll get that with the next nightly at once. In the meantime I found out that post skylake systems have more differences than was expected: the PLLs are different again, which could be the explanation for the trouble on external screens for a lot of people, and also for the to high refresh on your screen.

Anyhow, each update gets us closer to a correctly working system ;-)

Indeed. Great work!

You are making huge progress.

I am building hrev55690 right now.

I did more testing with hrev55688 and is much improved from hrev55687.
Almost all of the choices presented either work or revert correctly.

PS. My issue with my main partition is solved. (user error!)

[beaglejoe]

Hi, I haven't done much testing yet, but attached syslog-hrev55690 for your reading pleasure.
Strangely there is no syslog.old ??

The refresh rate is still doubled. The monitor is 144 capable. In testing hrev55688, (almost) every setting works up to 72Hz, but nothing works at 75Hz. I had come to the same conclusion as you. The monitor is just handling the doubled rate for most settings.

[rudolfc]

Nice you got the driver working in the main partition. How did you do it? UEFI no? which rev is the OS itself?

Upto now the log does not indicate changes for you, ref clk is still 24Mhz (was before, but fixed and now detected if all is right); colordepth on link is detected 24bit, was fixed 24 bit.

I think I need to adapt the PLL programming code and hopefully find how to detect the baseclock for the DDI: I mentioned I did find it , but that was for skylake: after that I found for later cards this does not apply unfortunately, I think. I'll get back to you on that.

If you want to do a quick test, and don't mind compiling yourself: change the detected lanes from 4 to fixed 2: I think we have a chance that the refresh is OK then for your setup (we started at 8).

I am not going to upload that to git though since I need to determine what's really not OK here of course :-)

Anyhow: if you do test that, let me know what happens, and upload a tweak-syslog here as well..

[beaglejoe]

Replying to rudolfc:

Nice you got the driver working in the main partition. How did you do it? UEFI no? which rev is the OS itself?

I had moved my packages (blocklist file) to the Desktop in case I needed to put it back. But I had COPIED it instead of moving it! the rev on that partition is 55687 (I think). I copied the haiku package and the haiku_loader packages that I had build onto that partition, so I don't run into the non-packaged driver issue. I will more properly upgrade via SoftwareUpdater once all your fixes hit the nightlies.

Upto now the log does not indicate changes for you, ref clk is still 24Mhz (was before, but fixed and now detected if all is right); colordepth on link is detected 24bit, was fixed 24 bit.

I think I need to adapt the PLL programming code and hopefully find how to detect the baseclock for the DDI: I mentioned I did find it , but that was for skylake: after that I found for later cards this does not apply unfortunately, I think. I'll get back to you on that.

If you want to do a quick test, and don't mind compiling yourself: change the detected lanes from 4 to fixed 2: I think we have a chance that the refresh is OK then for your setup (we started at 8).

What file to make this change?

I am not going to upload that to git though since I need to determine what's really not OK here of course :-)

makes sense.

Anyhow: if you do test that, let me know what happens, and upload a tweak-syslog here as well..

Will do.
BTW, where is the screen resolution stored? The Installer and first boot always come up in 1024 x 768.

Oh also, if I go to the boot menu, the monitor menu shows 60Hz. I think Frambuffer also, but I will double check.

[rudolfc]

Ah yes, you are applying the same non-packaged-system trick as I do. Thanks for clarifying. I am looking over the code, maybe don't touch the lanes, as that's actually working OK.

Instead change the fixed base frequency to half that or double that (see which one will fix the refresh, I am guessing half the rate.

It's in Ports.cpp, routine _SetPortLinkGen8(), item LinkBandWidth (now 270000). This one I still need to autodetect as I tried to imply above.

Let me know, OK? I'm very curious indeed ;-)

[rudolfc]

BTW: don't bother with VESA and framebuffer, these are working completely different, that won't tell us anything at all. The mode is a failsafe default from app_Server if all is right, so it's not stored in the driver or BIOS or screen.

In order to fix this I need to extract EDID from your screen, via DP protocol DDC piggyback use. (aux channel does this via high-level controller hardware for I2C)

[beaglejoe]

Replying to rudolfc:

Ah yes, you are applying the same non-packaged-system trick as I do. Thanks for clarifying. I am looking over the code, maybe don't touch the lanes, as that's actually working OK.

Instead change the fixed base frequency to half that or double that (see which one will fix the refresh, I am guessing half the rate.

It's in Ports.cpp, routine _SetPortLinkGen8(), item LinkBandWidth (now 270000). This one I still need to autodetect as I tried to imply above.

I changed Line 1457 to:

uint32 linkBandwidth = 135000; //khz

When booting to that install, I get "input not supported" right after boot icons. Will try 540000 next.

Let me know, OK? I'm very curious indeed ;-)

[rudolfc]

Jummy. Hardcore live hardware programming! :-)

[beaglejoe]

Success! With Line 1457:

uint32 linkBandwidth = 540000; //khz

Boots to 1024 x 768 @60 Monitor show 60.

Changed to 1920 x 1080 @60 Monitor show 60.
Changed to 1920 x 1080 @75 Monitor show 75.
Previously, nothing worked at 75.

See syslog-540000
Hope it helps!

[beaglejoe]

This is done over HDMI. I can also connect with a DP cable if that might give more info.

[rudolfc]

Super! Thanks! Yeah, also try DP. Was all done via HDMI upto now btw? It seems your screen uses DP over HDMI ..

[rudolfc]

Oh, do you also have the option to do analog VGA test, even over an external adapter?

[rudolfc]

Or: do you have an older HDMI screen? I would love to hear what that would do, as you would rely on other PLL calcs probably still down for you..

[beaglejoe]

Strangely, if I connect the monitor via DisplayPort, the monitor reports 60Hz.
But connected via HDMI, it reports 120Hz. This is with hrev55692 (unmodified).
Linux Mint reports 60Hz on either connection.

Was all done via HDMI upto now btw?

Yes

Oh, do you also have the option to do analog VGA test, even over an external adapter?

I'll see if I can find an adapter.

Or: do you have an older HDMI screen? I would love to hear what that would do, as you would rely on other PLL calcs probably still down for you..

I think that I have one around, but I'll have to figure out how to get the Hz to display. Or can that be determined from the syslog? If so, where?

---

​https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/NUC8i3BE_NUC8i5BE_NUC8i7BE_TechProdSpec.pdf

Page 12 explains the NUC's video connection(s)

[beaglejoe]

New syslogs attached. Made from an install of hrev55962.
syslog-dp taken when connected via USBC to DisplayPort cable.
syslog-hdmi from when connected via HDMI cable.

If you no longer need the older syslogs, feel free to delete them.

[rudolfc]

Thanks! Which one gave correct refresh again? And were both logs made with 540mhz setting patch?

[beaglejoe]

DisplayPort shows correct refresh.
HDMI shows doubled refresh.
This was done with an unpatched build of hrev55962.
I formatted the partition, installed to the partition from a USB stick (then copied my synergy files to the partition). I rebooted to the new install with DisplayPort connection, grabbed syslog. Deleted syslog. Shutdown. Reboot with HDMI connection. Grabbed syslog.

[rudolfc]

Thanks, I'll dive in the techdocs to see if what I see gives me what I need to get that base frequency :-)

[rudolfc]

Bingo: got it! Thanks to your two different behaving outputs and your very special screen, and your work in testing.

Big thanks to you, I'll update the driver and come back to you for the next test! :-)

[rudolfc]

BTW That leaves PLL programming for non-DP modes, these will no doubt be down since the PLLs now sit at different locations, and have different content, combined with different calc method.

If you would come across a screen that does not have a DP input, it will no doubt run in HDMI or DVI mode, and if you'd have that, I'll be haunting you for more tests... ;-)

The analog VGA will probably internally have a DP converter, so I expect it will run OK with the coming update for the base frequency for the link programming (Which is only used for DP protocol)

Stay tuned, update will come tonight (I hope)..

[rudolfc]

Thinking a bit more I just realized that it might well be the PLL's are still on the skylake location and function for coffeelake. Icelake has these modifications in PLL, that I know for sure.

So if you'd find a non-DP digital screen, it might be it works 'right out of the box' after all ;-)

[rudolfc]

Hi, can you test hrev55697? If all is right both HDMI and DP connector work correctly on your DP capable gaming screen ;-)

Please confirm..

Thank you!

[beaglejoe]

Replying to rudolfc:

Hi, can you test hrev55697? If all is right both HDMI and DP connector work correctly on your DP capable gaming screen ;-)

Please confirm..

Thank you!

tldr: Both HDMI and DisplayPort connections work and monitor now confirms correct refresh rate.

So great progress!

I also had an ASUS ve228 monitor which has no DP but does have HDMI. It works as well. Additionally, I connected the NUC to the monitor with a USBC to HDMI cable and that works.

I went through all the listed modes from page 50 of the AOC manual. Every one that is available from the Screen app works well via DisplayPort.
For HDMI, there are two that do NOT work.

• 1280 x 720 @60Hz
• 1024 x 768 @60Hz

Both of these modes present a "no signal" message on the AOC monitor. Both will also work if in the Screen app, you use the slider and set refresh to 59.7.

This may provide a clue to why other people cannot get a display. 1024 x 768 @60Hz is the default if I remember correctly.

If someone could try Safe-mode graphics and change the screen resolution. Or change the resolution at the <SHIFT> boot menu. It might boot.

Hope this helps.
Thanks again!!

[rudolfc]

Super! Still, I do need a syslog from the attempts with both connections including the modes that do not work (these explicitly would be handy). If all is right this display also came up with EDID info Wich I would like to see..

Thank you!

[beaglejoe]

With some more testing, the issue with these two modes under HDMI, appears to be intermittent.

• 1280 x 720 @60Hz
• 1024 x 768 @60Hz

Unfortunately, even when one sets successfully, on reboot, it may or may not work.

The syslog-failed-55967 file should contain a failed mode switch near the end. I had to use <Ctrl><Alt><Del> to reboot. I rebooted to a different partition and obtained the syslog.
Hope it helps.

[rudolfc]

Thanks again! Observations:

• I don't see trouble in the driver
• Your ASUS screen is also a DP capable screen, it runs in DP mode.

Questions:

• Are you aware that you can use a keyboard shortcut to fallback to a lower mode? (I think it's <ctl><alt><esc>. Hitting once will go to a lower mode, hitting again, goes to an even lower mode. Maybe you can overcome the no picture problem this way, instead of doing a reboot.
• Another option to test would be applying the troublesome mode to one workspace only, and see if you can overcome that by switching to another workspace
• if that works, the system is at least operational
• if that doesn't work, I think it's a problem outside of the driver.
• Can you connect your ASUS to the DP connector (if needed via converter cable, if you'd have that), and test the troublesome modes again: are they now ok?
• Can you try the troublesome modes again with the beautiful 144Hz screen and see if it's really always OK there? especially if connected via the HDMI connector..

The last few questions I am asking because the base clock for the connection differs between the HDMI and DP connectors, and there might be a slight chance that this is the source of the problem (divider becoming to coarse to work correctly, and I'd in fact need to (try to) change the base clock..)

Thanks for answering in advance :-)

[rudolfc]

Oh, do you have the specs for that ASUS? And would you just maybe have yet another HDMI or maybe even better a DVI screen at your disposal? (dare I ask? ;-)

Thanks!!

[beaglejoe]

Replying to rudolfc:

Thanks again! Observations:

• I don't see trouble in the driver
• Your ASUS screen is also a DP capable screen, it runs in DP mode.

Questions:

• Are you aware that you can use a keyboard shortcut to fallback to a lower mode? (I think it's <ctl><alt><esc>. Hitting once will go to a lower mode, hitting again, goes to an even lower mode. Maybe you can overcome the no picture problem this way, instead of doing a reboot.

Thanks, I was not aware. (It's actually <Shift><Command><Ctrl><Escape>), but it does not work once I am in the blank screen situation. It acts like a system call never returns ??

• Another option to test would be applying the troublesome mode to one workspace only, and see if you can overcome that by switching to another workspace
• if that works, the system is at least operational
• if that doesn't work, I think it's a problem outside of the driver.

I tried setting different resolutions on different workspaces. Similar to above, once the condition occurs, I can't switch to the other workspac(s) via <Alt><F#>

• Can you connect your ASUS to the DP connector (if needed via converter cable, if you'd have that), and test the troublesome modes again: are they now ok?

I will attempt this soon...

• Can you try the troublesome modes again with the beautiful 144Hz screen and see if it's really always OK there? especially if connected via the HDMI connector..

I have been testing the 1024x768 mode and it does not work reliably on HDMI. When it does work, I can change to another workspace (causing a monitor resolution change) when I change back, it will usually fail.

The last few questions I am asking because the base clock for the connection differs between the HDMI and DP connectors, and there might be a slight chance that this is the source of the problem (divider becoming to coarse to work correctly, and I'd in fact need to (try to) change the base clock..)

Thanks for answering in advance :-)

[beaglejoe]

Replying to rudolfc:

Oh, do you have the specs for that ASUS? And would you just maybe have yet another HDMI or maybe even better a DVI screen at your disposal? (dare I ask? ;-)

Thanks!!

I don't have a spec sheet for the ASUS, it is a model ve228. It does have a DVI port, I'll see if I can find an adapter.

[beaglejoe]

Upon some further testing, it turns out that I can connect to the machine via ssh when it is in the blank screen state. So it seems less like a non-returning system call and more like a lost connection to the monitor. So it may be possible to get information from a "live" system when this occurs.

[korli]

it might be interesting to have a register snapshot feature in the driver or accelerant, that one could trigger on demand (even if it requires a ssh connection).

[rudolfc]

Sure, what also might be helpful at times is having the bios dumped to file :-)

BTW a possible reason for screen off might be that the driver does not yet set dpms off for modesetting.

At some point it should be re-enabled, but currently that cannot be done without caching the situation found set by the bios upon driver start. I use this as a screen connected detection since that turned out to be more reliable than actually checking the intended target bit, and EDID is not yet always up to use.

[beaglejoe]

@rudolfc,
Don't know if it will tell you anything, but I noticed in the syslog tha I attached to #17464

https://dev.haiku-os.org/attachment/ticket/17464/syslog

At line 7224: KERN: intel_extreme: Power: Digital Display Interface B DDI enabled: false

At line 9098: KERN: intel_extreme: Power: Digital Display Interface B DDI enabled: true

Hope it helps.

[rudolfc]

Hi again,

Can you try hrev55928 or later? The panel's native mode is maybe known now, which could result in a working driver.. If you have a desktop, try some other resolutions as well. Also test if GLTeapot spins at 60HZ.

In the meantime the ROM (or rather some info created by the ROM) is fetched (ACPI / PCI config space), which now also can be dumped to a file in your home folder. In order to do that, create a file called intel_extreme in the home/config/settings/kernel/drivers folder.

It needs one line in it: dump_rom true

After rebooting the kerneldriver will dump the info in a 8kB ROM file I expect, which would also be interesting to see uploaded, along with a new syslog..

Thank you!

[beaglejoe]

Replying to rudolfc:

Hi again,

Can you try hrev55928 or later? The panel's native mode is maybe known now, which could result in a working driver.. If you have a desktop, try some other resolutions as well. Also test if GLTeapot spins at 60HZ.

With hrev55928, everything works very well, until it fails. GLTeapot at 60, mode switching, refresh rate switching. All works great. 1024 x 768, seems to cause instability. Sometimes the screen goes blank on setting it, other times it will intermittently fail on reboot or return from another workspace. So it is about the same as before.

In the meantime the ROM (or rather some info created by the ROM) is fetched (ACPI / PCI config space), which now also can be dumped to a file in your home folder. In order to do that, create a file called intel_extreme in the home/config/settings/kernel/drivers folder.

It needs one line in it: dump_rom true

After rebooting the kerneldriver will dump the info in a 8kB ROM file I expect, which would also be interesting to see uploaded, along with a new syslog..

I created the file as specified, but I cannot locate the ROM file, it wasn't in home/config/settings/kernel/drivers or with the syslogs Where do you expect it to be created?

Thanks.

[rudolfc]

Hi, I would expect it in your home folder. can you also upload a syslog again? Thank you!

[beaglejoe]

Replying to rudolfc:

Hi, I would expect it in your home folder. can you also upload a syslog again? Thank you!

You are correct. Right in the home folder. Logs attached.

Thanks.

[korli]

Please check with hrev56001 or newer. Thanks.