Created attachment 139838 [details] Xorg.0.log on 1.20.0 With Intel Integrated Graphics (HD Graphics 520) since upgrading to xorg-server 1.20.0, when I set rotation different from normal on a screen (internal or external), the screen turns black and only the cursor remains visible. In Xorg.0.log the message 'failed to add rotate fb' appears. (see attachment) Cf. my bug report on the Arch Forums: https://bbs.archlinux.org/viewtopic.php?pid=1788344 I did a bisect and the current behaviour seems to be since commit c8c276c9569b3ca1e695682a5443f1b615c606bd. However in the commits leading up to that rotation was broken in various other ways, which however did not yield this message. Another bisect showed that setting rotation initially stopped working on commit 9817c14f6a2ea5db44459659131c13f403716df1 Author: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Date: Wed Feb 28 01:19:39 2018 +0000 modesetting: Use atomic modesetting to configure output/CRTCs To make sure we also use the same primary plane and to avoid mixing uses of two APIs, it is better to always use the atomic modesetting API when possible. v2: Don't use mode_output->connector_id Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Acked-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
I have the same issue with the same chip (HD 520 from a lenovo yoga x1) using the kms driver. I'm on Debian unstable and tried with various kernel versions. Downgrading to 1.19 restored the ability to rotate the display for me.
same here on a nouveau setup, trying to start sddm 90 degrees rotated for a pivot monitor results in a mouse pointer and no X screen
Same with Intel HD Graphics 620 (PCI ID 8086:5916).
I also have this issue with the following chip (Dell Latitude E5470): 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) I am on arch linux (4.16.13-2-ARCH) and the downgrade to 1.19 also restored the ability to rotate the display.
Can you please try this patch here: https://patchwork.freedesktop.org/series/44802/ It was successfully tested downstream for a similar issue.
(In reply to Olivier Fourdan from comment #5) > Can you please try this patch here: > > https://patchwork.freedesktop.org/series/44802/ > > It was successfully tested downstream for a similar issue. The patch fixes the issue for me.
(In reply to Olivier Fourdan from comment #5) > Can you please try this patch here: > > https://patchwork.freedesktop.org/series/44802/ > > It was successfully tested downstream for a similar issue. I can also confirm that this patch fixes the issue for me.
Thanks for the report, fixed in Git master: commit a85e94a50c94b07574c8701a3ff3c1243f4257f4 Author: Olivier Fourdan <ofourdan@redhat.com> Date: Fri Jun 15 08:57:12 2018 +0200 modesetting: use drmmode_bo_import() for rotate_fb
Please let me know if I should open another bug report, but my issue seems tightly related to this bug. * Description of my setup: - On my laptop (Thinkpad T460s, with HD Graphics 520) I have two outputs: an external monitor, rotated 90 degrees ccw and the internal panel, standard orientation. - I use sddm as a login manager and KDE. - Everything is working fine on the 1.19 branch; on the 1.20 branch sddm does not work properly, I can blindly log in; the plasma splash shows on both screens with the correct orientation, then freezes on the internal panel and plasma shows correctly only on the external monitor. The internal panel keeps showing the plasma splash and the mouse cursor (when the cursor is moved to that screen), but no windows, no panels. I bisected the issue and I found out that prior to commit a85e94a50c94b07574c8701a3ff3c1243f4257f4 rotation was broken on the external monitor (as described in this bug report) but plasma was functional on both screens. after commit a85e94a50c94b07574c8701a3ff3c1243f4257f4, plasma is only functional on the second screen (once again, correctly rotated) Please let me know of any other test that I could perform
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.