Intel HD driver - nightly regression

[un_spacyar]

Hi. On hrev55120 (32 bit), I get the screen like in a "out of sync" (see screenshot). On hrev55102+1 (and before), the driver works perfectly, so I guess the issue is related to some recent change.

On hrev55102+1, the Screen Preferences identify the video hardware as "Intel HD/Iris (IronLake Mobile)".

I attach also the listdev output.

I tried the following workaround, without sucess:

• I deleted the ScreenData file in ~/config/settings
• I deleted the Workspaces_settings in ~/config/settings

[un_spacyar]

listdev ouput

[un_spacyar]

Screen Preferences hrev55102+1

[un_spacyar]

Screen output

[rudolfc]

Hi, I'm currently working on the driver. Can you add a syslog here? (if you can't grab it because you have no picture, you can try the previous_syslog).

So this is a laptop and you're looking at the internal screen. I am guessing you are running this in native mode?

Note to self: this is generation 5.

[un_spacyar]

Hi Rudolf! Yes, I'm working on real hardware, and using the internal screen (it's a Dell 11z laptop). I attach the syslog. Just to get the syslog 'clean', I did the following:

1. I deleted all syslog files.
2. I started Haiku, normal boot. Ended with the weird 'out of sync like' screen.
3. I started again, this time enabling the Safe video mode.

I found only one Syslog file, that contains the two boot attempts. The first half of the syslog have the failed attempt. The second half, the correct one with the safe mode video enabled.

[un_spacyar]

Syslog

[rudolfc]

Thank you. It indeed has the info I was looking for. I am thinking that the regression might actually be progress: since the DPLL programming now works, it might be this uncovered actually another problem in the driver that now makes your system not work OK.

While working more on digital connections I discovered 2 type errors in the codebase today which I fixed in git in hrev55125. Could you please upgrade to that one and see if that changes the driver's behaviour and describe the change (if there) to me?

[rudolfc]

Thank you. It indeed has the info I was looking for. I am thinking that the regression might actually be progress: since the DPLL programming now works, it might be this uncovered actually another problem in the driver that now makes your system not work OK.

While working more on digital connections I discovered 2 type errors in the codebase today which I fixed in git in hrev55125. Could you please upgrade to that one and see if that changes the driver's behaviour and describe the change (if there) to me?

[un_spacyar]

Hi Rudolf! I tested again, after upgrading to hrev55125, but got the same behaviour.

I send the new syslog (same format here: first boot, normal one, with the out-of-sync screen, second half of the syslog is boot with the safe video mode enabled).

[un_spacyar]

Syslog from hrev55125

[rudolfc]

Ok thanks. Is it also possible to upload a syslog from the old, working version, of the driver?

Looks like I have to come up with a few specially compiled testversions for you to see which change I did had this effect..

[un_spacyar]

Hi! sure, no problem. Here I'm using 32 bit, so no problem about trying with some specific test version.

also, I'm sending the Syslog from the previous hrev, where the driver worked without problems (hrev55102+1).

[un_spacyar]

Syslog from hrev55102+1 (no issues here)

[rudolfc]

Thank you. BTW Another workaround: could you try this:

• boot with failsafe driver VESA.
• with screenprefs, set display resolution 1024x768 (also try 1280x1024) assuming you get these presented.

-reboot, and hit spacebar to enter the bootoptions menu again.

• do -not- select the failsafe driver, but -do- select a custom display resolution (Default it says: current). choose the same resolution as you selected just now with screenprefs.
• continue the boot.
• do you now have a working screen in the specified resolution?
• if you want to keep that, once more use screenprefs to temporary set another mode (i.e. other colordepth) and accept it.
• you should have a working screen now as well, as long as starting with 1024x768 you did -not- select a higher resolution, and with 1280x1024 you did -not- select a lower resolution. Choose within these rules a nearby resolution.
• this time the screenprefs will also make sure the bootscreen has the same resolution I think, so next time you can boot without tricks.

Does the above tricky method work for you? (remember that there's also a file called 'vesa' which holds the bootmode..

I'm very curious if this works for you?

UPDATE: Oh sorry, another mode will not work yet for you I think, so switch colordepth instead. for the test to get a working desktop. In the laptop case for now both the booticons screen and the screenprefs need to be in the same resolution and refreshrate.

Anyhow: awaiting your reply ;-)

[un_spacyar]

Hi! I did the following test (I will detail the steps just to make sure that I followed the process correctly):

1. Started Haiku in safe video mode.
2. Changed the Screen properties to 1024 x 768 and 16 bit color.
3. Reboot and in the boot options, and choose the same resolution and color deep that in the previous step (but not choosing the safe mode video).
4. At this point, I get the same screen that in the original post (the out-of-sync-like).

