Opened 3 years ago

Closed 2 years ago

#16981 closed bug (fixed)

Intel HD driver - nightly regression

Reported by: un_spacyar Owned by: rudolfc
Priority: normal Milestone: Unscheduled
Component: Drivers/Graphics/intel_extreme/ironlake 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 (19)

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

Change History (74)

by un_spacyar, 3 years ago

Attachment: listdev_output.txt added

listdev ouput

by un_spacyar, 3 years ago

Screen Preferences hrev55102+1

by un_spacyar, 3 years ago

Attachment: ScreenOutput-2.jpg added

Screen output

comment:1 by rudolfc, 3 years 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 3 years ago by rudolfc (previous) (diff)

comment:2 by korli, 3 years ago

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

comment:3 by un_spacyar, 3 years 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 3 years ago by un_spacyar (previous) (diff)

by un_spacyar, 3 years ago

Attachment: syslog added

Syslog

comment:4 by rudolfc, 3 years 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, 3 years 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, 3 years 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, 3 years ago

Attachment: syslog_hrev55125 added

Syslog from hrev55125

comment:7 by rudolfc, 3 years 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 3 years ago by rudolfc (previous) (diff)

comment:8 by un_spacyar, 3 years 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, 3 years ago

Attachment: syslog_hrev55102+1 added

Syslog from hrev55102+1 (no issues here)

comment:9 by rudolfc, 3 years 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 3 years ago by rudolfc (previous) (diff)

comment:10 by un_spacyar, 3 years 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, 3 years 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, 3 years ago

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

comment:13 by madmax, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 3 years ago

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

by rudolfc, 3 years ago

Attachment: Intel_extreme_drv_v4.zip added

version 4 tesdriver (32 and 64bit)

comment:20 by rudolfc, 3 years 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, 3 years 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, 3 years 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, 3 years 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, 3 years ago

Attachment: syslog-panel.txt added

Test driver and no external monitor

by madmax, 3 years ago

Attachment: syslog-monitor.txt added

Test driver with external monitor

by madmax, 3 years ago

Attachment: syslog-master.txt added

Driver from master

comment:24 by madmax, 3 years 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, 3 years ago

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

by un_spacyar, 3 years ago

Attachment: syslog_intel_extreme_drv_v4 added

Syslog using the "intel_extreme_drv_V4" driver

comment:26 by rudolfc, 3 years 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, 3 years 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, 3 years 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 3 years ago by un_spacyar (previous) (diff)

by un_spacyar, 3 years ago

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

comment:29 by rudolfc, 3 years 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, 3 years 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, 3 years ago

Attachment: syslog_humdinger added

black screen: haiku-hrev1~beta3_hrev55185-1

comment:31 by rudolfc, 3 years 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, 3 years 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, 3 years ago

Attachment: syslog_hrev55168 added

working: syslog hrev55168

comment:33 by humdinger, 3 years ago

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

comment:34 by rudolfc, 3 years 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, 3 years 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, 3 years 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, 3 years ago

Attachment: syslog_working added

comment:37 by rudolfc, 3 years 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 would like to know if you have the same (or better) behaviour on your system now? Can you upload a syslog again?

Thank you!

Version 0, edited 3 years ago by rudolfc (next)

comment:38 by humdinger, 3 years 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, 3 years ago

Attachment: syslog.v6 added

comment:39 by un_spacyar, 3 years 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, 3 years 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 years 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 years ago by humdinger (previous) (diff)

by humdinger, 3 years ago

Attachment: garbled.jpg added

by humdinger, 3 years ago

Attachment: syslog.garbled added

comment:42 by humdinger, 3 years 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 years 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 years 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 years 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 years ago by rudolfc (previous) (diff)

comment:46 by rudolfc, 3 years 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 years 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 years 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 years 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 :)

comment:50 by waddlesplash, 2 years ago

Component: - GeneralDrivers/Graphics/intel_extreme

comment:51 by korli, 2 years ago

Component: Drivers/Graphics/intel_extremeDrivers/Graphics/intel_extreme/ironlake

comment:52 by rudolfc, 2 years ago

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!

comment:53 by humdinger, 2 years ago

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.

by humdinger, 2 years ago

Attachment: syslog_humdinger_hrev55711 added

comment:54 by madmax, 2 years ago

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.

comment:55 by rudolfc, 2 years ago

Resolution: fixed
Status: in-progressclosed

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!

Note: See TracTickets for help on using tickets.