Summary: | [Ubuntu 19.04] The screen display incompleted when rotate the screen to left/right | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | qwang13 <quanxian.wang> | ||||||||
Component: | DRM/Intel | Assignee: | Stanislav Lisovskiy <stanislav.lisovskiy> | ||||||||
Status: | RESOLVED NOTOURBUG | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
Severity: | major | ||||||||||
Priority: | high | CC: | intel-gfx-bugs, quanxian.wang, stanislav.lisovskiy | ||||||||
Version: | unspecified | Keywords: | regression | ||||||||
Hardware: | All | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | Triaged, ReadyForDev | ||||||||||
i915 platform: | ALL | i915 features: | display/Other | ||||||||
Attachments: |
|
Description
qwang13
2019-04-10 07:58:02 UTC
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.