After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777166 - GDM not rotated with fbcon=rotate:1
GDM not rotated with fbcon=rotate:1
Status: RESOLVED NOTGNOME
Product: gdm
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2017-01-12 10:07 UTC by Adrien Plazas
Modified: 2017-05-07 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The DSDT of the GPD Win (118.80 KB, application/octet-stream)
2017-01-12 12:15 UTC, Adrien Plazas
Details
Decompiled DSDT (1013.28 KB, text/x-dsl)
2017-01-12 12:52 UTC, Adrien Plazas
Details
The output of `udevadm info --export-db` (164.11 KB, text/plain)
2017-01-12 13:48 UTC, Adrien Plazas
Details

Description Adrien Plazas 2017-01-12 10:07:51 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.
Comment 1 Adrien Plazas 2017-01-12 10:24:09 UTC
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.
Comment 2 Bastien Nocera 2017-01-12 11:36:05 UTC
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:
https://bugs.freedesktop.org/show_bug.cgi?id=94894
Comment 3 Adrien Plazas 2017-01-12 12:15:05 UTC
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.
Comment 4 Adrien Plazas 2017-01-12 12:52:53 UTC
Created attachment 343358 [details]
Decompiled DSDT
Comment 5 Adrien Plazas 2017-01-12 13:48:41 UTC
Created attachment 343361 [details]
The output of `udevadm info --export-db`
Comment 6 Bastien Nocera 2017-02-15 13:11:37 UTC
(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.
Comment 7 Adrien Plazas 2017-02-15 13:44:52 UTC
(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.
Comment 8 Hans de Goede 2017-04-21 15:52:29 UTC
Hi,

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:

https://github.com/hadess/iio-sensor-proxy/pull/162

Together with this hwdb entry (and a recent kernel with proper accelerometer support) this fixes gdm being oriented wrong for me:

/lib/udev/hwdb.d/99-local.hwdb:

# 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
sensor:modalias:acpi:KIOX000A*:dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd*:svnDefa
 ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1
 ACCEL_INITIAL_ORIENTATION=right-up

Regards,

Hans
Comment 9 Hans de Goede 2017-05-07 13:29:50 UTC
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.