Opened 8 weeks ago

Last modified 3 weeks ago

#16981 in-progress bug

Intel HD driver - nightly regression

Reported by: un_spacyar Owned by: rudolfc
Priority: normal Milestone: Unscheduled
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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

Attachments (18)

listdev_output.txt (1.9 KB ) - added by un_spacyar 8 weeks ago.
listdev ouput
ScreenPreferences_hrev55102.png (24.2 KB ) - added by un_spacyar 8 weeks ago.
Screen Preferences hrev55102+1
ScreenOutput-2.jpg (313.3 KB ) - added by un_spacyar 8 weeks ago.
Screen output
syslog (349.9 KB ) - added by un_spacyar 8 weeks ago.
Syslog
syslog_hrev55125 (350.3 KB ) - added by un_spacyar 8 weeks ago.
Syslog from hrev55125
syslog_hrev55102+1 (233.5 KB ) - added by un_spacyar 8 weeks ago.
Syslog from hrev55102+1 (no issues here)
Intel_extreme_drv_v4.zip (137.0 KB ) - added by rudolfc 7 weeks ago.
version 4 tesdriver (32 and 64bit)
syslog-panel.txt (344.8 KB ) - added by madmax 7 weeks ago.
Test driver and no external monitor
syslog-monitor.txt (247.4 KB ) - added by madmax 7 weeks ago.
Test driver with external monitor
syslog-master.txt (273.0 KB ) - added by madmax 7 weeks ago.
Driver from master
syslog_intel_extreme_drv_v4 (180.0 KB ) - added by un_spacyar 7 weeks ago.
Syslog using the "intel_extreme_drv_V4" driver
syslog_hrev55168_driverOK-No_Issues_Found (179.9 KB ) - added by un_spacyar 5 weeks ago.
Syslog from hrev55168 - everything works well - no issues found.
syslog_humdinger (229.7 KB ) - added by humdinger 5 weeks ago.
black screen: haiku-hrev1~beta3_hrev55185-1
syslog_hrev55168 (274.0 KB ) - added by humdinger 5 weeks ago.
working: syslog hrev55168
syslog_working (316.2 KB ) - added by humdinger 5 weeks ago.
syslog.v6 (260.5 KB ) - added by humdinger 4 weeks ago.
garbled.jpg (581.8 KB ) - added by humdinger 3 weeks ago.
syslog.garbled (214.6 KB ) - added by humdinger 3 weeks ago.

Change History (67)

by un_spacyar, 8 weeks ago

Attachment: listdev_output.txt added

listdev ouput

by un_spacyar, 8 weeks ago

Screen Preferences hrev55102+1

by un_spacyar, 8 weeks ago

Attachment: ScreenOutput-2.jpg added

Screen output

comment:1 by rudolfc, 8 weeks ago

Owner: changed from nobody to rudolfc
Status: newin-progress

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.

Last edited 8 weeks ago by rudolfc (previous) (diff)

comment:2 by korli, 8 weeks ago

Summary: Intel HD driver - regressionIntel HD driver - nightly regression
Version: R1/beta2R1/Development

comment:3 by un_spacyar, 8 weeks ago

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.

Last edited 8 weeks ago by un_spacyar (previous) (diff)

by un_spacyar, 8 weeks ago

Attachment: syslog added

Syslog

comment:4 by rudolfc, 8 weeks ago

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?

comment:5 by rudolfc, 8 weeks ago

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?

comment:6 by un_spacyar, 8 weeks ago

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).

by un_spacyar, 8 weeks ago

Attachment: syslog_hrev55125 added

Syslog from hrev55125

comment:7 by rudolfc, 8 weeks ago

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..

Would a 32bit version be useable for you for a test?

Last edited 8 weeks ago by rudolfc (previous) (diff)

comment:8 by un_spacyar, 8 weeks ago

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).

by un_spacyar, 8 weeks ago

Attachment: syslog_hrev55102+1 added

Syslog from hrev55102+1 (no issues here)

comment:9 by rudolfc, 8 weeks ago

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 ;-)

