https://bugs.kde.org/show_bug.cgi?id=504611
--- Comment #16 from Sergio <sergio.calleg...@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
