Regression: intel_extreme mode setting

[jprostko]

I was interested to try the latest WPA-related changes brought in hrev42775, and upon booting this build, instead of being greeted by the desktop, a multi-colored vertical banding was shown instead. While this looked neat, I really wanted to see the desktop instead. :)

By doing a binary search, I found that the problematic revision was hrev42742. My laptop works fine with hrev42741 before the sanitization checks were put into place.

My laptop is a Lenovo X61 Tablet with a native resolution of 1400x1050 @50 Hz. It displays at this resolution just fine in Haiku hrev42741, but is seen as an invalid mode in hrev42742.

Attached are the syslog at each revision, as well as listdev and a listimage showing the drivers loaded.

If anything else is needed, please let me know.

[jprostko]

syslog from hrev42741

[jprostko]

syslog from hrev42742

[jprostko]

listdev

[jprostko]

listimage showing drivers

[jscipione]

Doomtron in IRC also noted problems with the Intel Extreme driver in hrev42751. He is seeing only a 1px high band at the top of his screen and the rest is black with the Intel Driver. Fail-safe video mode gives him 800x600 resolution only. I'll attach his listdev output.

[jscipione]

Listdev from Doomtron

[bbjimmy]

Similar issues but a black screen:

device Display controller [3|80|0]

vendor 8086: Intel Corporation device 27a6: Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller

device Display controller (VGA compatible controller, VGA controller) [3|0|0]

vendor 8086: Intel Corporation device 27ae: Mobile 945GME Express Integrated Graphics Controller

[kallisti5]

3385	KERN: intel_get_mode_info()
3386	KERN: intel_set_display_mode(1400x1050)
3387	KERN: intel_extreme: invalid mode set!intel_set_display_mode(1400x1050)
3388	KERN: intel_extreme: invalid mode set!intel_set_display_mode(640x350)

That looks to be the problem in the mode verification.

[kallisti5]

I'm thinking hrev42742 is definitely the cause. Your card is being tripped up by those new timing constraints at https://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/accelerants/intel_extreme/mode.cpp?rev=42742#L590

Would it be possible to get the mode lines for your card? (1400x1050) is what we are interested in.

Linux:
   xrandr --verbose
Windows:
   Use Powerstrip

[jprostko]

I will attach the output of xrandr --verbose to this ticket so it can be examined further.

[jprostko]

xrandr --verbose output on Lenovo X61 Tablet

[pjrinaldi]

I have an acer aspire timeline 4810tz and get the right video mode (1366x768 @ 60hz) with the intel extreme graphics 2 (GM45) in alpha3, but when i tried the latest gcc2 x86 hybrid nightly 42795, i got a black screen with intel and had to use fail safe to get 1024x768. I am hopefully including the files I have access to that were mentioned in the submitting patches section. Hopefully this information is useful in resolving the issue.

[pjrinaldi]

listdev file from my computer

[axeld]

Even if the timing is supposed to be invalid (more debug output would possibly explain the problem), it would be interesting if the app_server actually calls propose_mode() before setting the mode, as this should more or less 'repair' it. Maybe the propose_mode() implementation is still to simplistic, though.

[tidux]

I can confirm this on the Atom N450 (GMA 3150) with @hrev42801. Booting normally, the stretched-out splash screen displays normally, then the "desktop" is show as a single row of pixels going across the top of the monitor. Using VESA fallback 800x600x32, the desktop displays normally.

[jprostko]

Axel, I see what you're saying. This weekend I'll try to add some TRACEs to the code in various places to try to glean more information about the situation. I admit when first filing the ticket I didn't really dig into the code much, but now I have some ideas about things to look into further. If I figure anything out, I will post back with my findings.

[axeld]

Replying to jprostko:

This weekend I'll try to add some TRACEs to the code in various places to try to glean more information about the situation.

Great, this is very appreciated -- I would have liked to do that, too, but found absolutely no time in the past days. It would also be very interesting where the app_server got the wrong resolution from. And finally, what causes something entirely weird to be set. IOW you might identify three distinct bugs that lead to this situation :-)

[kallisti5]

better tracing added to modeline sanitization in hrev42823, disabled by default however.

[jprostko]

Okay, I ran hrev42825 with the additional tracing brought in with hrev42823 enabled. I'll attach the full syslog, but here are the relevant lines which were brought in by the tracing.

