Created attachment 123509 [details] eDP screen When trying to set clone mode from terminal with eDP (13x7) and HDMI(19x10), a malfunction is seen , please see the attached pictures, and the dmesg.log Steps to reproduce: ================================================== 1. attach HDMI panel to platform 2. Set any mode except clone mode 3. Set max resolution on both eDP and HDMI 4. open a terminal: xrandr --output HDMI1 --same-as eDP1 Expected results: ================================================== Both outpput screens should be the same. Actual Result: ================================================== A malfunction of clone mode is observed when it is set. HW Configuration +================================================ product: Inspiron 15-3552 (06AC) description: Motherboard product: 0T14MC Family: Braswell version: A00 version: Intel(R) Pentium(R) CPU N3700 @ 1.60GHz SW Configuration ================================================== kernel: 4.2.3-300.fc23.x86_64 mesa: mesa-11.0.3-1.20151012.fc23.x86_64 cairo: 1.14.2-2.fc23.x86_64 libdrm: 2.4.65-1.fc23.x86_64 xorg: 7.5-20.fc23.x86_64
Adding to my previous comment, the OS is Fedora 23 64bits
Created attachment 123510 [details] HDMI screen
Created attachment 123511 [details] dmesg
Comment on attachment 123510 [details] HDMI screen Please try to ensure the attachment mime types are correct.
The dmesg.log doesn't contain any drm.debug info. Please attach your Xorg.0.log, the output of xrandr --verbose and the typescript of the commands you ran.
The problem seems to be that Xrandr is taking as default value for configuration the HDMMI highest value. Im testint with a 4k display facing the same issue. The GI from Ubuntu is making the change without any problem showing good cloning m taking as baseline the eDP. Attaching Xorg.log + xrandr --verbose (before, after cloning with xrandr , and clonning with UI)
Tested with following configuration, problem persists. Software information ============================================ Kernel version : 4.6.0-drm-intel-nightly-ww23-commit-fb023a2+ Linux distribution : Ubuntu 16.04 LTS Architecture : 64-bit Mesa version : Not found << Please see the message at the bottom >> xf86-video-intel version : 2.99.917 Xorg-Xserver version : 1.18.3 DRM version : 2.4.68 VAAPI version : Intel i965 driver for Intel(R) CherryView - 1.7.0 Cairo version : 1.15.2 Intel GPU Tools version : Tag [intel-gpu-tools-1.14-348-g303b380] / Commit [303b380] Kernel driver in use : i915 Hardware acceleration : Bios revision : 0.33 KSC revision : 0.16 Hardware information ============================================ Platform : Motherboard model : 10G9000NUS Motherboard type : BRASWELL Desktop Motherboard manufacturer : LENOVO CPU family : Pentium CPU information : Intel(R) Pentium(R) CPU N3700 @ 1.60GHz GPU Card : Intel Corporation Device 22b1 (rev 21) (prog-if 00 [VGA controller]) Memory ram : 8 GB Maximum memory ram allowed : 8 GB Display resolution : CPU's number : 4 Hard drive Capacity : 120 GB
Created attachment 124304 [details] Xorg Log
Created attachment 124305 [details] xrandr before clonning
Created attachment 124306 [details] xrandr after clonning
Created attachment 124307 [details] xrandr after clonning with UI
The kernel is unhappy -> please attach drm.debug=0xe dmesg.
this issue continue failing with the next configuration. ============================================ Software information ============================================ Kernel version : 4.10.0-rc3-drm-tip-commit-af72342+ Linux distribution : Ubuntu 16.10 Architecture : 64-bit Xorg-Xserver version : 1.18.4 DRM version : 2.4.74 Cairo version : 1.15.5 Intel GPU Tools version : Tag [intel-gpu-tools-1.17-115-g12e34d8] / Commit [12e34d8] Kernel driver in use : i915 Bios revision : 0.33 KSC revision : 0.16 Hardware information ============================================ Platform : BSW Motherboard model : 10G9000NUS Motherboard type : BRASWELL Desktop Motherboard manufacturer : LENOVO CPU family : Pentium CPU information : Intel(R) Pentium(R) CPU N3700 @ 1.60GHz Add Comment Collapse All Comments Expand All Comments attach ========================== dmesgC2 Xorg.0.log
Created attachment 129394 [details] dmesgC2
Created attachment 129395 [details] Xorg.0.log
The 5kx2k fb creation obviously fails due to the stride exceeding the hw limit. So that part is expected as far as the kernel is concerned. I don't really know what the supposed cloning problem is. To me the images look pretty much as expected when you try to clone displays with different resolutions. And there is one unrelated WARN in the kernel log. It's clearly a regression from one of my recent patches, so I'll have to fix it up.
(In reply to Ville Syrjala from comment #16) > And there is one unrelated WARN in the kernel log. It's clearly a regression > from one of my recent patches, so I'll have to fix it up. https://patchwork.freedesktop.org/patch/137747/ should hopefully eliminate the WARNs.
The warns and whatnot should be gone now. Can someone now explain what the supposed cloning failure is?
Elio can you please answer the question from Ville
(In reply to Ville Syrjala from comment #18) > The warns and whatnot should be gone now. > > Can someone now explain what the supposed cloning failure is? It seems that when you force to clone from lower to high resolution, the OS is overlaping images. It is not adjusting resolutions by itself, please check the attached image.
Created attachment 130216 [details] Overlaping image
(In reply to Elio from comment #21) > Created attachment 130216 [details] > Overlaping image The bacground image? That's something the compositor/some other component does for whatever reason, so I don't see what this has to do with i915. Maybe try telling whatever draws the background to tile the image instead of stretching and maybe then it looks less nuts.
(In reply to Ville Syrjala from comment #22) > (In reply to Elio from comment #21) > > Created attachment 130216 [details] > > Overlaping image > > The bacground image? That's something the compositor/some other component > does for whatever reason, so I don't see what this has to do with i915. > Maybe try telling whatever draws the background to tile the image instead of > stretching and maybe then it looks less nuts. This issue is not seen anymore, I tested this on GLK where the issue was also seen. Closing bug
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.