I repeated the process choosing 1024 x 768 and 8 bit color. Same results.

Please, tell me any further test that could be useful

[rudolfc]

OK, that was the right procedure I think. In the meantime it's good we are testing on 32bit since there seems to be an additional problem with 64bit. For now I am assuming compiling there does something not entirely right.

I'll post a testing driver or two here in which I disable some of the additional programming I added so we can see what that does. Would be nice if you could post screenshots again as well.

[rudolfc]

Can you redo tha last test method with this driverversion and see what happens? Thanks!

[madmax]

I have similar output in my laptop panel with IronLake IGD. Using ​6bpp instead of 8 here solves it for me. That is what my BIOS sets, so ditching that line also works, of course. The BIOS also sets dithering, but I get a working panel both with and without it.

[rudolfc]

Interesting! So this one line set to 6bit makes your screen work correctly in the one mode already set by the BIOS if the screenprefs panel is set to same I understand. Can you confirm that you can also use some other modes using the workaround I just described?

Thanks for trying things! that makes life so much easier :-)

[rudolfc]

Oh madmax: question: did you try 32bit Haiku or 64bit? And if you did not test 64bit, could you test that as well and report back? Thanks!

[madmax]

64bit.

I did try reverting and applying each chunk in hrev55115 and hrev55125. The only thing that made a difference was the bitdepth.

The previous comment there points to it being about the display hardware, not the framebuffer. That is, even though I have it at 6 bits per pixel, the screen mode is still 32bit color. 6bpp seems to be common for old LVDS panels, while newer ones use 8, so I guess no silver bullet here unless you can get that info from EDID or somewhere else.

Other modes do work. In fact, if I boot with a VGA monitor connected (I know you are still not there, but this info may be interesting later), I get the image in the panel with the 1280x1024 mode from the monitor.

[un_spacyar]

Hi! I'm going to test the provided driver. Is enough to just copy them to this location? : /boot/home/config/non-packaged/add-ons/accelerants /boot/home/config/non-packaged/add-ons/kernel/drivers/bin

or additionally I need to blacklist the drivers located in /system/addons/ ?

Thanks!

[rudolfc]

un_spacyar, forget about that testversion for now I'd say. The comments from madmax make perfect sense to me so I now know in which direction to update git. After I did that I'll ask you to retest. OK? Thanks!

[un_spacyar]

Welcome! Any additional test that you need, just ask. Glad to help!

[rudolfc]

version 4 tesdriver (32 and 64bit)

[rudolfc]

Thank you! Please test the V4 driver. Yes, copy to those locations, No, no blacklist needed, Additionally you need to create a shortcut to the kerneldriver in /boot/home/config/non-packaged/add-ons/kernel/drivers/bin. This shortcut needs to be in /boot/home/config/non-packaged/add-ons/kernel/drivers/dev/graphics.

After you did those 3 things, just reboot and see what happens :-)

[un_spacyar]

Hi! I tried installing the "intel_extreme_drv_v4.zip" attached recently and now works perfectly! Almost no issues detected. (see below)

There is a quick checklist of what I tried:

• Native resolution: Works
  • Native resolution: different color deph (8 , 16, 32 bit): Works
• Non native resolution (like 800 x 600, 1024 x 768); Not works (out of sync).
• Bright control: Works
• Video playback: Works.
• GL Teapot: Works.

In other words, the only "regression" still active is the non-native resolutions (no big deal, really).

[rudolfc]

Thanks for the update! Can you also upload a syslog from these tests? That might give me some more clues. Good to know the regression by itself is gone indeed. Though it would be very nice if other resolutions would work as well I think.

[rudolfc]