KERN: accelerant common: sanitize_display_mode: h_display(60140) > max_h_display(8192)
KERN: accelerant common: sanitize_display_mode: v_display(17266) > max_v_display(4096)
KERN: accelerant common: sanitize_timing: syncStart(32766) > max_sync_start(8160)
KERN: accelerant common: sanitize_timing: syncLength(51764) > max_sync_length(504)
KERN: accelerant common: sanitize_timing: total(32766) > max_total(8192)
KERN: accelerant common: sanitize_timing: syncStart(89) < display(4096) + min_before_sync(1)
KERN: accelerant common: sanitize_timing: syncLength(56647) > max_sync_length(63)
KERN: accelerant common: sanitize_timing: total(6146) > max_total(4096)

[jprostko]

syslog from hrev42825 of Lenovo X61 with additional tracing from hrev42823 enabled

[pjrinaldi]

listdev for hrev42795

[pjrinaldi]

syslog my alpha3

[pjrinaldi]

syslog for my hrev42795

[pjrinaldi]

Not sure if the information will help, but I added my listdev and syslog from alpha3 and hrev42795. let me know if there's anything else i can provide to help resolve this issue.

[kallisti5]

Confirmed the same black screen bug on my Aspire ZG5 which has a Intel 945GSE.

This seems to effect all Intel video devices, as such I am bumping the priority to high.

[axeld]

Bumping the priority is fine, but there are chipsets that still work fine - like the one I've tested this with, or mmlr's, obviously :-)

I'll see if I can make some time to test on another machine (I actually have two other systems with Intel chipsets), but I can't promise anything.

[mmlr]

I'm currently reworking some of the intel_extreme internals (to better separate the various components of the display "chain"). I have already looked over the constraints put in place and they do seem off for quite a few configurations. I wasn't experiencing any black screens, but I can't select a few modes that worked fine before anymore on pretty much all of the systems with intel graphics (I actually got 5, tested only on 4 of them though).

