My thinkpad x201 has a blackscreen. did work before

[modeenf]

Black screen on latest hrev. Did test hrev55114 and that one worked (giving me a desctop etc).

I will pinpoint the one that brake it.

[bruno]

Would be better with syslog?

[modeenf]

So far.

ok
hrev55114-x86_64
hrev55161-x86_64
hrev55176-x86_64
hrev55185-x86_64
hrev55207-x86_64
hrev55449-x86_64

not ok
hrev55459-x86_64
hrev55464-x86_64
hrev55489-x86_64

So it's ether of these. hrev55454 or hrev55451. Didn't hade any Nightly for these.

​https://git.haiku-os.org/haiku/commit/src/add-ons/accelerants/intel_extreme?id=fe8f9e23261ba5e7748db1dde6c6d74aa751da36

or ​https://git.haiku-os.org/haiku/commit/src/add-ons/accelerants/intel_extreme?id=1681f7f4fe3f98fbea47faac40db07dc3b5bc28a

Should I send in a syslog as well?

[modeenf]

Replying to bruno:

Would be better with syslog?

That to, Rudolf suggested pinpoint the hrev that broke it.

​https://discuss.haiku-os.org/t/improving-the-intel-extreme-driver-was-graphics-on-dell-laptop-in-vesa-mode-only/10583/297?u=modeenf

[rudolfc]

ModeenF, yes, please.. Upload a syslog here that shows the intel_extreme driver trying to control the card to start with.. maybe one where it was OK, and one where it failed?

[rudolfc]

Looking at both files it seems the refreshrate is set at 113% when it's working, compared to when it's not working. So maybe if the refresh is 60 when it's OK, it's 53-ish when it's not OK. Strange that this is not the same on both logs. Maybe you could try on the working version: look at the reported refresh in screenprefs there (let me know here) and also test what happens if you lower it by approx this amount: no screen?

EDIT: Hmm,

Your screen reports two 'additional modes' (native):

KERN: Additional Video Mode (1280x800@60Hz): KERN: clock=68.940000 MHz KERN: h: (1280, 1296, 1344, 1408) KERN: v: (800, 801, 804, 816)

KERN: Additional Video Mode (1280x800@49Hz): KERN: clock=60.960000 MHz KERN: h: (1280, 1328, 1360, 1478) KERN: v: (800, 803, 809, 825)

Seems the first one works on your system and is selected in the working log, the second one is selected on the other syslog. the dotclocks are exactly 113% different.

I don't know why another mode is selected, but looks like this is a good pointer to the problem. I'll try to locate it..

[rudolfc]

OK, The trouble is that the 60Hz mode should be selected, but comes later in the generated modelist I think. Since now SetMode calls ProposeMode, which iterates over this list, where before ProposeMode was (incorrectly) not called by SetMode, this problem is introduced.

ProposeMode needs to be expanded to check the refreshrate and with that come up with the really requested (closer) mode. That would solve it, though if all would be perfect, even other modes would be handled correctly.

I have another few questions:

• What happens if you change refreshrate lower, higher, on the working hrefs?
• What happens if you change resolution?

Would these changes result in a working screen? Always? Or only some? If so, where are the limits so to speak?

Thanks!

[modeenf]

I didn't test all combination

Working
60 hz, 32 bits 1280*800
60 hz, 16 bits 1280*800
60 hz, 8 bits 1280*800
60 hz, 32 bits 1024*768
60 hz, 32 bits 640*350

Not working (black screen)
70-85 hz, 32 bits 1280*800
didn't test other resolutons. Can do that but I guess it will be the same ;)

Works but with top of the screen dissorted
60 hz, 32 bits 1680*1050 and above

[rudolfc]

Thanks! Can you also try below 60 Hz?

[modeenf]

That was the lowest I could choose in the dropdown or in the custom view.

[rudolfc]

Hmm. No slider in prefs then for the refresh?

[modeenf]

When I choose custom the slider shows 60 to 85.

[smashIt]

I have the same problem on my Thinkpad T420 (intel HD 3000 GPU) after upgrading to hrev55507 x86_64.

[rudolfc]

Hi, I'll update proposemode for this asap and get back to you. Thanks!

[rudolfc]

Please try hrev55513, to see what happens. The refreshrate is preserved now in proposemode, which is not yet enough from the looks of it here. Anyhow it should improve the situation already (somewhat).

I'll puzzle a bit more here before I make another commit. Anyhow, I'm curious if you have a picture again..

[rudolfc]

OK, got more info now. I expect hrev55513 is a good candidate to give you both your screen back so to speak.

I was testing some hrevs since I saw an unexpected effect on Generation4 (G45) over here: the refreshrate (after the above commit, but also on hrevs before I started working on BWindowScreen, so where proposemode did not yet come into play with setmode) deviates a lot if I set 1280x1024x70Hz: with the old version it sets 76Hz, with the latest commit it's 64Hz. Both about the same error. The reason for the deviation is limits in the PLL hardware so it looks like that can't be helped (easily).

