SUMMARY Tested with a wayland session and a tablet/convertible. Display autorotation does not work anymore. The sensor-monitor utility reports the rotation correctly. STEPS TO REPRODUCE 1. Detach keyboard 2. Rotate display OBSERVED RESULT The desktop stays as nothing had happened EXPECTED RESULT The desktop is rotated SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.12.28-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Celeron® N4120 CPU @ 1.10GHz Memory: 5.6 GiB of RAM Graphics Processor: Intel® UHD Graphics 600 Manufacturer: CHUWI Innovation And Technology(ShenZhen)co.,Ltd Product Name: Hi10 X ADDITIONAL INFORMATION I am sure this used to work until not long ago.
If you downgrade your kernel to an older one, does that fix it?
I have tried, but it is not the kernel. As a matter of fact the sensor-monitor utility reports the rotation correctly and it is kwin/plasma not applying it. As a matter of fact, playing with the display option dialog, you *can* make plasma do the autorotation. You need to put the tablet in tablet mode, switch to "manual" then back to "automatic" and you must disable the tick that controls if the autorotation should only happen in tablet mode. Apply, and at this point the autorotation works. So there is definitely a first problem with the detection of the "tablet mode": plasma thinks that the device is not in tablet mode even when it is. Then there is a second problem in that the above procedure to get the autorotation to work does not work if you have the keyboard attached (i.e., if you are not in tablet mode) even if you have unticked the "only in tablet mode". Finally there is a problem in that when the rotation works, it works skewed by 90 degrees. This last issue might be due to the fact, that I have added a "video" entry among the kernel boot params to get an initial 90 degree rotation, in order to be able to enter the password to decrypt the filesystem. Maybe that introduces the skew, maybe it is just the sensor that is mounted in a skewed way. I need to check, even if I am sure that the thing was working properly not long ago. In any case the skew might be fixable by introducing a rotation matrix for the sensor.
I have made more tests. There are two (maybe three) different issues. Please let me know if I should open separate bugs: 1. The tablet mode detection does not work with my tablet. So with the default setup in which it gets activated, the autorotation does not work and one gets the impression of a regression. Probably there is no regression in strict sense, but the fact that autorotation is now by default enabled only in tablet mode and that the test for the tablet mode does not work properly gives this impression. - Now, it is unclear to me how the test for the tablet mode works on the kde/plasma side. I understand that there is no standard interface on linux for this, like a "/sys/class/chassis/tablet_mode" standard pseudo-file, but that linux should report this via evdev. Is it correct? Now, if this is the case, I really do not understand how it can work, because evdev is meant to report *events* (namely changes). So, how can one sample at a point in time the tablet/not tablet state, without having watched the previous event history. And how can one say if the hardware supports communicating the mode (tablet/not tablet) at all? Because if the hardware does not, the GUI should probably not propose the "only in tablet mode" tickbox at all. 2. When you select an "initial" rotation from the kernel boot parameters, with something like "video=DSI-1:panel_orientation=right_side_up", then the plasma auto-rotation gets skewed by that same amount. Kwin should consider that initial rotation. Alternatively to having kwin consider the initial rotation practiced by the kernel itself, one might want to consider the following point: 3. When you have the display rotation set to "automatic" the possibility to select an orientation is grayed out, but I think it could be advantageous to still let the user select a rotation, to be used in this case as the "base" one, to work around situations like 2.
> Now, it is unclear to me how the test for the tablet mode works on the kde/plasma side Try > sudo libinput debug-events you should get events as the switch changes state. As for getting the current state, that's done with libinput API in the compositor, not sure if there's any command line tool to tell you about it. > And how can one say if the hardware supports communicating the mode (tablet/not tablet) at all? Because if the hardware does not, the GUI should probably not propose the "only in tablet mode" tickbox at all. You can manually switch tablet mode in the settings as well. > When you select an "initial" rotation from the kernel boot parameters, with something like "video=DSI-1:panel_orientation=right_side_up" I don't have a device with a (working) auto rotate sensor, so I can't verify that works as expected, but it was tested by others when it was implemented and has matching autotests, so I'm pretty sure it still works the same. That kernel option doesn't set an initial rotation though, it tells KWin that the display hardware is rotated vs. the rest of the device (and vs. the sensor!) - are you sure that it's not working correctly, with that in mind?
Setting status, since we're waiting on information.
> Try >> sudo libinput debug-events > you should get events as the switch changes state. I will experiment with that to see if my tablet/convertible reports it at all > When you select an "initial" rotation from the kernel boot parameters, with something like "video=DSI-1:panel_orientation=right_side_up" I don't have a device with a (working) auto rotate sensor, so I can't verify that works as expected, but it was tested by others when it was implemented and has matching autotests, so I'm pretty sure it still works the same. That kernel option doesn't set an initial rotation though, it tells KWin that the display hardware is rotated vs. the rest of the device (and vs. the sensor!) - are you sure that it's not working correctly, with that in mind? Yes, I am sure there is an issue here: - If I remove the video line in the kernel options passed by grub, the prompt I get for entering the LUKS password on the linux console is readable keeping the tablet "vertical" which is very impractical when the tablet is attached to the keyboard that forces it to be "horizontal". However, in this mode the plasma autorotation works well - When I add the line, the linux console becomes readable with the "horizontal" tablet arrangement, but the plasma autorotation becomes wrong. For instance, the bottom of the desktop goes on the right side of the screen.
Maybe I can work that around myself, by assuring that at the same time when the video line is introduced a rotation matrix is defined for the sensor. Clearly, it would be preferable to have it managed automatically.
(In reply to Sergio from comment #6) > Yes, I am sure there is an issue here: > > - If I remove the video line in the kernel options passed by grub, the > prompt I get for entering the LUKS password on the linux console is readable > keeping the tablet "vertical" which is very impractical when the tablet is > attached to the keyboard that forces it to be "horizontal". However, in this > mode the plasma autorotation works well > > - When I add the line, the linux console becomes readable with the > "horizontal" tablet arrangement, but the plasma autorotation becomes wrong. > For instance, the bottom of the desktop goes on the right side of the screen. The kernel boot argument simply isn't meant for that purpose. We can't fix that.
I think that I have not expressed myself properly, so maybe my explanation was confused. The kernel supports a `video` option on its command line. Within that option there is a `panel_orientation` suboption that can be only applied to integrated panels and it is used to specify their physical orientation being useful in 2-in-1 laptops, tablets, or convertible devices. Its purpose is to let one provide hints to the kernel for cases where the built-in display reports the wrong orientation (e.g., rotated 90° or 180°), leading to incorrectly oriented content at boot or in early user-space. I need to use it because my Chuwi Hi10x has exactly that issue. The built in display thinks that its regular orientation is "vertical". I need to pass the option as `video=DSI-1:panel_orientation=right_side_up` otherwise early boot messages (and critically the LUKS password prompt) are shown sideway when the system is attached to its keyboard (with must be the case, if you want to enter the LUKS passord). Furthermore, without the option also the linux consoles (the ones accessible via FN+3, FN+4, etc) would be shown sideways. It is not that the system "does not work" without this option on the kernel command line. It's that it is a pain to use it. If I do not have that option, autorotation works fine in KDE. But if I include that option, the autorotation practiced by KDE is wrong. It is wrong because the initial rotation set by the "video" parameter is not accounted for by the KDE rotation logic, so one gets an angular skew identical to that initial rotation. How could KDE help: ------------------------------ In my opinion there are two possibilities: 1) Assure that the the display configuration dialog, when the orientation is set to "automatic", there is a further dropdown called "autorotation adjustment" where you can select among "0, 90, -90 and 180", so you can adjust things from there; 2) KDE reads `\proc\commandline` and if there is a `panel_orientation` option, it reads it and it accounts for it when doing automatic orientation. About the two options: 2. looks nice because it would "just work"; 1. is possibly simpler to implement; it is possible to implement both, which IMHO would be the optimal thing to do.
> The kernel supports a `video` option on its command line. Within that option there is a `panel_orientation` suboption that can be only applied to integrated panels and it is used to specify their physical orientation being useful in 2-in-1 laptops, tablets, or convertible devices. Its purpose is to let one provide hints to the kernel for cases where the built-in display reports the wrong orientation (e.g., rotated 90° or 180°), leading to incorrectly oriented content at boot or in early user-space. It's not just about kernel or early user space. It signals the panel orientation for the system, for all software. If you work around the panel orientation without also patching the orientation of the sensor, then that's not something we can fix. I don't think we should add workarounds for that either - if kernel command line args cause problems, then the workaround for that should be in the kernel (or you need to have another arg for rotating the sensor). I would also recommend you to upstream the quirks for your hardware; these kinds of quirks are in lists that are relatively simple to patch.
I have looked a bit more into this and for what concerns the rotation matrix, I think that it should be probably the iio-sensor-proxy to fix the data for all the possible consumers. I am now trying to interact with its developers.
I have had some interaction with the iio-proxy-developers. Their point is that the sensor data is correct. It should be the user of the data that practices the display orientation to use that data correctly taking into account that there is already a display rotation practiced at the DRM level. Their take is that it is the wayland compositor that already talks to the DRM interfaces, so it has all the means to know. Maybe they are right. In the end the display might not (e.g. in the future) be the single user of the orientation data. There might be a day when in tablets speakers arrays become the norm. In this scenario, the signal processing chain might need to know the orientation to produce correct stereo. And it would need the "real" orientation. It is only the display that needs to know of any rotation introduced at the display connector level.
The last message on the iio-proxy mailing list appears to negate the point that "if kernel command line args cause problems, then the workaround for that should be in the kernel" What they say is: "No. iio-sensor-proxy takes the orientation towards the physical hardware panel. Only the compositor has enough rope to figure out the correct orientation. How would iio-sensor-proxy [or the kernel] ever know if a compositor honors the drm property?" E.g. they say that "phoc" has an option to ignore that property.
Would then an easy solution be to have a "tickbox" in the display configuration dialog saying "ignore panel_orientation overrides"? Wouldn't that fix everything?
(In reply to Sergio from comment #12) > I have had some interaction with the iio-proxy-developers. > > Their point is that the sensor data is correct. It should be the user of the > data that practices the display orientation to use that data correctly > taking into account that there is already a display rotation practiced at > the DRM level. Their take is that it is the wayland compositor that already > talks to the DRM interfaces, so it has all the means to know. There is no display rotation practiced at the DRM level. panel_orientation is purely information for the compositor to apply, not something the driver does under the hood. > Maybe they are right. In the end the display might not (e.g. in the future) > be the single user of the orientation data. There might be a day when in > tablets speakers arrays become the norm. In this scenario, the signal > processing chain might need to know the orientation to produce correct > stereo. And it would need the "real" orientation. It is only the display > that needs to know of any rotation introduced at the display connector level. The issue here is *not* that the sensor orientation needs to be adjusted to match the display, exactly the opposite. Your sensor is oriented so that it matches the display, instead of the device. (In reply to Sergio from comment #14) > Would then an easy solution be to have a "tickbox" in the display > configuration dialog saying "ignore panel_orientation overrides"? Wouldn't > that fix everything? No, KWin is not the correct place to work around the orientation sensor being wrong.
Almost at the same time of your response, I am getting the following message from the iio-sensor-proxy developers: > iio-sensor-proxy should indeed not take the panel orientation into account, it should report the device orientation > and leave it up to the users of the sensor data to correct for their use cases, which could have nothing to do with the display. And they are right. The accelerometers are meant to report the orientation of the *device* with respect to its "natural" orientation. That they are right can be easily seen by checking the sensor data that I get on the Chuwi Hi10x against the specification (https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/sensor-orientation). The sensor data should not change if you change the kernel panel orientation property associated to the display connector, because it is associated to the device (the display chassis). To see why this is the case, just suppose that some ACME company decides to manufacture a tablet with a serial LCD display on the rear side of the display and that the driver of this display uses the accelerometer data to adjust the orientation. The fact that you change the linux kernel "panel_orientation" property of the front display should not lead to a change in the data reported by the sensors, otherwise the rear display orientation would end up broken. Now, let's look at the "video" parameter on the kernel command line. That is meant to provide an "early" specification of video parameters, before there is software running that could provide a more thorough interface or make better choices. For instance, on the video parameter you can specify a display resolution. It is not that the compositor that comes after is tied to it for ever. It can very well override it, and in fact almost every compositor lets you choose the resolution or can pick the best one by querying the display hardware regardless of what you put on the kernel command line. The same possibility should exist for every other parameter for which "what comes after the kernel" can provide a better interface than the kernel command line. There is no reason why the compositor should not be allowed to override the "panel_orientation" based on settings taken from the user or information from the sensors. The kernel documentation itself makes it explicit that the "panel_orientation" is a *hint* (https://docs.kernel.org/fb/modedb.html). As already mentioned, developers of the "phoc" compositor that have an almost 100% user base on devices that can be rotated know that there are cases for doing differently from what the panel_orientation property hints at. In my specific case, the device natural orientation is vertical. And the sensor data *is right*. The sensors report "normal" when the device is vertical. However, practically booting involves having it horizontal (because the keyboard is needed for the LUKS password, until we have an OSK for that). Because the kernel in setting up its consoles does not look at the sensors, the only way to tell the kernel to rotate the display of the consoles to have the display readable when entering the LUKS password is to use the video panel_orientation property. I need to set to "right_side_up" (the message to the kernel is "because you do not look at the sensors, you must listen to my hint: put things on the display as if the display is not in its natural orientation, but with the right side up, aka rotated 90 degrees counterclockwise". The kernel obeys and rotates the way in which it displays its consoles 90 degrees clockwise to compensate). Now, after the kernel comes KDE, and because I have the tablet horizontal, the sensors correctly say that the device is rotated 90 degrees counterclockwise wrt its natural orientation. Now if I tell KDE to adjust the display orientation based on the sensors, what does Kwin do? First it rotates the display 90 degrees clockwise because it obeys the kernel "panel_orientation" property. Then it rotates it another 90 degrees clockwise because it obeys the sensors too. See why that is wrong? (In reply to Zamundaaa from comment #15) > (In reply to Sergio from comment #12) > > I have had some interaction with the iio-proxy-developers. > > > > Their point is that the sensor data is correct. It should be the user of the > > data that practices the display orientation to use that data correctly > > taking into account that there is already a display rotation practiced at > > the DRM level. Their take is that it is the wayland compositor that already > > talks to the DRM interfaces, so it has all the means to know. > There is no display rotation practiced at the DRM level. panel_orientation > is purely information for the compositor to apply, not something the driver > does under the hood. > > > Maybe they are right. In the end the display might not (e.g. in the future) > > be the single user of the orientation data. There might be a day when in > > tablets speakers arrays become the norm. In this scenario, the signal > > processing chain might need to know the orientation to produce correct > > stereo. And it would need the "real" orientation. It is only the display > > that needs to know of any rotation introduced at the display connector level. > The issue here is *not* that the sensor orientation needs to be adjusted to > match the display, exactly the opposite. Your sensor is oriented so that it > matches the display, instead of the device. > > (In reply to Sergio from comment #14) > > Would then an easy solution be to have a "tickbox" in the display > > configuration dialog saying "ignore panel_orientation overrides"? Wouldn't > > that fix everything? > No, KWin is not the correct place to work around the orientation sensor > being wrong.
That is my comment. I am not an iio sensor proxy developer... And you really should've explained how your device works much earlier. > Now, let's look at the "video" parameter on the kernel command line. That is meant to provide an "early" specification of video parameters, before there is software running that could provide a more thorough interface or make better choices. Yes, but not panel_orientation. It hints to KMS that the display is rotated vs. the device, it is not there for configuring early boot rotation. "rotate" is the option you need. See https://gitlab.com/linux-kernel/linux/-/blob/master/Documentation/fb/modedb.rst for details.
I see your point that panel_orientation is to say if the panel is mounted rotated wrt to the device. I will try with "rotate" out of curiosity. In any case the assumptions about the "normal" orientation of my device are at best weird. The normal orientation (vertical) is apparently based on the fact that it is the one that makes the windows logo on the bezel look OK. It was probably chosen because when you have an on screen keyboard, it takes less screen estate when the screen is vertical. The fact that in the normal orientation the left speaker is on top and the right speaker is on the bottom seems of no concern to the manufacturer. Given that with linux there are basically no on-screen-keyboards that can be used at boot to enter a password for full disk encryption, and that no one cares about the windows logo I dare to say that on linux the "normal" orientation should be horizontal (which gives you the ability to use the keyboard and proper stereo). So, I think I will configure my machine saying that the panel is rotated sideways and fixing the sensor data, under the assumption that "normal" is horizontal.