[PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

[Eric Anholt]

Hans de Goede <hdegoede at redhat.com> writes:

> HI,
>
> On 08-05-17 14:27, Chris Wilson wrote:
>> On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote:
>>> On some (Bay Trail) devices the LCD panel is mounted upside-down.
>>>
>>> This commit uses the code to read back the initial rotation of the
>>> primary plane in get_initial_plane_config from Ville Syrjala's
>>> "drm/fb-helper: Inherit rotation wip" patch and when re-using the
>>> initial fb it stores that in intel_crtc.initial_rotation.
>>>
>>> It adds an intel_plane_get_rotation helper which combines this
>>> initial_rotation with any rotation requested by userspace and
>>> uses this in all places which look at a planes rotation, thus
>>> transparently dealing with upside-down LCD panels without requiring
>>> any user-space or fbcon changes.
>>>
>>> This fixes the kernel boot messages switching from being shown the right
>>> way up in efifb to being shown upside down as soon as a native kms driver
>>> loads, as well as any graphics displayed by userspace being upside-down.
>>>
>>> Note this only deals with upside-down LCD panels / 180 degrees
>>> rotation as the hardware in question only supports 180 degrees
>>> rotation in hardware. The one model known which has a panel mounted
>>> with 90/270 degrees rotation will need to be fully dealt with in
>>> userspace, even the firmware boot screen / menus are rotated 90 degrees
>>> on this one and there simply is nothing the kernel can do about this.
>> 
>> I shall just mention a concern with hiding the transformation on the
>> connection, we do expose the subpixel layout to userspace and that
>> should be adjusted based on this lie. There are probably other places
>> where the orientation of the output leaks through the current interface.
>> 
>> The commit message fails to explain how userspace, which should already
>> have the tools available to it, is unable to reapply the existing
>> rotation - i.e. why this is a kernel problem,
>
> This is a kernel problem because one of the things the kernel does
> is hardware abstraction, as I mentioned in my reply to Ville, there is
> not single userspace to fix here, there is a large supply of userspace
> consumers of the kms API which need fixing to fix this in userspace.
>
> For touchscreens which are mounted with a wrong orientation the
> input layer fixes things up, I don't see how this is any different
> really. Now if it was impossible or very complicated to fix this
> in the kernel that would be a different story, but as this patch
> shows it is quite doable to fix this in the kernel.

FWIW, Raspberry Pi has a similar problem: The panel has an appropriate
orientation due to its viewing angle, but the cabling is such that many
people mount it upside down and use a firmware configuration to have
everything flipped.  It would be nice if I could do readback of the
panel's orientation reg (I haven't tested) and retain automatically that
after boot, as a default policy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170508/9670e6bc/attachment.sig>