GNOME Bugzilla – Bug 777166
GDM not rotated with fbcon=rotate:1
Last modified: 2017-05-07 13:29:50 UTC
I have a device with a portrait screen put in landscape, so I need to rotate it.
To do so I pass the `fbcon=rotate:1` parameter to the kernel; the console and my GNOME sessions are correctly rotated accordingly to this parameter, but GDM isn't.
Marcus Lundblad told me that GDM is probably "relying on events from the iio-sensor-proxy or something like that for an accelerometer".
My device has an accelerometer and it doesn't seem to work on Linux, so it's probably a bug in iio-sensor-proxy which should default to the rotation of the framebuffer, and a bug in the accelerometer not being supported.
Any feedback, validation or invalidation of these statements is welcome.
I don't see why GDM would be involved here. The fact that you need to rely on a work-around ("fbcon=rotate:1") means that the framebuffer is in the wrong orientation to start with.
It's very likely a missing feature in the Intel kernel driver, which I mentioned when you were trying to use the device the first time:
Created attachment 343357 [details]
The DSDT of the GPD Win
After our conversation on IRC stating that by default everything from the firmware's menu to the desktop session is incorrectly rotated because GPD used a portrait screen and put it in landscape, you suggested me to extract the DSDT. So here it is.
Created attachment 343358 [details]
Created attachment 343361 [details]
The output of `udevadm info --export-db`
(In reply to Adrien Plazas from comment #5)
> Created attachment 343361 [details]
> The output of `udevadm info --export-db`
There's no accelerometer in the device list, which means that either there's no accelerometer in the device (unlikely), or drivers are missing. In any case, the lack of accelerometer means that iio-sensor-proxy and its use are not responsible for the different orientation you're seeing.
What's more likely is that GDM forces Wayland usage, and that mutter-wayland gets information about the framebuffer in a way that ignores fbcon.
The first fix for this is to make sure the framebuffer (and the touch panel itself, by the same token) are correctly oriented. Which is something that needs to happen in the kernel.
(In reply to Bastien Nocera from comment #6)
> There's no accelerometer in the device list, which means that either there's
> no accelerometer in the device (unlikely), or drivers are missing. In any
> case, the lack of accelerometer means that iio-sensor-proxy and its use are
> not responsible for the different orientation you're seeing.
There is an accelerometer: I read many user complaining about the screen automatically rotating on Windows and "tips" on how to prevent this from happening.
> What's more likely is that GDM forces Wayland usage, and that mutter-wayland
> gets information about the framebuffer in a way that ignores fbcon.
AFAIK openSUSE Leap 42.2 doesn't support Wayland at all, so it's unlikely.
> The first fix for this is to make sure the framebuffer (and the touch panel
> itself, by the same token) are correctly oriented. Which is something that
> needs to happen in the kernel.
So I've been talking to some Intel kernel people about this and unfortunately it is impossible to transparently fix this on the kernel side. But with the existing rotation code in gnome-shell all that is really needed is for iio-sensor-proxy to provide a correct initial rotation when the device is sitting flat on a horizontal surface, I've written a small patch for this:
Together with this hwdb entry (and a recent kernel with proper accelerometer support) this fixes gdm being oriented wrong for me:
# For the GPDwin we match all dmi fields accept for bios_date, because the
# dmi-strings are not really model specific. Note that out of 15 boards
# tested only the GPDwin has board_vendor=AMI... and board_name=Default...
# so this is unique enough to identify the GPDwin
ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1
As discussed here: https://bugs.freedesktop.org/show_bug.cgi?id=94894 for regular devices which have their LCD-panel mounted upside down this should indeed be fixed in the kernel and I've written a kernel-patch which should fix rotation issues with upside-down LCD-panels.
But the display hardware does not support 90 degrees rotation, so for the GPDwin we are going to need something else. I've been thinking about this and I've a simple solution for this which I believe is the best way to fix this. I've opened a new bug giving a bit of background info on LCD panel rotation in general and describing me proposed solution, lets discuss this further in that bug: bug 782294.