Improving the Intel Extreme Driver (Was: Graphics on Dell laptop in Vesa mode only)

Feedback Hardware
82

Thank you for your detailed report! This is indeed the behaviour I would expect from hrev55117. In order to get refreshrate changes working you need M/N pipe programming added.

For nearby resolutions also the panelfitter needs to be working, but this will get you not all yet: for that the north/south bridge reconfiguring is needed which doesn’t work yet.

Also it may be that gen5, just like gen6 differs a bit when compared to gen7 which means something else additional is needed as well: if this is indeed the case that will be a challenge without having access to the actual systems…

83

Thanks! Yes, I remember. However it should be much better organized yet, and the extra or other translation was not made by me, but by other persons who might have introduced errors. I think the word-list at the end of the doc is nice already though (I will at some point check it once more anyway).

1 Like
84

Hi, Status Update and a question…

  • HDMI is up and running like analog port. I can set depth, refresh, resolution with the limitations imposed because I cannot yet program the north-south link. I have one more thingy to nail and then I think I should be able to create a new testversion

Interesting thing I just saw:

  • On my Iiyama monitor, the EDID info for analog connection shows max pixelclock of 180Mhz. At 60Hz we have with the default modeline style in the common code approx 172.5Mhz, so this will work on my screen. Though it reports (via its ‘native modeline’ that it would rather see 148Mhz instead, That would give me room to set a higher refreshrate than is now possible. Now max is 62.0Hz.
  • The same monitor reports via EDID it can do 170Mhz via the DVI/HDMI link(!). This poses a problem with our default modeline: when the system boots for the first time it will try 1920x1080x60Hz, but that is outside these limits. Max possible (and working OK) is approx. 58Hz… That’s not so nice. Were we to use the ‘native modeline’ this problem would not exist.

Seems like indeed the driver should replace the default modeline with the full one from the attached screen, would be better. Of course if we adress two screens at the same time, well, such a line might be to ‘tight’ for the second screen. (On nVidia driver I just block all modes above the highest ‘common’ mode so to speak).

Interesting, no?

Then, another thing I noticed:

  • Currently I have the driver setup to set the clock and such on the DVI connection so that the screen works the same way as in analog mode. On lowres modes, this mode is ‘directly’ sent to the screen. The other method I see is being used in Windows, and also in my Ivy’s BIOS: these -always- set the native modeline for the DVI connection, and if you select a lower resolution for output: it’s just translated in the card to the native resolution.

Upside is when you set a non-widescreen mode on a widescreen monitor you will get correct aspect ratio (so left and right a vertical black bar), while ‘my’ way just stretches the screen.

Downside is that if you want another refreshrate than the link’s 60Hz, well, that cannot be done. And this is how it works as said in Windows (7 tested) and the BIOS…

Of course the driver currently does not think about aspect ratios, so for the second way of working that would have to be added at some point for the same behaviour as on Windows and the BIOS.

So, I’m curious: which route should we take? And while I’m asking, anything on anybody’s mind seeing this story? (For now I’ll just take the easiest route anyway I think, but I have yet to find out what that is :wink: Of course that can be changed later on, by anyone :slight_smile: )

7 Likes
86

I have i5-8400 Intel UHD 630. Need a test on that one?

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
vendor 8086: Intel Corporation
device 3e92: UHD Graphics 630 (Desktop)

64 bit Haiku

87

I’d go the same route as Windows, seems safer, and probably what most people compare with.

And a very very low prio wish: that we can go from boot to full desktop without screen blinking if mode been setup correctly by firmware.

88

I have problems with both solutions, of course :stuck_out_tongue:

Being forced to 60Hz is not so nice in some cases. For example one of my projects is writing an emulator for Amstrad/Schneider CPC computers, and in this case, I would like to set a very specific refresh rate (50.02Hz) to have the display be exactly synchronized with the emulator.

On the other hand, keeping the native resolution on the output means faster mode switches, and it becomes more reasonable to use different video modes in different workspaces. With the current driver it is very slow.

Yes, old Intel devices were a lot simpler, but the modern ones have become a lot more complex. From what I understand, the approach used by modern AMD cards makes it a bit easier in that area, because they perform a lot of the work in AtomBIOS. The idea is that they have some bytecode in the card ROM and provide a specification for the virtual machine needed to run it. Then, we just implement that VM, and ask the card to perform the low-level things. And when a new card comes, they can just change the content of the ROM and we don’t need as much changes to the driver.

1 Like
89

Thank you all for your thoughts, I’ll keep it in mind. Though it seems somewhat incompatible in total to me :wink:

Anyhow, I have a new testdriver ready, the third one, 32bit. You can grab it here:
http://www.rudolfs-place.nl/Haiku/Downloads/Intel_extreme_drv_v3_32bit.zip
(the first one I took offline btw)

This new version now works both on analog connected screens, and on digital connected (HDMI) screens, at least on IvyBridge as I am testing on that one. There will hopefully also be improvements for all other systems so I’m always interested in testresults :smile:

The digital connection currently works in the ‘analog’ way as I described in my story above. So the link is set to the actually needed speed, and so is the refreshrate. Nice for gaming (and such) indeed… :wink:

As a sidenote I also updated git again with a few small fixes that I stumbled upon today while fixing the trouble with the digital connection (which now works because of those fixes, plus the M/N and panelfitter programming I have not yet in git).

Please note that only one connected screen is tested by me at the moment, I think very soon I’ll test with both an analog and digital connection. But first I’ll doublecheck gen4 displayport (did not test that yet), and I’ll dive in the Sandy Bridge compat trouble (gives a picture but still has distortions): I’ve located a system with that chipset over at the office and directly demoed Haiku to an interested collegue of mine :wink:

If you start testing, and you get no picture (out of range), it might be handy to first boot in vesamode and set a nice starting mode: i.e. 1024x768 if you want to test single-lane modes (downto 640x480 i.e. will go that way): or 1280x1024 if you want to test dual lane modes ( goes upto/including 1920x1080 but only in low refreshrates ( just below 60Hz).
If you’d start with 1920x1080 @ 70 Hz or so: the driver needs three lanes, but since that’s never programmed by the BIOS (anyone a 4k screen or so? what does VESA offer on such a screen?). this won’t give you a working screen.

After you set your starting mode in VESA you can reboot to the normal driver: that should work, and you should be able to set modes nearby as explained just now.

I hope this piece of text makes sense to everyone… Good luck!

9 Likes
90

I tried your v3 of the intel_extreme driver on a 32bit beta2 Haiku (all updates applied), seeing if it would maybe fix my ticket #14643. It does not. Worse, the boot process stops at the last icon. Here’s the syslog.

I tried with booting into VESA and setting a lower resolution (1024x768), same result.
When I hit CTRL+ALT+DEL, I see a white bar filling ca. 75% at the top of the screen before the computer reboots.

It’s a notebook with just the internal panel, no external monitor.

91

Hi, if in your case you got a desktop without my testdriver, and before my two patches to git: then you’ll probably have no picture since my git updates and without the v3 driver.

This is the second laptop I get response from so to speak: looks like it’s best not to program the DPLL for laptops for now as that’s (almost) the only thing I can think of that could be the added ‘error’.

Actually it’s progress, showing another problem in the driver I expect.

Since you’re a developer:

For the pll you could try what happens if you disable the code in Pipes.cpp, lines 259 and 343-349. From your comment ‘since some time’ it might be that a previous commit for the CK505 clock disturbed your screen output already: so you could undo that patch locally for a test as well. (it’s one line there).

As last possible thingy I can think of now is you could as a seperate test disable the watermark default programming I added to see if that fixes output for you. Line 405 in Pipes.cpp (lines from master).

If you could test these things that would be cool. If not, I have to create a few variations of the driver to send to you for these tests. Best of course would be I find a laptop myself, but sofar nothing yet…

1 Like
92

Hmm,

From that syslog it looks like the accelerant is never loaded… Did you install both the kernel driver and accelerant in the non_packaged hierarchy? Maybe check that fist… Or is this the incorrect syslog?

Thanks!

1 Like
93

Rudolf - What generations does the driver currently support?

1 Like
94

Oh, thanks for the warning, I’m still on hrev55102.
I tried to put a fresh nightly on a test partition, but ran into issues, the installation didn’t finish. Still I managed to boot into that installation (hrev55125, 32bit).
The screen comes on immediately (good), but I’m limited to 1024x768, 60Hz. Changing resolution or frequency results in a black screen. Native resolution is 1920x1080, 60Hz.

I’m a bit stretched for time, so I don’t know when I get to try the code changes you suggested above.

The syslog is the correct one. I put the files at:
~/config/non-packaged/add-ons/accelerants/intel_extreme.accelerant
~/config/non-packaged/add-ons/kernel/drivers/bin/intel_extreme
and even a link to the bin at ~/config/non-packaged/add-ons/kernel/drivers/dev/graphics/intel_extreme

(Maybe you could put the files into that hierarchy in the test ZIPs, so people can simply unzip to ‘non-packaged’.)

95

Ah, well, then we have no problem at all on your system:

  • you get immediate a screen whereas before that could happen sometimes after 15 minutes even
  • you have a correct desktop in 1024x768 @ 60Hz. No artifacts whatsoever.

This confirms theres no problem in hrev55125 with my git fixes and the CK505 thing. The fact you cannot change resolution or you cannot do native resolution is because modeswitching is not supported yet in git.

The testdriver added more modeswitching requied code, but not yet for all digital interfaces. The internal one probably also needs panelfitter programming. But not M/N programming if a laptop internal panel is -always- connected directly to the Intel CPU. We could do some tests with a new testdriver in this direction.

Is is possible for you to grab syslog once more from hrev55125, with intel_extreme stuff included? Maybe wait a bit longer before grabbing that syslog? I don’t know if it can be that messages remain in a cache for a short time before being written to the actual file or something. I saw entries missing here as well on some of the numerous boots I did in the past month or so.

1 Like
96

BTW: if you want to do another mode, you have to set it ‘blindly’ in screenprefs, reboot, hit space, select the same mode from the resolution menu (so replace the ‘current’ mode with the one you just set the desktop at) and then continue the boot.

Could be that native mode is possible that way for you (if it’s listed in the bootmenu that is). The modes need to be the same because otherwise the programming that -is- done by the driver does not match what’s needed. In that case the screen is distorted or ‘sync’ seems to be missing if all is right.

Update: the method I am describing for setting a mode may seem strange: but it has to do with the fact Haiku keeps the ‘current’ mode in not one, but -two- config files. One is used at boot, one after. And they don’t always match. I don’t know yet what the exact behaviour is, but this is how you can work around that.

1 Like
97

Indeed! :smile:
Even better, I rebooted into that hrev55125 and now, when I changed resolution to the native 1920x1080, it just worked! Brilliant, now I’ll update my ‘production’ system, fingers crossed…

This is the syslog from that adventure.

2 Likes
98

Hmm… maybe I was a bit premature in my rejoicing. I updated my 64bit Haiku to hrev55129 and here I still have the initial black screen. I only restarted 3 times, but the blackscreen never lasted for longer than 20 seconds. Could be coincidence…

I also tried setting the default screen resolution from the boot options to 1920x1080. Didn’t make a difference.

Could there be a difference between 32bit and 64bits?
Here’s the syslog of the 64bit hrev55129.

1 Like
99

OK, I just compared both logs and there’s one very disturbing difference. Maybe you can help out here, though I’ll also look myself.
It seems there’s an adressing problem in the driver.

32bit does log what I’d expect (more or less):
KERN: intel_extreme: CALLED void Pipe::ConfigureClocks(const pll_divisors&, uint32, uint32)
KERN: intel_extreme: Old PLL selection: 10
KERN: intel_extreme: Route PLL A to transcoder A
KERN: intel_extreme: New PLL selection: 18

whereas 64 bit:
KERN: intel_extreme: CALLED void Pipe::ConfigureClocks(const pll_divisors &, long unsigned int, long unsigned int)
KERN: intel_extreme: Old PLL selection: 41e041e
KERN: intel_extreme: Route PLL A to transcoder A
KERN: intel_extreme: New PLL selection: 41e0418

This must be utter nonsense! looks like wrong adress, or at least wrong content (PLL selection).

UPDATE this is Pipes.cpp, line 358, and on.

1 Like
100

BTW Just to be sure, can you confirm 32bit works OK every boot?
Also: there are read32 and write32 functions in Accelerant.h. Are these OK I wonder?
In the log only one single instance of register -content- is literally logged. So could be all accesses are faulty in 64bit.
Unfortunately this is less my area of expertise :wink:

In order to find this I would have to setup a 64bit system with the sources and go building 64bit drivers with testing code to find this error, if I’d be able to.

1 Like
101

Setting up a 64bit wasn’t as easy as with 32bits. Don’t remember now what it was but I think it was that 64 bits need to be crosscompiled on a 64bits Haiku.

Perhaps you can use your existing 32bits system to compile 64bits Haiku and then just install or make a second USB with 64 bits Haiku?

102

I tried v2 and v3 driver on Beta 32 bit, just out of curiosity. Normally it boots to 1280x1024 at 60Hz using the Intel driver. With v2 or v3 installed in non-packaged it won’t boot past the rocket icon.