Hi,
On 27-04-17 18:39, Bastien Nocera wrote:
On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote:
On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
<snip>
I've a patch for iio-sensor-proxy which fixes the rotation
under
Xorg /
Wayland when using a desktop environment which honors iio-
sensor-
proxy's
rotation detection:
https://github.com/hadess/iio-sensor-proxy/pull/162
Or is it just this thing that clobbers what the DDX inherited
from
the
kernel as the initial rotation?
I think it's mostly got to do with the compositor (or X) not
knowing
what "normal" or "0 degrees rotation" corresponds to.
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. >
Yes. My problem was that instead of fixing the DDX to behave properly,
reusing the same orientation as already configured, we were using iio-
sensor-proxy to trigger the initial rotation. This doesn't work if
there's no accelerometer, or orientation is locked, which is counter-
intuitive.
Right, so the iio-sensor-proxy approach was a quick fix attemp and
I agree with you that with e.g. orientation locking breaking this
it is not a good fix.
Also note that with wayland we have no DDX and relying on reading
the current primary plane rotation and assuming that that is the
hw lcd panel orientation seems fragile in general, what if the
xserver crashes while the display is rotated ? Then the next instance
will assume that this is hardware panel orientation.
Case 2 can't work without some mechanism to query the orientation
of the display from the firmware/etc.
Yes. I'm not sure where we'd be exporting this quirk though, as we need
it available early enough so that it can be used by boot splashes. DMI
matches in the graphics driver?
Looking at what gnome currently does on both wayland and X11 AFAICT, I
would like to solve both cases in the same manner in both cases we
need the compositor to be aware that it needs to apply some rotation.
Also taking into account thing like the monitor configuration panel
I think we need to fix this at the compositor level by having some
sort of "lcd-panel-hardware-rotation" property which gets added to
the rotation selected by the user at the compositor level.
As for where to store this for case 1 we have the info in the kernel
from the firmware (once these patches land) so we just need to export
it somehow.
For case 2 we do need a dmi quirk in the kernel to set fbcon.rotate
properly, and once we have it there we can export it in what is
hopefully the same manner.
Note that the GPD-win (which is an example of case 2) seems to be
a rare example and case 1 is the more common case, so lets focus
on fixing that first. It seems that these 2 patches get us quite
far with fixing this, we just need to add some property (sysfs file?)
to the drm_connector where the initial rotation as inherited from
the firmware can be read by the compositor. Once we have that in
place we can add a dmi quirk to set that property for e.g. the
GPD-win and somehow propagate it to fbcon.rotate (case 2 needs to
be done with software rotation in fbcon because the hw cannot handle
all rotation cases).
Regards,
Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
