| Summary: | Regression i915 with 800x600 | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Roberto Viola <cagnulein> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | cagnulein, imre.deak, intel-gfx-bugs |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | Triaged | ||
| i915 platform: | BXT | i915 features: | |
| Attachments: | |||
|
Description
Roberto Viola
2019-02-25 14:50:30 UTC
Created attachment 143460 [details]
dmesg of the 4.7 version (the one that works)
Created attachment 143461 [details]
dmesg of the 4.8 version (the one that doesn't work)
> With the 4.8-rc2 and above, the output of the framebuffer and Xorg exceeds > the monitor. Kernel 4.8 is quiet old, have you tried to verify with latest kernel/drmtip? (https://cgit.freedesktop.org/drm-tip) Imre, any comments. yes, the issue starts from 4.8 (from this commit "drm/i915/bxt: Remove the preliminary_hw_support flag") and it's still present with the latest kernel/drmtip. Just to be clear, my monitor supports only 800x600 and 640x480 resolutions. It's quite old, but in the industrial enviroment it's still used (a lot!) Please boot drm-tip with drm.debug=0x1e passed to the kernel cmdline, and attach the resulting dmesg. Created attachment 143471 [details]
5.0.0-rc8+ drm-tip dmesg
here you can find the dmesg of drm-tip.
The issue is still there.
Created attachment 143472 [details]
framebuffer issue
Created attachment 143473 [details]
xorg issue
i attached some picture of the issue in order to give a better idea of the issue. As you can see the images oversize the screen.
looking the dmesg that i posted of the drm-tip, i guess the issue starts from this: Feb 25 18:20:19 debiankvm kernel: [ 371.091475] [drm:skl_update_scaler [i915]] scaler_user index 0.31: staged scaling request for 800x600->1024x768 scaler_users = 0x80000000 Looks like we're picking the VBT mode over the EDID mode. The problem seems to be that there is no preferred mode listed in the EDID. Please attach a copy of /sys/class/drm/card0-eDP1/edid (In reply to Ville Syrjala from comment #10) > Looks like we're picking the VBT mode over the EDID mode. The problem seems > to be that there is no preferred mode listed in the EDID. > > Please attach a copy of /sys/class/drm/card0-eDP1/edid Make that /sys/class/drm/card0-eDP-1/edid uhm, i haven't any /sys/class/drm :S root@debiankvm:~# uname -a Linux debiankvm 5.0.0-rc8+ #1 SMP Mon Feb 25 16:41:50 CET 2019 x86_64 GNU/Linux root@debiankvm:~# cat /sys/class/ ata_device/ backlight/ bsg/ devfreq/ firmware/ hwmon/ iommu/ mem/ net/ powercap/ ptp/ scsi_disk/ sound/ tpm/ vc/ ata_link/ bdi/ dca/ dma/ gpio/ i2c-adapter/ leds/ misc/ pci_bus/ power_supply/ rtc/ scsi_generic/ spi_master/ tpmrm/ vtconsole/ ata_port/ block/ devcoredump/ dmi/ graphics/ input/ mei/ mmc_host/ phy/ pps/ scsi_device/ scsi_host/ thermal/ tty/ watchdog/ root@debiankvm:~# find /sys | grep drm root@debiankvm:~# Created attachment 143477 [details]
card0-eDP-1 edid
sorry, i blacklisted the i915 for a test.
Here the edid with the i915 loaded.
# ls /sys/class/drm/
card0/ card0-DP-1/ card0-DP-2/ card0-eDP-1/ card0-HDMI-A-1/ card0-HDMI-A-2/ renderD128/ version
no card0-eDP1
(In reply to Ville Syrjala from comment #10) > Looks like we're picking the VBT mode over the EDID mode. The problem seems > to be that there is no preferred mode listed in the EDID. > > Please attach a copy of /sys/class/drm/card0-eDP1/edid So simplebuffer has a different way to choose the preferred mode? Because it works well Created attachment 143486 [details]
vbt binary file
Created attachment 143487 [details]
vbt decoded
i think it could be useful
Created attachment 143488 [details] [review] [PATCH] drm/edid: If no preferred mode is found assume the first mode is preferred This should fix it I think. Please test and attach again the resulting dmesg with drm.debug=0x1e so that I can double check the results. Created attachment 143490 [details]
dmesg with the Ville Syrjala's patch
thanks Ville Syrjala! It works like a charm!
(In reply to Roberto Viola from comment #18) > Created attachment 143490 [details] > dmesg with the Ville Syrjala's patch > > thanks Ville Syrjala! It works like a charm! Nice. Looks like there is a very slight discrepancy in that the VBIOS apparently picks the 800x600 EST mode with positive h/vsync, the detailed mode which we pick has negative h/vsync. But since it works I guess we don't need to worry about that. Created attachment 143554 [details] [review] [PATCH 1/2] drm/i915: Refactor EDID fixed mode search Created attachment 143555 [details] [review] [PATCH 2/2] drm/i915: Pick the first mode from EDID as the fixed mode when there is no preferred mode Slight redesign based on review feedback. Rather than do this in the generic EDID parser we'll do the fallback in the driver. Now two patches instead of one. Please test these and report back whether it still works. Created attachment 143563 [details]
dmesg
it works fine with these 2 patch!
Do you need other tests?
Declaring this as fixed via commit 8f49673ef919e828cf66c23d9c73c1d50e56610a Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Mar 21 15:24:42 2019 +0200 drm/i915: Pick the first mode from EDID as the fixed mode when there is no preferred mode Thanks for reporting the bug, and for the thorough testing. Thanks to you for the patch :) Have a nice weekend |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.