[Intel-gfx] [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation

Hans de Goede hdegoede at redhat.com
Sun May 7 09:05:13 UTC 2017


Hi,

On 30-04-17 21:34, Hans de Goede wrote:
> Hi,
> 
> On 27-04-17 18:39, Bastien Nocera wrote:
>> On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote:

<snip>

>>> Well, there are really two cases to consider:
>>>
>>> 1. BIOS/whatever configures display hardware rotation in a way
>>>     that matches the orientation of the physical display
>>> 2. BIOS didn't do that. Either the hardware can't do what
>>>     would be required, or the BIOS just chose not to do it.
>>>
>>> Case 1 should work with these patches as long as the DDX will set up
>>> the
>>> initial randr rotation to match what it read out from the kms
>>> rotation
>>> property of the primary plane. >

So I've been running some tests with the 2 original patches focussing
only on the normal screen is upside down, BIOS has configured hardware
rotation case which is what all devices except on special device
seem to have.

As expected with these 2 patches fbcon and the plymouth splashscreen
work fine. If I then start:

a) Xorg with modesetting driver: I get the screen the right way
up, but the cursor plane is upside down both in coordinates (where
the cursor gets shown) as well as the cursor glyph being upside down

b) Xorg with intel driver, the intel driver re-sets the primary plane's
drm "rotation" property, so everthing is upside down. At least the
primary and cursor planes are consistent with each other now
(the touchscreen coordinates how ever are not).

c) Gnome as Wayland compositor, same as Xorg with intel driver

So think more about this I think that Ville's 2 original cases
really are:

1. All planes support the necessary rotation in hardware, so we
can fix things up fully in hardware, aka the upside down case
which I believe is the majority of all troublesome hardware
out there.

2. The necessary rotation is not supported in hardware. This
is the case with the GPD-win where we've a 90 / 270 degrees
rotation. Here even the EFI configuration menu, grub, efifb,
etc. all are rotated.

My conclusion of all this is that:

1. For 1. we can and should fix this entirely and transparently
in the kernel, we need kernel fixes for fbcon/fbdev anyways, so
we might just as well go all the way, otherwise all of Xorg + modesetting,
Xorg + intel and Gnome as Wayland compositor will need separate
fixes. So this is best dealt with in the kernel, esp. since there
are more Wayland compositors out there.

2. There is nothing the kernel can do here, so this one we really
need to fix in userspace. I've some ideas for this, but those
fall outside the scope of this discussion.

I've already implemented the all kernel fix for 1. It is a single
patch only touching the i915 driver, since if we transparently deal
with the extra rotation in the i915 code we no longer need the
drm_fb_helper changes as things will just work for the fbcon too,
which is really nice to see and to me shows this is the right way
to solve this. The patch adds just 80 lines of code and completely
fixes this issue :)

I'll send out the patch right after this mail.

Regards,

Hans


More information about the Intel-gfx mailing list