Last edited 8 weeks ago by rudolfc (previous) (diff)

comment:10 by un_spacyar, 8 weeks ago

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

comment:11 by rudolfc, 8 weeks ago

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.

comment:12 by rudolfc, 8 weeks ago

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

comment:13 by madmax, 8 weeks ago

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.

comment:14 by rudolfc, 8 weeks ago

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 :-)

comment:15 by rudolfc, 8 weeks ago

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!

comment:16 by madmax, 8 weeks ago

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.

comment:17 by un_spacyar, 8 weeks ago

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!

comment:18 by rudolfc, 8 weeks ago

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!

comment:19 by un_spacyar, 7 weeks ago

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

by rudolfc, 7 weeks ago

Attachment: Intel_extreme_drv_v4.zip added

version 4 tesdriver (32 and 64bit)

comment:20 by rudolfc, 7 weeks ago

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 :-)

comment:21 by un_spacyar, 7 weeks ago

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).

comment:22 by rudolfc, 7 weeks ago

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.

comment:23 by rudolfc, 7 weeks ago

@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?)

by madmax, 7 weeks ago

Attachment: syslog-panel.txt added

Test driver and no external monitor

by madmax, 7 weeks ago

Attachment: syslog-monitor.txt added

Test driver with external monitor

by madmax, 7 weeks ago

Attachment: syslog-master.txt added

Driver from master

comment:24 by madmax, 7 weeks ago

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.

comment:25 by un_spacyar, 7 weeks ago

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

by un_spacyar, 7 weeks ago

Attachment: syslog_intel_extreme_drv_v4 added

Syslog using the "intel_extreme_drv_V4" driver

comment:26 by rudolfc, 6 weeks ago

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!

comment:27 by madmax, 6 weeks ago

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.

comment:28 by un_spacyar, 5 weeks ago

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!!!!

Last edited 5 weeks ago by un_spacyar (previous) (diff)

by un_spacyar, 5 weeks ago

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

comment:29 by rudolfc, 5 weeks ago

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 :)

comment:30 by humdinger, 5 weeks ago

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".

by humdinger, 5 weeks ago

Attachment: syslog_humdinger added

black screen: haiku-hrev1~beta3_hrev55185-1

comment:31 by rudolfc, 5 weeks ago

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

comment:32 by rudolfc, 5 weeks ago

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..

by humdinger, 5 weeks ago

Attachment: syslog_hrev55168 added

working: syslog hrev55168

comment:33 by humdinger, 5 weeks ago

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

comment:34 by rudolfc, 5 weeks ago

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!

comment:35 by rudolfc, 5 weeks ago

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!

comment:36 by humdinger, 5 weeks ago

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.

by humdinger, 5 weeks ago

Attachment: syslog_working added

comment:37 by rudolfc, 4 weeks ago

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!

Last edited 4 weeks ago by rudolfc (previous) (diff)

comment:38 by humdinger, 4 weeks ago

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.

by humdinger, 4 weeks ago

Attachment: syslog.v6 added

comment:39 by un_spacyar, 4 weeks ago

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!!

comment:40 by rudolfc, 4 weeks ago

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!

comment:41 by humdinger, 3 weeks ago

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.

Last edited 3 weeks ago by humdinger (previous) (diff)

by humdinger, 3 weeks ago

Attachment: garbled.jpg added

by humdinger, 3 weeks ago

Attachment: syslog.garbled added

comment:42 by humdinger, 3 weeks ago

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?

comment:43 by rudolfc, 3 weeks ago

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 :-)

comment:44 by humdinger, 3 weeks ago

  • 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...

comment:45 by rudolfc, 3 weeks ago

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 ;-)

Last edited 3 weeks ago by rudolfc (previous) (diff)

comment:46 by rudolfc, 3 weeks ago

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..

comment:47 by rudolfc, 3 weeks ago

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

comment:48 by humdinger, 3 weeks ago

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

comment:49 by rudolfc, 3 weeks ago

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 :)

Note: See TracTickets for help on using tickets.