Just take a device with panel orientation quirks https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c?h=v6.18 and start KDE. For example with a rightside_up device the display is rotated -90º. If we rely in the accelerometer going to laptop mode the orientation is correct according to the accelerometer values we get and we are fine with auto-rotation but just when we return to laptop mode the display get rotated -90º. If we set rotation manually the options are also bad, so -90º is indeed called normal. Also the resolution values are swapped and we only get few possible resolutions to select and not all the ones we could use. For example a native resolution of 1920x1200 is shown as 1200x1920. The resolution issue need to correct the resolutions swap, also filter out when a resolution is not one we should select, for example one that makes the panel to have black bands and to retrieve all the logical possible resolutions. This issues were solved time ago in gnome, I don't know if a generic way to deal with this issues should be done because now we are going to have the same issues to solve also with kmscon. Forget to mention that I have done the orientation tests with Wayland but X11 should behave similar, perhaps the resolution values are not swapped, if I test I comment it but I think the effort only worth for Wayland.
I have tested X11, and there we just have the output -90º, but, we have all the resolutions listed the ones that should be with the x y swapped and the other ones that makes the black side bands and scaled down output also x and y swapped. About the resolution under wayland should appear all the normal ones and swap x and y. For example 1920x1200 should be filtered out and 1200x1920 should be there but appear as 1920x1200, and same for all the other resolutions.
The device I tested had wrong accel matrix for orientation, now it has been fixed to respect that the normal orientation reported for example in monitor sensor, should be the normal orientation of the panel and not the normal orientation of the device. That means that not only the names for orientations and resolutions must be corrected but also the display output. With this kind of devices we should always take into account that the orientation of the device is the panel one plus the rotation that drm panel oriention dictates so when we have a device with tablet mode switch we must set the orientation with that taken into account when is not in tablet mode, and, when is in tablet mode we must take into account that the accelerometers are announcing us the normal orientation of the panel, so the device orientation in every position must also take into account drm panel orientation.
(In reply to howl from comment #2) > The device I tested had wrong accel matrix for orientation, now it has been > fixed to respect that the normal orientation reported for example in monitor > sensor, should be the normal orientation of the panel and not the normal > orientation of the device. The accelerometer needs to be relative to the device orientation, *not* to the display. > That means that not only the names for orientations and resolutions must be corrected but also the display output. Auto rotation does take it into account. > tablet mode switch That's a difficult one. IIRC some devices have a "tablet mode switch" that's about the "tablet" part disconnecting from the keyboard, so we can't really infer different device orientation from the switch. We also don't know if the accelerometer is in the display part of the laptop, or close to the keyboard instead, so I feel like this would need to be handled in iio-sensor-proxy with per-device quirks.
The report of accelerometer being normal the panel orientation for this device is solved and entered in the last minute for the next systemd release https://github.com/systemd/systemd/pull/40576 My bad that had to edit so much the issue but I think that left not clear. The tablet mode switch is being handled right, no issues there, automatic rotation starts to works in tablet mode and is off in laptop mode. The issue is that the screen orientation is wrong when a device has panel_orientation drm property. With this one for example the panel is mounted -90º so we have panel_orientation to Right Side Up to compensate. KDE doesn't follow the property so the screen output is never right, at booting is -90º and the interesting this is that when using autorotate is always +90º. I think is just managing it like normal oriented panel ones but apply then the drm panel orientation to rotate it just +90º to compensate the panel orientation. Also could be interesting to relabel the resolutions swaping X and Y 1200x1920 to 1920x1200 and relabel the orientations to match normal to the normal device. That leaves the device as if the panel is not mounted in another position.
> The issue is that the screen orientation is wrong when a device has panel_orientation drm property. With this one for example the panel is mounted -90º so we have panel_orientation to Right Side Up to compensate. As I wrote before, the orientation sensor must *not* take into account the display orientation. It must be relative to the device, not to the display. > KDE doesn't follow the property It absolutely does, and has for quite a long time. You're giving KWin wrong data, so it's doing the wrong thing. That "fix" in systemd is wrong and needs to be reverted.
(In reply to Zamundaaa from comment #5) > > The issue is that the screen orientation is wrong when a device has panel_orientation drm property. With this one for example the panel is mounted -90º so we have panel_orientation to Right Side Up to compensate. > As I wrote before, the orientation sensor must *not* take into account the > display orientation. It must be relative to the device, not to the display. > You are totally wrong: https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L55 Go read a little the udev's hwdb note. > > KDE doesn't follow the property > It absolutely does, and has for quite a long time. You're giving KWin wrong > data, so it's doing the wrong thing. That "fix" in systemd is wrong and > needs to be reverted. With your wrong assumption plus telling me that it takes into account I think you are applying drm panel orientation for what the accelerometer says in the incorrent orientation. Accelerometer value normal is when the panel is in it's normal orientation not device orientation.
More easy, this device panel mounted -90 degrees, panel orientation property Right Up, accelerometer normal when panel is normal oriented, so normal orientation of device accel value right-up. So accel matrix is correct. Display in KDE when accelerometer is in use for that +90 degress from the rotation it's correct, so instead only doing just +90 to compensate it does +180. When the KDE boots normal orientation is normal of the panel so display output is -90 degress from what it should. Also I don't like comparisons, but both GNOME and Windows relabels display settings to shown resolution and orientation names as it was from the point of view of normal device, or casing, orientation not from the panel orientation.
Sigh, so systemd added workarounds for desktops not handling unusual display orientations properly. Boo! Assuming the accelerometer is only used by the compositor, and only for auto rotate, is quite the stretch. I guess we just have to deal with it now. > Also I don't like comparisons, but both GNOME and Windows relabels display settings to shown resolution and orientation names as it was from the point of view of normal device, or casing, orientation not from the panel orientation. You don't have to make any comparisons. This bug report was not closed, someone just has to implement it.
(In reply to Zamundaaa from comment #8) > Sigh, so systemd added workarounds for desktops not handling unusual display > orientations properly. Boo! Assuming the accelerometer is only used by the > compositor, and only for auto rotate, is quite the stretch. I guess we just > have to deal with it now. > No, some people used it to correct their displays, so some devices are wrong. The real issue is the trust, if some send a matrix is should be to follow the panel orientation when the identity matrix or acpi in mount matrix is wrong. But, without having the device only trust in people reports can be use. I have fixed 3 devices recently because could find how they report the position. The good part, if the desktop does it right, the people that send incorrect matrices will argue again but will be their own fail. > > Also I don't like comparisons, but both GNOME and Windows relabels display settings to shown resolution and orientation names as it was from the point of view of normal device, or casing, orientation not from the panel orientation. > You don't have to make any comparisons. This bug report was not closed, > someone just has to implement it. That part I haven't found a standar way to go. For accel values the standard universal for all OSes is normal when the panel is normal, not the casing, but, for the orientation labels and resolution swap at showing it in settings there is no standard but seems to be coherent to relabel to make the device feel it's normal position is the normal casing position and make totally transparent for the user the manufacturer used a panel with another orientation.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8772
Git commit cd52f314bef2d967040923cd83824a4cebdf90a2 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 16/02/2026 at 13:23. Pushed by vladz into branch 'master'. outputconfigurationstore: don't apply the panel orientation for auto rotate While this fixed auto rotate on some devices, unfortunately systemd for a long time already also applies "quirks" for orientation sensors, to work around other desktops that do not handle panel orientations with auto rotate. KWin rotating the sensor readings again on top of that then results in the wrong orientation being used. In other words, sensor readings are expected to be relative to the display, not relative to the device. M +14 -14 autotests/integration/outputchanges_test.cpp M +6 -5 src/outputconfigurationstore.cpp https://invent.kde.org/plasma/kwin/-/commit/cd52f314bef2d967040923cd83824a4cebdf90a2
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8819
Git commit b380e32193b0d373515b7ea003d8e2a6cb94a21f by Xaver Hugl. Committed on 16/02/2026 at 15:34. Pushed by zamundaaa into branch 'Plasma/6.6'. outputconfigurationstore: don't apply the panel orientation for auto rotate While this fixed auto rotate on some devices, unfortunately systemd for a long time already also applies "quirks" for orientation sensors, to work around other desktops that do not handle panel orientations with auto rotate. KWin rotating the sensor readings again on top of that then results in the wrong orientation being used. In other words, sensor readings are expected to be relative to the display, not relative to the device. (cherry picked from commit cd52f314bef2d967040923cd83824a4cebdf90a2) M +14 -14 autotests/integration/outputchanges_test.cpp M +6 -5 src/outputconfigurationstore.cpp https://invent.kde.org/plasma/kwin/-/commit/b380e32193b0d373515b7ea003d8e2a6cb94a21f