intel_extreme: can't find native resolution

[korli]

Haiku starts with the default resolution 1024x768 instead of the native resolution (1920x1080).

[rudolfc]

Hi,

I fear just adding the ID's is a too simple approach.

For instance: I see no mention of this being a laptop in the text here or in the syslog? is it? From the looks of it you have a EDP connected panel, which has special handling in case it's a laptop. (IsMobile()).

Currently nothing is detected so modesetting is almost fully skipped, which might look like the driver is working, while it isn't..

Also it's strange that no VBT is detected at all, maybe this generation has this space enlarged (> 8kB). Wouldn't know, I did not just yet read specs for this type..

[rudolfc]

Oh that panel: connected to PORT_E, which is eDP, which is hardcoded to DDI-A (==eDP DDI). its set to 8bit per color (24bit), 2 lanes in DP SST mode from the register in the log. The driver doesn't look at it yet because it's not seen as a laptop.

[korli]

Right, it's eDP; as you said, the driver doesn't do much, brightness slider doesn't work. I'll look at using the PCI ROM to find the VBT.

[rudolfc]

So, if OPRegion can be mapped, but doesn't contain the signature, we could fallback to reading the ROM instead: currently the driver assumes that if OpRegion exists it will succeed on finding VBT: but doesn't in your case.

The rom is read from $c0000 legacy space: the normal way a graphics card has rom probably doesn't work (already tested that: doesn't exist that way, via the PCI config space that is)

[korli]

Right, I was mistaken, because lspci on Linux shows expansion ROM for the device at $c0000, but no PCI ROM seems configured.

[korli]

hi, found the VBT is handled differently on newer OpRegion versions, please see ​https://review.haiku-os.org/c/haiku/+/5109

Then there is a new generic dtd block which I handled in ​https://review.haiku-os.org/c/haiku/+/5110

The bad news: the mode found in the VBT is 1024x768, so it seems EDID has to be used.

[korli]

And now I can't get 1920x1080 to work in the preferences, looks more like #17655 now.

[rudolfc]

Nice work! So if there's no downside just apply both updates I'd say. After this it still has to be expanded more since some systems still don't find the right native mode as you just stated. Korli, can you also upload a syslog from how your system behaves with these changes, in your ticket I'd say?

[rudolfc]

oh wait: this is that ticket :-)

[korli]

syslog hrev55954

[rudolfc]

Hi, In the meantime I tested your updates on Ivybridge and Skylake: both behave the same, as would be expected. So, for your system: the mode is not the native one (1024), I'm curious:

• do you have a picture on the internal panel?
• can you set different resolutions?
• does it all scale correctly?
• can you set the native mode?
• does GLTeapot spin at 60Hz?

Thanks again for your work on this!

[korli]

• do you have a picture on the internal panel? yes
• can you set different resolutions? yes
• does it all scale correctly? no, it's only scaled in the 1024 box.
• can you set the native mode? no, I can set 1920x1080 in the prefs but it's scaled down in the 1024 box.
• does GLTeapot spin at 60Hz? the GLTeapot doesn't spin at all.

The driver behaved actually better before my VBT changes... A setting to disable the VBT might be an idea, until EDID is supported.

[rudolfc]

Before thse changes the driver did nothing, so that's only 'natural' and actually I prefer what it does now ;-)

• So this box does not fill the entire screen I take it?
• do other resolutions scale nicely inside that box? (so: the scale function -is- working, no clipping content etc)
• in what resolution do you see the icons screen? would that be 1024*768 as well?
• this box: is that the part of the screen like this: left-top area, of size h=1024/1920 and v= 768/1080? (your native mode is 1920x1080, no?)

• looks like the interrupt code is not working ok yet, I guess someone should look at that piece as well then for this specific generation.

I think, from a user perspective, the driver should be disabled alltogether for your chipset, it should run in vesa or framebuffer mode instead. Since you're a developer and without testing we won't get any further I can personally live with the fact that you see 'weird things' :-)

I also think, that a more constructive setting would be that you can force a native modeline there. it would be interesting to see what the driver does for you if we force the right native mode: there's a chance it actually working nice already then.. Or at least for some other users, with i.e. wrong BIOSes flashed, there's a way to set things straight.

Of course, EDID for DP should be implemented as well, though there's still no guarantee I guess that all internal panels even support that function..

[rudolfc]

Update: about scaling: it's not very interesting that it currently scales down: it's much more interesting that it scales at all (that gives us a reasonable chance to get thing up quick), I hope you gathered that from my comments above :-)

[korli]

the box is at the top left corner, about h=1024/1920 and v=768/1080. 1024x768 is 100% in the box, 1920x1080 is scaled down in the same box. the icons boot screen is in native resolution 1920x1080.

Providing a setting with the native modeline would be an option. I'll try to force the native resolution in the VBT code.

Yes, the chipset is a big work-in-progress, to be disabled for releases.

I'm trying to follow the EDID code for DDI/DP, and I'm lost already. I'll probably look at the interrupt code, it might be an easier thing for me.

[rudolfc]

About EDID, I have a bit of a clue how it works, but I did not get around to actually try to implement it. I think I'd try it first inside the driver, so outside of the common code. I think I saw the newer radeon driver already supports EDID from such a connection, done inside the driver there as well. This dedicated i2c controller is a strange beast I think, not some generic device, but has limitations in transfer size for instance. Also some extra coding has to be done to get that AUX channel going, it may well be powered down by the BIOS as a power-save feature, since it only has to be up for EDID detection. Depending on chipset you (probably) have to poke at different registers to get the power(well) for this going. Power saving btw, has no or lo prio for me, I'd just power up for now and leave it that way until a later point in the future if/when this would become important (that would mean the driver has matured a lot I guess ;-)

[korli]

At least in Linux i2cdetect finds the EDID on the AUX bus, so I doubt it is powered down by the driver after EDID detection (it doesn't say that the BIOS has it powered down).

[korli]

with ​https://review.haiku-os.org/c/haiku/+/5175 the EDID is found and the correct mode is used. the vblank interrupt is already committed. Now it uses a default AUX channel on Gen11. the correct channel should be found in the VBT.

[rudolfc]

Wow, sounds very nice! Thanks for solving that puzzle, even via common code! Once it's committed I'll test it on gen 7 as well :-)

[korli]

it's committed in hrev56001, I tested also on KabyLake.

[korli]

Support looks good, so closing.