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

[Bastien Nocera]

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.

> 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?