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