The reason it was 76Hz, and it's now 64Hz, is because via setmode calling proposemode with just visible size check, along with refresh, another modeline is still choosen.

The better way of choosing the modeline would probably be to look at which mode's defaults come closest to the refreshrate setmode wants to set, so I might still look at that, depending on your results. (please let me know)

Of course the PLL hardware restrictions remain, so with either mode there's a big refreshrate deviation. This does not apply for lower modes on G45, tested 640x480, 800x600 and 1024x768 in range 60-75Hz: all OK. 1280x1024 in 60Hz is OK too btw.

I just doublechecked IvyBridge and the deviation does not happen there: more modern card with more options in the PLL's, thankfully.

OK, that's it for now. Hopefully the nightlies will be up soon so you can easily check if it's OK again with hrev55513 or later..

[rudolfc]

Another update: I'll be updating the PLL limits code as well, since it's wrong. I thought it would be stupid the PLL couldn't handle refreshrates better, and I was right. Just removed some limits as a bold test and voila, perfect set refreshrates :-) Anyhow, Going to sync against Intel i915 Linux drm driver for this now and see what happens..

[modeenf]

Can't wait to test all the changes. Checks the nightly builds daily. But still stuck at 55507..

[rudolfc]

Are you on 32 or 64bit? Maybe I can post the driver here, you'd have to place it in the user unpackaged hierarchy to use it, that seems to work OK again at least in hrev55464 (tested x64 which accepts the user hierarchy for this again)

[modeenf]

That would be nice. 64 bits. Yes I know. Even have built my own drivers before but right now my Haiku sourscode are not update.

[rudolfc]

Will do. G45 works OK with the i915 PLL limits I just saw. Nice :-) I'll complete this doublecheck/update and compile a driver for you, hopefully within a few hours.

[rudolfc]

Updated PLL limits and updated setmode/proposemode to behave as I think should be as intended. PLL mods partly from DRM i915, partly from own guesses with tests for G45 (all resolutions and all refreshrates now OK there)

[rudolfc]

Hi again, please test this version and let me know what happens.. :-) Also upload a syslog if possible..

[modeenf]

nice. with the new driver it now works the same as in hrev55449-x86_64. only shows 60-85 hz.

[modeenf]

hrev55507 with new driver

[rudolfc]

Would for instance 1024*768 @ 70 Hz work for you? or is it literally the same as with the list you posted here on the old revs?

At least a difference between then and now should be that BWindowScreen works properly with panning/scrolling support, and so also cloning the accelerant is OK.

[rudolfc]

Just built a system with Intel Skylake (Generation 9 gfx), HD 530 (Id 0x1912). I'll probably do a intel_extreme driver test with it to see what happens. At this time the ID is not in the driver, so I'm running 'framebuffer' on Haiku x64. :-)

[modeenf]

Nice, 1024*768 @ 70 Hz up to 85hz.

but when setting 1024*768 @ 85 Hz and then tryed 1280*800 @ 85hz the screen went black and stayd black more than those 15 second. So I had to force a reboot but was 1024*768 @ 85hz after the reboot.

Nice have a laptop with both 520 and 620

[modeenf]

I thought I hade generation 10 but apparently no generation 10 was released. HD 6xx are generation 9.5 and after that it's generation 11.

So if you need some testing ;)
This is what I have. My systems that has 620, 530 and 520 are not working that great with Haiku, don't know why, can be that I'm only booting through USB..

UHD Graphics 620 (Gen 9.5), Laptop screen, 1 HDMI
HD Graphics 530 (Gen 9), Desktop. 2 DP and 1 VGA, same id as yours
HD Graphics 520 (Gen 9), Laptop screen, 1 DP
HD Graphics 4000 (Gen 7), nuc, only 1 VGA
HD Graphics 4000 (Gen 7), Laptop screen, 1 VGA, 1 HDMI
HD Graphics (Gen 5), Laptop screen, VGA
GMA 3150 (Atom N4xx), Laptop screen, VGA

[smashIt]

With hrev55541 it works again. Thanks :)

[rudolfc]

Nice all those systems! And nice it works again for both of you. I'll close this ticket then. @modeenf: if 1024*768 @ 70Hz works for you, you could try my BWindowScreen command line test app to see it indeed works (it sets 1024x768, which is 60Hz via BWindowScreen, then it sets 1024*768 @ 70Hz via BScreen for that class (a trick), which also is a virtual mode. Then it will draw a vertical single yellow line in top mid of your screen, and then it will pan that line with hardware 'acceleration' (pointer updates via X,Y set) smoothly to left and back to right.

This app failed before, now it fully succeeds at the exact same way it did when I wrote it On R5.0.3 and Dan0.

It can be found on my homepage (rudolfs-place.nl): it's in the technical info page at the drivers. It was originally written for the MAtrox driver. So it will initially offer you a lot of other special modes (tv, dualhead stretch: left: yellow line, right: blue line) which will block on all drivers except nvidia and matrox.

For 64bit you need to recompile that app first, it's 32bit.

Thanks for your help with this bug, all!