Bug 94894 - [BSW] Upside down framebuffer
Summary: [BSW] Upside down framebuffer
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: low normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-11 14:34 UTC by Bastien Nocera
Modified: 2018-04-20 11:09 UTC (History)
3 users (show)

See Also:
i915 platform: BSW/CHT
i915 features: display/Other


Attachments

Description Bastien Nocera 2016-04-11 14:34:15 UTC
kernel 4.5.0

On the Teclast X98 Plus, the graphical framebuffer is upside down compared to the text framebuffer.

When booting, the text shows up close to where the camera is, but when the graphical mode kicks in, the image appears upside down, compared to the text framebuffer and the EFI firmware logo.

Note that while it is possible to rotate the device after a UI has showed up, it looks quite untidy.

Let me know what debug data you need.
Comment 1 Jani Nikula 2016-04-11 15:14:12 UTC
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?
Comment 2 Ville Syrjala 2016-04-11 15:24:03 UTC
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.
Comment 3 Jani Nikula 2016-09-20 12:51:51 UTC
No response from reporter, timeout, closing.
Comment 4 Bastien Nocera 2016-10-28 13:48:09 UTC
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)
Comment 5 pcercuei 2016-12-01 11:52:28 UTC
Happens as well on the Teclast x89 (not x98).
Comment 6 Hans de Goede 2017-02-03 09:55:14 UTC
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
Comment 7 Jani Nikula 2017-02-03 13:06:29 UTC
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.
Comment 8 Hans de Goede 2017-02-04 13:52:58 UTC
(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 ?
Comment 9 Hans de Goede 2017-04-23 16:11:38 UTC
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
Comment 10 pcercuei 2017-05-03 10:26:28 UTC
@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?
Comment 11 Hans de Goede 2017-05-03 10:36:58 UTC
(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.
Comment 12 Hans de Goede 2017-05-07 12:51:42 UTC
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
Comment 13 pcercuei 2017-05-07 19:07:15 UTC
Works good :)

Thanks!
Comment 14 Carlo Caione 2017-06-15 14:36:24 UTC
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.
Comment 15 Hans de Goede 2017-06-16 14:57:45 UTC
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
Comment 16 Elizabeth 2017-07-27 17:20:45 UTC
(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.
Comment 17 Hans de Goede 2017-12-05 17:06:20 UTC
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.
Comment 18 Hans de Goede 2018-01-21 21:58:46 UTC
I've submitted plymouth patches to also make plymouth use the new panel-orientation drm-connector property upstream now too, see bug 104714.
Comment 19 Jani Saarinen 2018-04-20 11:09:45 UTC
Closing, please re-open if still occurs.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.