Note:This is a common bug for all tested platforms including CFL-S/Bean Canyon/CFL-H/WHL-U/June Canyon. This issue is a regression issue compared with 18.10 (v4.18) We have verified on 19.04 beta1 (v5.0.0) kernel, linux official kernel, and latest drm-intel-next kernel, all can reproduced. Just list the platform information for CFL-S. Platform information: Label: CFLS04 Processor: CoffeeLake DT, Genuine Intel(R) CPU 0000 @ 2.60GHz, P0 Stepping, GT2 Bios: CNLSFWX1.R00.X144.B02.1805180751 Chipset: CNL B0 Stepping OS: Ubuntu 19.04 Kernel: 5.0.0-8-generic Details: Only half of the screen is displayed, when run "xrandr --output $device --rotate left/right". Please check the attachment "Screen_half_rotate_CFLS04_19.04.jpg".
Created attachment 143910 [details] dmesg log
Created attachment 143911 [details] screen shot
*** Bug 110374 has been marked as a duplicate of this bug. ***
Created attachment 143929 [details] upload dmesg with drm.debug=0x1e log_buf_len=4M enable the debug switch and upload the dmesg log for reference.
I am unable reproduce this issue on my machine (KBL) with drmtip 5.1.0 rc4+. "xrandr --output $device --rotate left/right" shows external screen normal/complete but not as in the attachment. Can you try to verify with drmtip?
ok. I will have a try. Keep tune. Thanks for your response.
we can still reproduce this issue with drm-tip (5.1.0-rc4).
What I would like to know is that is this kernel regression or some userspace (modesetting driver) issue.
I have investigated this issue a bit on Friday. Problem ended up in userspace. As we have noticed the screen stays blank for eDP, because primary plane is disabled, whicl cursor still visible. I was looking for some wrong condition or calculation in kernel, but basically it is just userspace which assigns NO_FB to primary active plane at some point when other screen is rotated. Then skl_plane_check-drm_atomic_helper_check_plane_state(called from atomic_check) detects that and turns off the plane completely, making it further unusable. This is done in drm_atomic_set_fb_for_plane function. I can fix it by adding a simple check there which forbids removing FB from primary plane if it is active. Not sure if this patch is correct or will be accepted, but lets see :)
See this and check if it helps: https://patchwork.freedesktop.org/patch/299515/
If the problem is in userspace, fix userspace. :)
(In reply to Stanislav Lisovskiy from comment #10) > See this and check if it helps: > > https://patchwork.freedesktop.org/patch/299515/ it is not the whole screen blank. almost half of screen is blank.
(In reply to Maarten Lankhorst from comment #11) > If the problem is in userspace, fix userspace. :) If only I could :) (In reply to qwang13 from comment #12) > (In reply to Stanislav Lisovskiy from comment #10) > > See this and check if it helps: > > > > https://patchwork.freedesktop.org/patch/299515/ > > it is not the whole screen blank. almost half of screen is blank. For me and other person the whole screen is getting blank but cursor stays visible. Probably depends on your screen orientation or other parameters. But the fact is that userspace decides that you no longer need primary plane on eDP for some reason.
with this patch, the issue is fixed. Will this patch be accepted in upstream?
It helps if you can comment that "tested-by" eg.
(In reply to qwang13 from comment #14) > with this patch, the issue is fixed. Will this patch be accepted in upstream? Nope :D Because it is allowed to disable primary plane, if user space wants to. So if userspace decides to do something stupid, it is hard to fix in the kernel. This hack was just to prove that this is coming from userspace.
Based on comments, not our bug. Userspace issue.
*** Bug 108764 has been marked as a duplicate of this 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.