#12716 closed bug (fixed)
Blurry display with intel_extreme driver
Reported by: | miqlas | Owned by: | kallisti5 |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta1 |
Component: | Drivers/Graphics/intel_extreme | Version: | R1/Development |
Keywords: | Cc: | miqlas@… | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
After the big merge from kallisti, the display went blurry. I think, the pixel clock calculation is wrong, but FIXME.
I made a screenshot before and after the update, but the blurryness is not visible on the screenshots. Tried to disable the antialiasing, but it doesn't help. Tried to delete the vesa and screen config in home/config/settings, nothing changed.
My laptop using the intel_extreme driver booth before and after the update, the intel_extreme accelerant loaded.
Hardware: Lenovo Thinkpad X200s
GPU:
device Display controller [3|80|0] vendor 8086: Intel Corporation device 2a43: Mobile 4 Series Chipset Integrated Graphics Controller device Display controller (VGA compatible controller, VGA controller) [3|0|0] vendor 8086: Intel Corporation device 2a42: Mobile 4 Series Chipset Integrated Graphics Controller
See the two attached syslog.
Attachments (9)
Change History (25)
by , 9 years ago
Attachment: | syslog_hrev50197.txt added |
---|
comment:1 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 9 years ago
For my own reference:
Before:
KERN: intel_extreme accelerant:intel_set_display_mode: hardware mode will actually be 1440x900 KERN: intel_extreme accelerant:PLL limits, min: p 10 (p1 1, p2 10), n 1, m 104 (m1 17, m2 5) KERN: intel_extreme accelerant:PLL limits, max: p 30 (p1 3, p2 10), n 4, m 138 (m1 23, m2 11) KERN: intel_extreme accelerant:compute_pll_divisors: required MHz: 106.471 KERN: intel_extreme accelerant:compute_pll_divisors: found: 106.286 MHz, p = 28 (p1 = 2, p2 = 14), n = 4, m = 124 (m1 = 23, m2 = 9)
After:
KERN: intel_extreme: SetDisplayMode: LVDS C-3 1440x900 KERN: intel_extreme: PLL limits, min: p 7 (p1 1, p2 14), n 1, m 70 (m1 8, m2 3) KERN: intel_extreme: PLL limits, max: p 98 (p1 8, p2 7), n 6, m 120 (m1 18, m2 7) KERN: intel_extreme: compute_pll_divisors: required MHz: 106.471 KERN: intel_extreme: compute_pll_divisors: found: 106.286 MHz, p = 14 (p1 = 1, p2 = 14), n = 6, m = 93 (m1 = 15, m2 = 6)
This is good data, let me take a gander this evening. The limits were changed in-line with the Linux driver... maybe I missed something. (pll calculations are scoped to limits on intel cards... and intel has random limits on every GPU :-\)
comment:3 by , 9 years ago
Don't forget this one from the new log:
93 KERN: intel_extreme: SetDisplayMode: LVDS C-3 1440x900 94 KERN: intel_extreme: PLL limits, min: p 7 (p1 1, p2 14), n 1, m 70 (m1 8, m2 3) 95 KERN: intel_extreme: PLL limits, max: p 98 (p1 8, p2 7), n 6, m 120 (m1 18, m2 7) 96 KERN: intel_extreme: compute_pll_divisors: required MHz: 126.982 97 KERN: intel_extreme: compute_pll_divisors: found: 126.857 MHz, p = 14 (p1 = 2, p2 = 7), n = 4, m = 74 (m1 = 11, m2 = 7)
comment:4 by , 9 years ago
Also the Screen preflet doesn't let to select 50Hz update frequenz however i see it in the syslog here:
KERN: Supported VESA Video Modes: KERN: Additional Video Mode (1440x900@50Hz): KERN: clock=74.8 MHz KERN: h: (1440, 1464, 1480, 1600) KERN: v: (900, 903, 909, 926) KERN: size: 26.1 cm x 16.3 cm KERN: border: 0 cm x 0 cm KERN: Additional Video Mode (1440x900@50Hz): KERN: clock=74.8 MHz KERN: h: (1440, 1464, 1480, 1600) KERN: v: (900, 903, 909, 926) KERN: size: 26.1 cm x 16.3 cm KERN: border: 0 cm x 0 cm
And there is no bootsplash at Haiku boot. I never seen it yet on this laptop yet. Maybe, because:
KERN: OEM string: Intel(r)Cantiga Graphics Chip Accelerated VGA BIOS KERN: 0x160: 768 x 480 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x161: 768 x 480 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: 0x162: 768 x 480 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x163: 960 x 600 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x164: 960 x 600 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: 0x165: 960 x 600 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x166: 1280 x 800 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x167: 1280 x 800 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: 0x168: 1280 x 800 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x169: 1440 x 900 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x16a: 1440 x 900 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: 0x16b: 1440 x 900 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x16c: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x16d: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x16e: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x16f: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x170: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x171: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x13c: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x14d: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x15c: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x13a: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x14b: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x15a: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x107: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x11a: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x11b: 0 x 0 x 0 (a = 0, mem = 0, phy = 0, p = 0, b = 0) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x105: 1024 x 768 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x117: 1024 x 768 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: 0x118: 1024 x 768 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x112: 640 x 480 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x114: 800 x 600 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: 0x115: 800 x 600 x 32 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0 KERN: 0x101: 640 x 480 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x103: 800 x 600 x 8 (a = 155, mem = 4, phy = d0000000, p = 1, b = 1) KERN: mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0 KERN: 0x111: 640 x 480 x 16 (a = 155, mem = 6, phy = d0000000, p = 1, b = 1) KERN: mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0 KERN: Using mode 0x118
Bootman shows up correctly, but not the bootsplash.
comment:5 by , 9 years ago
Tested with Fail Safe Video Mode:
- 1440x900x32: no bootsplash, desktops full with garbage
- 1440x900x16: bootsplash visible (first time!), desktop ok, no blurriness, changing to 32 bit makes garbage.
comment:6 by , 9 years ago
I'd ignore the bootsplash for now... the driver doesn't impact the resolution of the bootsplash.
by , 9 years ago
Attachment: | 0001-intel_extreme-Rewrite-PLL-calculations.patch added |
---|
Any chance you could test this patch? It's a monster and I don't have the hardware.
comment:7 by , 9 years ago
patch: | 0 → 1 |
---|
comment:8 by , 9 years ago
OFC, i can do that today afternoon / night. Thank you!
comment:9 by , 9 years ago
that should work... although the branch isn't really necessary. I tested it on my laptop, and the screen is still blurry. The pll timings should be 1:1 linux now and some special cases were added for your chipset.
If the screen is blurry still I think we can rule out pll as a cause... I disabled the panel scaler until I had base functionality. I'm wondering if the scaler is the cause.
Let me know if the code works on your card.
Thanks!
comment:10 by , 9 years ago
It booted, but the screen was full with garbage, as the horizontal sync out of order.
It is like as i tried to boot with vesa in 32 bit, maybe it doesn't even used intel_extreme at the garbage-display boot, just vesa in 32 bit. I tried to boot with vesa in 16 bit to set the color depth, but then it always booted with vesa. There is nothing about intel extreme in syslog.
comment:11 by , 9 years ago
hm.. sounds like your syslog wasn't flushed to disk. if you press ctl+alt+del release, then hold ctl+alt+delete after booting (while screen is scrambled) it can cause a safe reboot flushing the syslogs (and ensuring the log data is present on the bootmedia.
comment:12 by , 9 years ago
Blurriness sounds like a scaler issue, although it shouldn't influence the display when it's actually turned off.
comment:13 by , 9 years ago
Yeah, the scaler should be turned off... but it feels like that is the cause. (blurry is a strange problem.. generally we just get scrambled output.
I was going to reenable it once intel_extreme was 'stable/working' again...
http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/intel_extreme/Ports.cpp#n436
I'll dig into the scaler and see if I can figure it out.. not going to merge that pll rewrite patch right now since it caused a regression for miqlas (however that pll patch should make the timings more robust for more chipsets and is a lot more like what linux kms does today :-\)
comment:14 by , 9 years ago
@miqlas:
One more thought on the pll rewrite, could you try the following:
- Ensure the pll rewrite above is applied.
- find the lvds_dual_link function
- add "return false;" to the top of the function (just above the float requestedPixelClock)
Rebuild and see if that fixes it. That lvds_dual_link function is missing some cases that could apply to you. (linux does a dmi_decode as well to try and figure out the dual-link status)
comment:15 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:16 by , 9 years ago
kalisti, sorry, i was ill, that's why i wasn't able to report back. I haven't tried your changes from comment 14 yet, but i had an update to hrev50232 now. The blurriness is fixed, but not on the right way, because i don't see any correct output, just a white background with plasma like effects. (I got the same with the old driver if i tried to use the non-native resolution in screen preflet.)
I will make a shoot about it for you and attach the newest syslog. Thanks for your work!
by , 9 years ago
Attachment: | intel_extreme_output.JPG added |
---|
by , 9 years ago
Attachment: | VESA_32_bit_output.JPG added |
---|
by , 9 years ago
Attachment: | syslog.old.hrev50232txt added |
---|
by , 9 years ago
Attachment: | syslog_hrev50232.txt added |
---|
Syslog before the update