Created attachment 143458 [details] kernel config file used On my system, systematically, with the kernel 4.7 my i915 runs correclty on my 800x600 monitor. With the 4.8-rc2 and above, the output of the framebuffer and Xorg exceeds the monitor. I try several times switching only the kernel version and the problem follows the kernel version (4.7 works, 4.8-rc2 doesn't). I can't try the 4.8-rc1 because it hangs on startup. lspci: 00:00.0 Host bridge: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series Host Bridge (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Device 5a85 (rev 0b) 00:0f.0 Communication controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series Trusted Execution Engine (rev 0b) 00:12.0 SATA controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series SATA AHCI Controller (rev 0b) 00:13.0 PCI bridge: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series PCI Express Port A #3 (rev fb) 00:13.3 PCI bridge: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series PCI Express Port A #4 (rev fb) 00:15.0 USB controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series USB xHCI (rev 0b) 00:16.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series I2C Controller #1 (rev 0b) 00:16.3 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series I2C Controller #4 (rev 0b) 00:17.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series I2C Controller #5 (rev 0b) 00:17.1 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series I2C Controller #6 (rev 0b) 00:18.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series HSUART Controller #1 (rev 0b) 00:18.2 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series HSUART Controller #3 (rev 0b) 00:1b.0 SD Host controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series SDXC/MMC Host Controller (rev 0b) 00:1c.0 SD Host controller: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series eMMC Controller (rev 0b) 00:1f.0 ISA bridge: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series Low Pin Count Interface (rev 0b) 00:1f.1 SMBus: Intel Corporation Atom/Celeron/Pentium Processor N4200/N3350/E3900 Series SMBus Controller (rev 0b) 01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) 02:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) Bisecting the kernel i found that the issue starts from here: Autore: Imre Deak <imre.deak@intel.com> 2016-07-01 16:40:45 Revisione creata da: Imre Deak <imre.deak@intel.com> 2016-07-01 20:25:54 Genitore: 37f501afed23fa1126017255495d5be5e97c9d6d (drm/i915/bxt: Export pooled eu info to userspace) Figlio: bed50aea61df4e62395620795079f0e7a3876723 (drm/i915/shrinker: Flush active on objects before counting) Ramo: master, remotes/origin/master Segue: v4.7-rc2 Precede: v4.8-rc1 drm/i915/bxt: Remove the preliminary_hw_support flag Broxton is now part of CI which doesn't indicate any major problems so enable the driver by default. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467384045-17028-1-git-send-email-imre.deak@intel.com ----------------------- drivers/gpu/drm/i915/i915_pci.c ----------------------- index a7f8f4fb7e8d..949c01686a66 100644 @@ -328,13 +328,12 @@ static const struct intel_device_info intel_skylake_gt3_info = { .is_skylake = 1, .gen = 9, .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING, }; static const struct intel_device_info intel_broxton_info = { - .is_preliminary = 1, .is_broxton = 1, .gen = 9, .need_gfx_hws = 1, .has_hotplug = 1, .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, .num_pipes = 3, .has_ddi = 1, And it's quite simple now understanding why: on the versions before this patch, the system loads the simplefb that manages correctly the 800x600 resolution. The kernel version with this patch, load correctly the intel driver that doesn't manage the 800x600 resolution. So, as workaround, you can blacklist the i915 module and enabling the "Simple Framebuffer" from the kernel you will see the corrected resolution. But i think the i915 driver should manage this resolution too.
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.