Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
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: > > > > > > > > > > > > > > > > > > > > > > > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
Hi, On 30-04-17 21:34, 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: 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. > So I've been running some tests with the 2 original patches focussing only on the normal screen is upside down, BIOS has configured hardware rotation case which is what all devices except on special device seem to have. As expected with these 2 patches fbcon and the plymouth splashscreen work fine. If I then start: a) Xorg with modesetting driver: I get the screen the right way up, but the cursor plane is upside down both in coordinates (where the cursor gets shown) as well as the cursor glyph being upside down b) Xorg with intel driver, the intel driver re-sets the primary plane's drm "rotation" property, so everthing is upside down. At least the primary and cursor planes are consistent with each other now (the touchscreen coordinates how ever are not). c) Gnome as Wayland compositor, same as Xorg with intel driver So think more about this I think that Ville's 2 original cases really are: 1. All planes support the necessary rotation in hardware, so we can fix things up fully in hardware, aka the upside down case which I believe is the majority of all troublesome hardware out there. 2. The necessary rotation is not supported in hardware. This is the case with the GPD-win where we've a 90 / 270 degrees rotation. Here even the EFI configuration menu, grub, efifb, etc. all are rotated. My conclusion of all this is that: 1. For 1. we can and should fix this entirely and transparently in the kernel, we need kernel fixes for fbcon/fbdev anyways, so we might just as well go all the way, otherwise all of Xorg + modesetting, Xorg + intel and Gnome as Wayland compositor will need separate fixes. So this is best dealt with in the kernel, esp. since there are more Wayland compositors out there. 2. There is nothing the kernel can do here, so this one we really need to fix in userspace. I've some ideas for this, but those fall outside the scope of this discussion. I've already implemented the all kernel fix for 1. It is a single patch only touching the i915 driver, since if we transparently deal with the extra rotation in the i915 code we no longer need the drm_fb_helper changes as things will just work for the fbcon too, which is really nice to see and to me shows this is the right way to solve this. The patch adds just 80 lines of code and completely fixes this issue :) I'll send out the patch right after this mail. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
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: 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
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: > > > > > > > > > > > > > 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? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
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: > > > > > > > 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. Case 2 can't work without some mechanism to query the orientation of the display from the firmware/etc. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote: > > > 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. I would expect the baseline test for this wouldn't involve iio-sensor- proxy at all, and boot to the desktop with the expected orientation showing up in the desktop env/XRandR as "not rotated". Eg. for the GPD Win which does have this problem, this should appear as being rotated (image 1): https://c.slashgear.com/wp-content/uploads/2016/11/gpd-win-book-2.jpg But not this (image 2): https://c.slashgear.com/wp-content/uploads/2016/11/gpd-win-0-800x420.jpg After that, the problem is whether the accelerometer is mounted the same way as the "non-rotated screen" (option 2), or the "non-rotated screen" (option 1), which would show what quirking is needed. Cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
On Sun, Apr 23, 2017 at 06:11:04PM +0200, Hans de Goede wrote: > Hi All, > > So I recently bought a (second-hand) Bay Trail tablet which has its LCD > mounted upside-down. As such I've ported Ville Syrjala's patches to deal > with this to current mainline and I'm hereby posting them upstream > for merging. > > These patches fix the kernel-console as well as the boot-splash > (at leats plymouth does not reset the rotation) being upside down as > soon as a native kms driver such as the i915 driver is loaded. > > This fixes the orientation of the displayed image from boot till the > Xserver or a Wayland compositor takes over. It doesn't work for X? Using -modesetting perhaps? IIRC it worked just fine with -intel way back when. > > 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? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation
Hi All, So I recently bought a (second-hand) Bay Trail tablet which has its LCD mounted upside-down. As such I've ported Ville Syrjala's patches to deal with this to current mainline and I'm hereby posting them upstream for merging. These patches fix the kernel-console as well as the boot-splash (at leats plymouth does not reset the rotation) being upside down as soon as a native kms driver such as the i915 driver is loaded. This fixes the orientation of the displayed image from boot till the Xserver or a Wayland compositor takes over. 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 Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
