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

[Hans de Goede]

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.

Regards,

Hans