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