[Intel-gfx] i915: Dealing with 90° rotated display ?

[Hans de Goede]

Hi,

On 16-02-17 17:58, Ville Syrjälä wrote:
> On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 15-02-17 15:59, Ville Syrjälä wrote:
>>> On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
>>>> Hi Jani,
>>>>
>>>> As discussed here:
>>>>
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=94894
>>>>
>>>> I've a mini-laptop which uses a phone-screen,
>>>> so the native orientation of the screen is portrait,
>>>> where as for a clam-shell device one wants it to
>>>> be landscape. Ideally there would be a flag somewhere
>>>> to tell the i915 driver that the panel is mounted
>>>> 90° rotated in its bezel and have the i915 driver
>>>> apply that rotation on top of whatever rotation
>>>> userspace requests.
>>>>
>>>> So question is there already a place (variable) in
>>>> the i915 driver where one can set such a rotation
>>>> offset to apply on top of what userspace requests ?
>>>>
>>>> If not do you have any idea how feasible adding one
>>>> would be and can you give me a few pointers / hints
>>>> where to start with such a thing ?
>>>
>>> You could have a look at my branch (which I pointed out in the bug).
>>
>> Ok, so the patch that actually is relevant to this
>> discussion (and not just a cleanup / bug-fix) seems to be:
>>
>> https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e
>>
>> Right ?
>
> Looks that way, yes.
>
>>
>> AFAICT that will make fbcon inherit the rotation setting of
>> the primary plan on the primary crt. That may solve the
>> original bug as reported, but not the case / device I'm
>> talking about. What I would like to see is a "rotation offset"
>> field somewhere to be applied to all rotations in a way which
>> is hidden from userspace. Specifically the device I've has a
>> screen which is 720x1280 in resolution, but I want userspace
>> to see it as a 1280x720 screen because that is how it is used
>> in the hardware. So I want a 90° rotation to be applied which
>> is completely hidden from userspace.
>
> That's not necessarily the best way since rotation may impose
> additional restrictions on what the hardware can do. Which would
> mean that your 0 degree setting would no longer be the setting
> that should give the highest chance of success. That doesn't leave
> much chance of userspace being able to work out a fallback strategy
> when things don't succeed.
>
> Oh, and the cursor plane can't even do 90/270 degree rotation, so
> there's just no way to hide this fully.

Ok, I see that sucks, but I understand.

> That said, I did once implement a "full pipe rotation" thing, and even
> added a knob into debugfs that allowed me to flip it without userspace
> being involved. That's just something I used for testing the rotation
> code initially. I just pushed some version of it here [1]. Obviously
> 90/270 effective rotation for the cursor still won't work.
>
> [1] git://github.com/vsyrjala/linux.git full_pipe_rotation
>
>> So when userspace
>> (e.g. the Xorg server + modesetting driver) asks for 0° degree
>> rotation under the hood they get 90 applied, when they aks for
>> the panel resolution they get 1280x720 instead of 720x1280.
>
> The idea was that userspace will inherit the initial rotation.
> That does work correctly at least with the intel ddx.

Ah (userspace will inherit the initial rotation) I've yet to patch the
kernel to set up an initial rotation for this, I will give this a
try and see if that helps.

> Given that our
> rotation properties are per-plane, that would mean userspace would have
> to deduce that the entire screen is rotation by simply looking at the
> rotation of the primary plane. Or I suppose we could make the kernel
> use the same default rotation for all planes, even the disabled ines.

I think having userspace inherit the setting of the primary plane
is fine.

>> Basically the idea is that the kernel as the HAL it is supposed
>> to be (amongst other things) hide the hardware weirdness / quirk
>> of using a portrait panel in a landscape bezel.
>
> As said we can't really hide without causing additional grief to
> userspace in the form of potential failures in configuring the
> planes/crtcs.

Ack, not nice, but ack.

Regards,

Hans