@madmax: could you see what the V4 driver does for your system as well? (interesting fact btw about that external monitor: what's the native resolution for that screen btw?)

[madmax]

Test driver and no external monitor

[madmax]

Test driver with external monitor

[madmax]

Driver from master

[madmax]

IronLake, laptop panel, 64bits

Out of sync regression solved. Native resolution works and color depth can be changed. Changing refresh rate skews the image, but that also happens without the test driver. Changing resolution also skews the image, which doesn't happen in master (except for the highest 1920x... ones, where a few lines are off at the top with the rest of the image OK).

The external monitor native resolution is 1280x1024, and it's connected via VGA.

Attached full session syslogs. The one with the external monitor is just boot and reboot, bad image now as it uses a non-native resolution. In the other ones I change refresh rate and resolutions.

[un_spacyar]

Hi. I'm sending the syslog, using the provided driver (intel_extreme_drv_v4.zip).

[un_spacyar]

Syslog using the "intel_extreme_drv_V4" driver

[rudolfc]

Hello guys, could you please test hrev55168 or later for me? Things might have improved again (I hope ;-) Also please upload a syslog or two.. Thank you!

[madmax]

For my IronLake laptop, the issues with non-native resolution were solved in hrev55159. hrev55168 does not change anything for me, but I guess that's expected, as I just have the LVDS panel and a VGA monitor.

[un_spacyar]

Hi, good news! I tried in hrev55168 (and after deleting the driver that was copied manually in the "non-packaged" directory), and everything looks good: Native and non native resolutions works perfectly.

As you requested, I'm uploading a syslog in case that is useful for you.

I will continue to do more test, just in case, but I'm pretty sure that this issue could be marked as fixed.

Thanks for your help!!!!

[un_spacyar]

Syslog from hrev55168 - everything works well - no issues found.

[rudolfc]

Could you see if the beta branch (or current nightly) still works OK for you? If so, I suggest we close this ticket for now indeed. Thank you! and You're welcome :)

[humdinger]

I experience a regression as now as well...
All worked very well with hrev55168, now I updated to haiku-hrev1~beta3_hrev55185-1 and I get a black screen (on my notebook panel). Attached the syslog "syslog_humdinger".

[humdinger]

black screen: haiku-hrev1~beta3_hrev55185-1

[rudolfc]

Hmm. That's a shame. Can you upload such a syslog also from hrev55168 so I can compare what changed in behaviour?

[rudolfc]

BTW I am working on another change for assigning the pipes so I am kind of hoping that will fix it again for you. The changes I did were no error..

[humdinger]

working: syslog hrev55168

[humdinger]

syslog hrev55168 attached. hope you find the issue, one way or another. :)

[rudolfc]

Yes, the pipe is assigned reversed for you between those two. Might be that what I am working on will reverse it again and thus fix it. I'll keep you posted!

[rudolfc]

Hi, Could you please test hrev55189 or later for me? Please also upload a syslog again. If all is right the pipe assignment issue should be solved for you..

Thank you!

[humdinger]

I'm happy to report, that after compiling the intel_extreme+accelerant of your commit def51fb91001b66ecb54a5be605d55d7b652701f and putting them into non-packaged, my display is working again!

Thank you, thank you, thank you\\ "syslog_working" attached.

[rudolfc]

Hello Humdinger,

Hi again,

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

I blocked (for your system type) 'old' DP-port scanning: so now it only scans DDI as it should be for you. I also blocked FDI programming for the DDI-A port where your internal panel is: it should not need that (also the settings made no sense from the previous log so that got me thinking ;-)

I would like to know if you have the same (or better) behaviour on your system now? Can you upload a syslog again?

Thank you!

[humdinger]

v6_hrev55200 works just as well as the one before. At least I don't see a difference... At first I thought the black screen before the display lights up is shorter, but after a few reboots I think that just varies; from lighting up immediately to having to wait for some secoonds.

syslog.v6 attached.

[un_spacyar]

Sorry for my late answer (I had been without internet service for five days). Just in case, I tested the Intel_extreme_drv_v6_hrev55200.zip driver on hrev55202 (32 bit), and works well, no issues or regressions found.

Please, feel free to ask any aditional information that you could need. Thanks!!

[rudolfc]

no matter un_spacyar, thanks for reporting back anyway. In the meantime that driver is outdated again (v6) and you can grab the latest nightly for current compatibility/improvement testing if you want. Thanks again!

[humdinger]

Not sure if this should go ina new ticket: When running your driver on my "production system" everything's fine. But when running a test installation of hrev1~beta3_hrev55206-1, I get a garbled screen:

This is the same with the system's intel_extreme driver, or when I use the v6 driver in non-packaged. Attached, the syslog.garbled of that.

[humdinger]

FWIW, comparing the syslogs using the same driver, I get the working in hrev55193:

KERN: intel_extreme: SetDisplayMode: Digital Display Interface A 1920x1080
KERN: intel_extreme: Enable: PCH_PANEL_FITTER_CONTROL, 0x80800000
KERN: intel_extreme: Enable: PCH_PANEL_FITTER_WINDOW_POS, 0x0
KERN: intel_extreme: compute_dpll_g4x: required MHz: 138.059, reference clock: 120
KERN: intel_extreme: PLL limits, min: p 5 (p1 1, p2 5), n 3, m 79 (m1 14, m2 7)
KERN: intel_extreme: PLL limits, max: p 80 (p1 8, p2 10), n 8, m 118 (m1 24, m2 11)
KERN: intel_extreme: compute_dpll_g4x: best MHz: 138 (error: 0.0590057)
KERN: intel_extreme: compute_pll_divisors: found: p = 20 (p1 = 2, p2 = 10), n = 4, m = 92 (m1 = 17, m2 = 7)

to the non-working hrev1~beta3_hrev55206-1:

