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

[Bastien Nocera]

On Sun, 2017-04-30 at 21:34 +0200, 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:
> > > 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).

Sounds like a good plan!