Hi,
On 08-05-17 12:44, Ville Syrjälä 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.
This pretty much looks like a very limited attempt at full pipe
rotation.
Correct, it is limited to 180 degree rotation because that is what
almost all hardware out there which needs rotation to correct
for LCD-panel mounting needs and all pipes on GEN4+ support
180 degree rotation and on GEN < 4 we will never set initial_rotation
so this patch is a nop.
I have posted a more generic version of that in the past
but it was pretty much shot down by everyone else.
I agree that trying to deal with 90/270 degree rotation in the
kernel is not a good idea, but 180 degree rotation is much
easier to deal with and all devices I know of where the kernel
can even detect it needs to do rotation use 180 degree rotation.
So I'm not convinced this apporach is really the way to go.
This ways in at about the same amount of lines added as the previous
2 patches, but unlike the previous 2 patches it actually fully solves
the problem. As my testing has shown we really should not punt this
problem to userspace because then we will get a never ending job
of needing to fix the userspace kms consumer of the week. I'm aware
of at least 6 implementations which would need fixing without
even trying: intel-ddx modesetting-ddx gnome-wayland-compositor
kde-wayland-compositor, sway-wayland-compositor, weston.
There are a few limitations even for the 180 degree rotation so
trying to hide it inside the kernel isn't 100% possible.
Looking at supported_rotations for all planes I don't see any
limitations, or are the maybe stride limitations or some such ?
The only limitation I see is that on Cherry Trail Pipe B
supports reflect-x but not when combined with 180 degree
rotation, this will get caught in intel_plane_atomic_check_with_state
just as before only now reflect cannot be combined with
0 degree rotation instead of 180 degree rotation.
Regards,
Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