What definitely happend on this laptop (Thinkpad X1) was that the mode retrieved from the panel was later not seen as valid (due to the resolution being 1366x768 where 1366 didn't comply to the 8 resolution granularity constraint). What I've seen pretty consistently so far is that setting modes with 60Hz does not work anymore, unless it is the exactly matching EDID mode. This is problematic in my case because the EDID mode suggests 59Hz which we do simply not offer (the Screen prefs starts at 60Hz). 70Hz or anything up does work however.

So what I could imagine (without really remembering the code flow in the app_server) is that on the affected systems, it was tried to set a mode (with 60Hz probably), that failed, as did the fallback to the "native" mode retrieved, resulting in a black screen.

I would have just adjusted the constraints, but even though I have a lot of different intel graphics hardware, I honestly don't know what to put there. In any case I will take ownership of this and fix it either separately or as part of reworking the driver.

[streak]

Just for information. Pre-3 release was working on my MSI Wind laptop [extreme graphics] but since alpha3 and later builds extreme graphics not work. I cant boot it up using extreme graphics driver [im forced to use fail-safe 800x600 resolution]

[jalopeura]

I was having a similar problem. I tracked the problem down to the resolution granularity used when rounding (as mentioned above in mmlr's comment). Here are the relevant lines from xrandr --verbose:

  1024x600 (0x43)   51.0MHz -HSync -VSync *current +preferred
        h: width  1024 start 1117 end 1152 total 1250 skew    0 clock   40.8KHz
        v: height  600 start  601 end  606 total  680           clock   60.0Hz

As you can see, the start value is 1117. As you may be aware, 1117 is a prime, so there are only two possible granularities which would not result in the value being changed when rounded. Since 1117 would not work with the other values above, I elected to go with 1. It fixed the problem, and now Haiku works on my N10 chip.

Since my solution involves simply replacing an '8' with a '1', I have not bothered to attached a patch. (If anyone really wants one, I'd be happy to generate one and attach it.)

[pulkomandy]

Please test hrev43235.

[jalopeura]

I tested it, but it doesn't work on my hardware. It reverted to the old behavior of a one-pixel line across the top of the screen.

I had to change the horizontal resolution back to 1 again to get it to work for me.

[humdinger]

FWIW, my Samsung NC10 with i945 graphics does boot again without having to enter safe mode.

[pjrinaldi]

i just updated my install to nightly build hrev43238 and my acer aspire timeline 4810tz (1366x768 @ 60hz) with the intel extreme graphics 2 (GM45) is now showing the correct video mode again. Let me know if there is any hardware output you need for comparison to help resolve this bug for everyone.

[jprostko]

I'm a bit late to the show, but as an FYI, I tried hrev43299 on my X61 system with i965GM, and it booted just fine due to pulkomandy's fix in hrev43235. That said, Michael will likely fix this in a different way when he reworks the driver, especially since the current fix doesn't help people like jalopeura and likely plenty of others. I'm not sure if using the '1' fix that jalopeura suggested would work system-wide or not without any issues, but at least his solution gives further information of how to reach an ultimate solution to the problem.

[pulkomandy]

Its not some random magic number :) This number is involved in rounding the horizontal resolution to match what is allowed by the video card.

From intel documentation, the G35 family only allowed even pixel counts, and later they changed it to allow anything. So, setting it to 1 may break things for G35 family chips owner.

On the other hand, some modern cards seems to use an odd mode in their mode description (or after computing of a mode by the GTF). In this case the mode is rounded to match the constraint, and the result is not a valid mode anymore, or not what's expected. The solution is to set the constraints matching the card family.

[bbjimmy]

Still shows a black screen on my eeepc

hrev43324

intel Mobile 945GME Express integrated Graphice Controller

works fine when I use the intel extreme driver and accelerant from r1a3

[anevilyak]

(In #8229) Indeed.

[Cypress]

Confirming the black screen symptom on a Dell Inspiron Mini 10 (1018) Netbook with integrated Intel GMA 3150 graphics.

[Cypress]

Update: hrev43540 seems to have fixed the issue on the aforementioned machine.

[tidux]

Not fixed for everyone: hrev43540 does not fix the issue on an Eee PC 1005PEB with GMA3150/N10 graphics.

[izomiac]

hrev43540 doesn't seem to have made a difference on my 4500MHD. Still a black screen with a bright half row of pixels in the upper left corner that changes with mouse movement.

[christof]

I am experiencing a similar problem on my eeepc 901 with hrev43563. After the startup icons have been shown, a strange visual effect occurs: a white fuzzy "cloud" appear in the center of the screen and everything slowly fades to black. After that, the screen stays black.

Similar to the descriptions in the comments above, older Haiku versions worked just fine. Would it maybe be a good idea to move the current version of the intel_extreme driver into an experimental branch and have the more stable old version in the trunk instead? Thanks.

[streak]

The same symptoms [like christof] on MSI Wind U100 / Advent 4211B.

Since pre-Alpha3 my all laptops stopped working because of changes in extreme graphics. Its more than a year, guys. Move on or revert changes or you'll lose a lot of new users / and old ones [me..]

[streak]

Could somebody extract the driver from pre-alpha3 and prvide it in here?

[AlienSoldier]

I updated my USB stick to hrev43692 today and it was still black desktop. I then did the trick of using an older intel_extreme driver as it worked before but now it goes directly to VESA as if the system does not recognize the old driver anymore. I double checked if everything was right (Accelerent and driver in the right place with the symlink) ,

This is on my aspire one netbook. Another long lasting problem is that it does not shutdown (screen stay blue and i have to press power).

[czeidler]

Whats about to first check for the modes in the mode list, like has been done before hrev42742 and if this does not work use a more general approach? This should at least make the driver usable again for many people.

--- a/src/add-ons/accelerants/intel_extreme/mode.cpp
+++ b/src/add-ons/accelerants/intel_extreme/mode.cpp
@@ -645,6 +645,22 @@ intel_propose_display_mode(display_mode* target, const display_mode* low,
 {
        TRACE(("intel_propose_display_mode()\n"));
 
+       // just search for the specified mode in the list
+
+       for (uint32 i = 0; i < gInfo->shared_info->mode_count; i++) {
+               display_mode *mode = &gInfo->mode_list[i];
+
+               // TODO: improve this, ie. adapt pixel clock to allowed values!!!
+
+               if (target->virtual_width != mode->virtual_width
+                       || target->virtual_height != mode->virtual_height
+                       || target->space != mode->space)
+                       continue;
+
+               *target = *mode;
+               return B_OK;
+       }
+
        sanitize_display_mode(*target);
 
        return is_display_mode_within_bounds(*target, *low, *high)

[axeld]

I wouldn't mind to put that back into place temporarily (with a comment as such), but it's just a work around, not a solution. hrev42742 is not an accident, but the right way to go, just the constraints seems to be wrong.

[mmlr]

A simpler way may be to drop the constraint to 1 at least until the proper limit can be figured out. The limits are card/generation as well as connection type specific, so a single set of constraints won't do anyway. Making the preciously tuned constraint a 1 should basically allow the same situation as before.

[czeidler]

But isn't that dangerous if the incoming mode is totally screwed up?

[czeidler]

After giving it another thought I have no clue about the constraints so I committed the workaround in hrev43708. This one is at least tested on one machine.

[AlienSoldier]

The workaround is working for me on my Acer aspire one.

Some things i noticed. The native resolution is not detected, i was expecting 1024x600 at 60hz but it first appeared at 640x 350 at 70 hz according to the pref panel. 1024x600 at 60hz say invalid mode. 1024x600 at 70 hz work fine.

[tidux]

The bug is not fixed for me on my Eee PC 1005PE (N10 graphics) in hrev43708. I still get the one-pixel-high desktop.

[czeidler]

Hi tidux, did the driver ever worked for you? Could you give me the mode line for your monitor? I could add it to the mode list (another workaround)

[tidux]

output of xrandr under Debian Sid with Linux 3.2 on Eee PC 1005PE

[jahaiku]

Up to now my AOA150 only showed a black screen. With this Version my AOA150 shows only the second half of the haiku desk on the left screen and from the middle of the screen it is black.

[czeidler]

@tidux this resolution is already in the list so this is not the problem...

[tidux]

@czeidler I'm stumped, then. I'm still getting that one-pixel-high desktop, with the rest of the screen stuck on the bootsplash.

[tidux]

I finally got wifi working under Haiku on this accursed netbook, so I'm going to submit my listdev output (listdev.out) and syslog for a fresh boot on hrev43739. I think the issue might be that it's not really a 60Hz resolution, but the driver in the Linux kernel lies to xrandr.

[tidux]

output of "listdev" on Eee PC 1005PE

[pulkomandy]

Another attempt in hrev43820 :

• Chipsets up to G35 get a constraint of 2,
• Anything newer gets a constraint of 1.

This should be working for all supported cards, please report.

[tidux]

At long last, the driver works on my Eee PC 1005PE. Thank you guys so much.

[diver]

I get black screen on my 945G/GZ after hrev43820. Please revert.

[diver]

It turns out that my build system produces a semi-working kernel_x86 binary. If I change Fail-safe video mode to 1024x768 then it works. And if I replace my kernel_x86 with the one from nightly image I don't have to mess around with Fail-safe video mode at all. Sorry for the noise.

[czeidler]

Interesting, I had similar problems with my nvidia card. I was able to boot with 16bit but the default resolution with 32bit gave just a black screen. Think this is still a vesa problem? After some random kernel changes this problem disappeared a while ago for me...

[diver]

I was able to boot with my default resolution 1280x1024 but @16bit too. 1280x1024@32 gives me a black screen.

[diver]

FYI, after installing correct jam version and rebuilding haiku this problem disappeared.

[bbjimmy]

my eeepc 900HA comes up with the wrong resolution, 640 * 480 * 8bits, but I can set the proper 1024 * 600* 32bit and it seems to work ok.

[izomiac]

Still present in Alpha 4.1. Intel 4500 MHD with a 1600x900 screen. The splashscreen never goes away and I see a box ~800 pixels wide by ~3 pixels tall with colors and movement suggestive of being a compressed version of the desktop.

Sorry for necroing this bug, but I haven't been following the project very closely since my work-around for this bug stopped working. (I used to use a pre Alpha 1 intel_extreme driver that mostly worked, albeit with some color distortion. Haiku stopped booting with that driver some time back.)

[diver]

Please see #9157.

[jua]

I'm still having problems with the driver due to the resolution constraints, using hrev45353. Reporting it here and not in #9157 because I don't see the "1 pixel height desktop", it just comes up with a black screen after the boot screen.

The hardware is an Asus Eee 1002HA netbook with Intel 945GME graphics.

EDID reports the main mode as (taken from syslog):

KERN: Additional Video Mode (1024x600@60Hz):
KERN: clock=45 MHz
KERN: h: (1024, 1077, 1112, 1200)
KERN: v: (600, 604, 609, 625)
KERN: size: 22 cm x 12.9 cm
KERN: border: 0 cm x 0 cm

i.e. syncStart is 1077. Since the graphics chip is 945GME, it gets the "oldCard" flag set in mode.cpp:sanitize_display_mode() and thus horizontal timing resolution is set to 2. This causes sanitize_timing() to change it to 1076 in its rounding of syncStart (it's the only change the sanitize functions do, all other constraints are met) and then intel_set_display_mode() rejects it because of that.

If I comment out the rounding so it just uses syncStart=1077 anyway, the accelerant works, I get a picture at proper resolution, so it seems that resolution=2 is not necessary for my hardware (or is it just luck...?). Same if I let it round to 1076 but edit intel_set_display_mode() in such a way that it doesn't care when sanitize changes the mode -- that works as well. No idea if any of that is "dangerous" though, so I don't recommend it...

I can live with that little workaround; however if I can supply any further info to help finding a proper fix, let me know.

[axeld]

The PLL is not being used for the laptop display; you probably can insert any value in there, and it should still work. It's not yet a proof that this works for VGA output, too.

In any case, EDID comes from the monitor, not the chipset, and the monitor cannot know of restrictions that apply to the chipset. The driver needs to sanitize all resolutions before adding them to the list. I'll provide a patch later today that should fix this.