Hans de Goede <hdegoede@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
