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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
