Bug 94894

Does the early boot image always show up with the same orientation regardless of device orientation?

Shot in the dark, does i915.fastboot=1 module parameter help?

A while ago I cobbled together something to take over the rotation setting from the firmware, since I have a BYT tablet that has its display mounted upside down. I never actually finished it though, so it's been just sitting on a branch collector rot. I can't remember if I even tested it on anything beyond one IVB laptop.

Anyway here it is in case someone is brave enough to try it:
git://github.com/vsyrjala/linux.git fbdev_inherit_rotation

I wouldn't mind someone grabbing it and finishing it off. It's looking unlikely I'll be able to get back to it very soon myself.

No response from reporter, timeout, closing.

In https://github.com/hadess/iio-sensor-proxy/issues/108
a user reported that passing i915.fastboot=2 to the kernel avoided the 180 degrees rotation on boot.

The device is the "WISKY  MID  M801R" I believe (http://www.wisky.hk/newsshow.asp?pageid=46)

Happens as well on the Teclast x89 (not x98).

Hi all,

So I've recently bought this device:
http://www.gpd.hk/gpdwin.asp

Which is a nice toy, but it uses a portrait screen in landscape orientation and they did not even bother to fix the firmware, the BIOS setup is simply shown on its side.

So it looks like getting the rotation from the firmware will not be enough in some cases, I believe we will
need a DMI based table for this, at least for my model, at which point we might just as well use it everywhere assuming this is not something which happens often (famous last words).

An other issue is we need to somehow communicate the info about how the screen is mounted rotated or upside down in the frame to userspace, so that e.g. display control panels will show it as not rotated (because that is how it looks to the user) while in reality the kms driver is rotating it by 90 degrees (because the device is using  a portait screen in landscape mode).

Regards,

Hans

Yup, stuff like this has three different orientations to take into account: 1) framebuffer orientation relative to the native orientation of the display, 2) native orientation of the display relative to the device, 3) device orientation relative to the user.

(In reply to Jani Nikula from comment #7)
> Yup, stuff like this has three different orientations to take into account:
> 1) framebuffer orientation relative to the native orientation of the
> display, 2) native orientation of the display relative to the device, 3)
> device orientation relative to the user.

So we agree we need todo something here, that is good :) Any suggestion on what a solution would look like ?

Hi All,

So I recently bought a (second-hand) Bay Trail tablet which has its LCD mounted upside-down. As such I've ported Ville Syrjala's patches to deal with this to current mainline and I'm going to send them upstream for merging.

These patches fix the kernel-console as well as the boot-splash (at leats plymouth does not reset the rotation) being upside down as soon as a native kms driver such as the i915 driver is loaded.

This fixes the orientation of the displayed image from boot till the Xserver or a Wayland compositor takes over.

I've a patch for iio-sensor-proxy which fixes the rotation under Xorg / Wayland when using a desktop environment which honors iio-sensor-proxy's rotation detection:
https://github.com/hadess/iio-sensor-proxy/pull/162

The 2 patches I'm posting upstream for this can be found here:
https://github.com/jwrdegoede/linux-sunxi/commits/master

Regards,

Hans

@Hans:

I tried your patches on top of 4.11-rc8, and it does fix the rotation until X11 starts.

But X11 still sees it as rotated, do you have a fix for that?

(In reply to pcercuei from comment #10)
> @Hans:
> 
> I tried your patches on top of 4.11-rc8, and it does fix the rotation until
> X11 starts.

Yes, that is expected (more or less).

> But X11 still sees it as rotated, do you have a fix for that?

We're discussing on the dri-devel mailinglist how to fix X11 and Wayland still ending up upside down.

Ok,

I've 2 new patches for this, 1 small prep patch and one transparently dealing with the upside-down ness inside the i915 driver so that no changes in userspace are necessary (and e.g. X11 should work fine) now, you can grab the new ones here (some place as the old ones which I've dropped from me tree):

https://github.com/jwrdegoede/linux-sunxi/commits/master

This is still being discussed upstream, but from my pov this is the best solution, as it makes everything just work.

Regards,

Hans

Works good :)

Thanks!

I'm a bit lost on the status of this problem for 90/270 degree panel rotations and if we have a valid (or already upstreamed) solution.

I'm working on a Haier laptop (Haier HR101CW) with a cherryview controller [Intel Corporation Device 22b0 (rev 36)] that uses a portrait screen in landscape orientation. Everything is basically in portrait mode, including the BIOS setup.

Any set of patches that can be useful in this case? I tried the patches proposed in this thread but they do not work for my case (or for some reason I was unable to make them working fine).

Thanks.

Hi,

(In reply to Carlo Caione from comment #14)
> I'm a bit lost on the status of this problem for 90/270 degree panel
> rotations and if we have a valid (or already upstreamed) solution.
> 
> I'm working on a Haier laptop (Haier HR101CW) with a cherryview controller
> [Intel Corporation Device 22b0 (rev 36)] that uses a portrait screen in
> landscape orientation. Everything is basically in portrait mode, including
> the BIOS setup.
> 
> Any set of patches that can be useful in this case? I tried the patches
> proposed in this thread but they do not work for my case (or for some reason
> I was unable to make them working fine).
> 
> Thanks.

90/270 degrees rotation is a separate problem from upside down mounted LCD panels, as the BIOS also being wrong shows, this cannot be fixed in hardware, so this will needs to be fully fixed in userspace which falls outside of the scope of this bug.

What I'm doing on my gpd win is using an ACCEL_MOUNT_MATRIX to rotate the accelerometer output to match the screen rotation and then just use gnome's build in rotation, this does require tilting the laptop base at boot to get iio-sensor-proxy to get an initial orientation value since when it is sitting horizontal iio-sensor-proxy cannot determine the orientation.

I hope to have time in the future to make gnome read an initial orientation from udev (hwdb) and use that as long as iio-sensor-proxy does not have orientation info yet. This should also fix this on devices which don't have an accelerometer.

You can get the kernel text console to rotate by adding the following to the kernel cmdline:
fbcon=rotate:1

Regards,

Hans

(In reply to Hans de Goede from comment #12)
> ... 
> This is still being discussed upstream, but from my pov this is the best
> solution, as it makes everything just work.
> Regards,
> Hans
Changing to NEEDINFO while the final decision is made. Thanks.

Ok, so upstream discussion about this has lead to the following decision:

1) No hiding of panel-orientation from userspace, if the panel is upside down, userspace needs to adjust using either software or drm_plane rotation

2) Detect the panel-orientation where possible (by reading the primary plane rotation used be the EFIFB back from the hardware) and export this through user-space to a new "panel orientation" drm property on the connector for the panel.

The patches for this have been merged into drm-misc-next and will show-up in kernel 4.16-rc1 once released.

From a kernel/DRI pov this closes this bug.

Userspace-support to act upon the new "panel orientation" drm property is a separate issue. I've written patches for mutter (for GNOME3 and deratives), you can find these here: https://bugzilla.gnome.org/show_bug.cgi?id=782294

I'm also working on plymouth patches for this so that the splash / diskcrypt boot screens will show the right way up too.

I've submitted plymouth patches to also make plymouth use the new panel-orientation drm-connector property upstream now too, see bug 104714.

Closing, please re-open if still occurs.