Intel default video breakage

[kallisti5]

The intel graphics modesetting broke on my XPS 13 between hrev55599 and hrev55668.

• It looks like hrev55599 was using framebuffer. One resolution is available: 3200x1800.
• hrev55668 changes to intel_extreme and selects 1024x768 by default.

Updating the resolution to 3200x1800 fixes the video output... however anything except native resolution fails to set properly.

[kallisti5]

Dell XPS 13, panel output. Skylake GT2 [HD Graphics 520]

[kallisti5]

cat /var/log/syslog | grep intel_extreme

[rudolfc]

Please upgrade again. Your panel is not yet detected here, assuming you have a laptop?

If you retest, upload a new syslog as well, I'm curious because of the high resolution additional stuff might need te be done.

[korli]

Scaling was fixed in hrev55669.

[rudolfc]

Hi,

I see we need to update routine intel_get_edid_info to also return OK if got_vbt, but -only- on laptops. That should fix the native mode. Unfortunately I don't have time until tonight ;-)

Also routine intel_get_accelerant_device_info probably needs some txt updating since we now support more cardtypes ;-)

[rudolfc]

Update: Korli tried this and it failed. I'll have another look and get back on this.

[korli]

Second try with ​https://review.haiku-os.org/c/haiku/+/4749/1 seems to work.

[rudolfc]

Hi, perfect. I was wondering if it was missing in the meantime. Can you update it to also return the native mode for desktop systems? there's no reason not to do that..

If you look at EDID info then the 'additional video mode' is the native mode (example):

KERN: Additional Video Mode (1920x1080@60Hz): KERN: clock=149.430000 MHz KERN: h: (1920, 2008, 2052, 2200) KERN: v: (1080, 1082, 1087, 1132)

[korli]

wouldn't this duplicate what the app_server already does at ​https://git.haiku-os.org/haiku/tree/src/servers/app/drawing/interface/local/AccelerantHWInterface.cpp#n924 ?

[rudolfc]

Thanks for the pointer. I doublechecked my nVidia driver, it does more or less the same indeed: abort if full EDIT known. Where it doesn't matter if it's a laptop or desktop system.

On that driver I have a trick to fetch the 'native' modeline from registers in the card as programmed by the BIOS (at least, its the highest mode that can be done over there) is case fetch EDID fails.

In case it fails over there I also check for the lowest common mode from the connected screens and return that for compatibility (Because app_Server doesn't support two seperate screens yet). On top of that I do compatibility checks on aspect. The modelist returned to app_Server there are filtered (other hook) so only widescreen modes would be offered to use if the screen is widescreen, and vice versa if it's all 4:3 (5:4) aspect.

That's overkill maybe and I don't know if these days it still has the same effect in screenprefs, because, as you just showed, app_server itself checks EDID and might come' in the way' of what the driver actually wanted to make happen.

--

Back to Intel_extreme I guess it's OK as it is now. If I come into a situation where I cannot fetch EDID, but I -can- determine the preferred mode trick-wise, the hook can always be updated to return that mode for desktop then. That being said, I expect that situation will probably not apply there since a lot of manuals are online :-)

EDIT: BTW I wonder if it's a good idea for app_server to determine a preferred mode from the EDID info after all, because it's not always so that the driver can set all modes the screen would offer. The driver should have a say in that as well somehow: that's also part of the reason I did what I did on my drivers ;-)

[korli]

applied in hrev55674

[kallisti5]

• Updated to hrev55673 and can confirm modesetting is now working properly on my XPS 13
• Updated to hrev55678 and can confirm modesetting is still working properly on my XPS 13

Nice work!