KERN: intel_extreme: SetDisplayMode: Digital Display Interface A 1024x768
KERN: intel_extreme: Enable: PCH_PANEL_FITTER_CONTROL, 0x80800000
KERN: intel_extreme: Enable: PCH_PANEL_FITTER_WINDOW_POS, 0x0
KERN: intel_extreme: compute_dpll_g4x: required MHz: 65, reference clock: 120
KERN: intel_extreme: PLL limits, min: p 5 (p1 1, p2 5), n 3, m 79 (m1 14, m2 7)
KERN: intel_extreme: PLL limits, max: p 80 (p1 8, p2 10), n 8, m 118 (m1 24, m2 11)
KERN: intel_extreme: compute_dpll_g4x: best MHz: 65.1429 (error: 0.14286)
KERN: intel_extreme: compute_pll_divisors: found: p = 30 (p1 = 3, p2 = 10), n = 7, m = 114 (m1 = 21, m2 = 9)

Did something besides the intel_extreme driver change that explains the difference?

[rudolfc]

Setting modes probably doesn't work very good on DDI (or not at all) yet, so you should probably go into the boot menu, select the same mode as is set in app_server (1024 apparantly) and continue the boot without using failsafe graphics.

Or the other way around:

• boot with vesa mode, set 1920x1080, reboot without vesa mode. If the icons screen is not displayed at 1920x1080 then, try again with explicitly setting this mode in the bootmenu, without using failsafe graphics.

Hopefully one of those methods (or both) will work for you. I don't really expect that the driver itself messes up.. But I would love to hear the results from above tests from you :-)

[humdinger]

• go into the boot menu, select the same mode as is set in app_server (1024 apparantly) and continue the boot without using failsafe graphics.

That one didn't work, results in same garblement.

• boot with vesa mode, set 1920x1080, reboot without vesa mode. If the icons screen is not displayed at 1920x1080 then, try again with explicitly setting this mode in the bootmenu, without using failsafe graphics.

This one worked in the end, but I'm now a bit fuzzy how I got there...

• I did boot into VESA fail safe, and the resolution was the correct 1920x1080 already.
• I rebooted, saw all icons lighting up, but after that the screen was again garbled.
• I rebooted in VESA fail safe, and changed the resolution to 1024x768 (working display) and back again to 1920x1080 to have a ~/config/settings/kernel/driver/vesa file created.
• I rebooted and the screen was OK, ungarbled.

It still works, even after removing the 'vesa' (and Screen_data) file. I'm unable to go back to the original situation, it seems. I'm therefore not 100% sure I recalled the above totally accurately...

[rudolfc]

Thank you. You did exactly right. For some reason the vesa file only gets 'in sync' with app server by explicitly setting the mode. You could also have switched to another colordepth or refreshrate instead of 1024 mode. As long as you set a different mode than the mode you want, explicitly accept it (revert fails in various ways) and then explicitly set the target mode.

So, no regression in the driver, it works just as 'good' as before ;-)

[rudolfc]

BTW its entirely possible that if no vesa file is present, native mode is set during boot.

The logic here is also not entirely clear to me :)

I think the behaviour of haiku needs to be doublechecked in these respects someday..

[rudolfc]

Oh, same applies for the resolution fallback keyboard shortcut. Not clear (target mode logic), and revert fails likewise as with screenprefs.

[humdinger]

I just found out that (in my case) it's not actually the ~/config/settings/kernel/driver/vesa file that does the magic, but the ~/config/settings/system/app_server/workspaces file. It, too, is first created by changing resolution/depth in the Screen prefs.

So the procedure actually is simpler:

• boot into fail-safe VESA mode
• change resolution/depth, apply setting, revert to native resolution/depth
• reboot

[rudolfc]

I dont exactly know how it works in its simplest. As long as the vesa settings file contains the same resolution as app-server-settings you will be OK :)

[rudolfc]

Hello un_spacyar, madmax and humdinger,

Can you update me on the status on your computers? maybe each upload a syslog as well. Can this ticket be closed already? ;-)

Thanks!

[humdinger]

All is working well for me on a 64bit nightly hrev55711 with:

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
  vendor 8086: Intel Corporation
  device 0416: 4th Gen Core Processor Integrated Graphics Controller

Syslog syslog_humdinger_hrev55711 attached.

[madmax]

You already solved the part that affected me 6 months ago with hrev55159. Given the many changes there have been, I've updated to hrev55720 and nothing was broken.

VGA output still doesn't work for me, but it didn't before, so I can't claim any regression. And I don't use it anyway.

[rudolfc]

Thanks! Seeing un_spacyar also reported no problems anymore some six months ago, lets close this ticket. If there are problems after all, feel free to reopen it.. Bye!