Opened 3 years ago

Closed 3 years ago

#17432 closed bug (fixed)

Intel default video breakage

Reported by: kallisti5 Owned by: rudolfc
Priority: normal Milestone: Unscheduled
Component: Drivers/Graphics/intel_extreme/skylake Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (2)

photo_2021-11-29_20-16-14.jpg (134.4 KB ) - added by kallisti5 3 years ago.
intel_extreme_logs.txt (10.3 KB ) - added by kallisti5 3 years ago.
cat /var/log/syslog | grep intel_extreme

Download all attachments as: .zip

Change History (15)

by kallisti5, 3 years ago

comment:1 by kallisti5, 3 years ago

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

by kallisti5, 3 years ago

Attachment: intel_extreme_logs.txt added

cat /var/log/syslog | grep intel_extreme

comment:2 by diver, 3 years ago

Component: Drivers/Graphics/intel_extremeDrivers/Graphics/intel_extreme/skylake
Owner: changed from pulkomandy to rudolfc

comment:3 by rudolfc, 3 years ago

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.

comment:4 by korli, 3 years ago

Version: R1/beta3R1/Development

comment:5 by korli, 3 years ago

Scaling was fixed in hrev55669.

comment:6 by rudolfc, 3 years ago

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 ;-)

Last edited 3 years ago by rudolfc (previous) (diff)

comment:7 by rudolfc, 3 years ago

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

comment:8 by korli, 3 years ago

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

comment:9 by rudolfc, 3 years ago

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)

comment:11 by rudolfc, 3 years ago

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 highest 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 ;-)

Last edited 3 years ago by rudolfc (previous) (diff)

comment:12 by korli, 3 years ago

applied in hrev55674

comment:13 by kallisti5, 3 years ago

Resolution: fixed
Status: newclosed
  • 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!

Note: See TracTickets for help on using tickets.