On Wed, 2023-02-01 at 12:00 +0100, Hans de Goede wrote: > Hi, > > On 2/1/23 11:28, Jonathan Cameron wrote: > > On Wed, 1 Feb 2023 01:40:49 +0000 > > Darrell Kavanagh <darrell.kavanagh@xxxxxxxxx> wrote: > > > > > Hello, all. > > > > > > I've finally reached a conclusion on this, after testing all the > > > combinations of the patches (with and without reading the acpi > > > mounting matrix), window managers (wayland, xorg) and the > > > presence or > > > not of my custom kernel parms. > > > > > > What works well is the full set of patches with the custom kernel > > > parms and a new hwdb entry for the sensor: > > > > > > sensor:modalias:acpi:SMO8B30*:dmi:*:svnLENOVO*:pn82AT:* > > > ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1 > > > > > > The autorotate then works correctly in wayland and xorg, but for > > > xorg, > > > the settings say the screen is "portrait left" when in actual > > > fact it > > > is in standard laptop landscape orientation. Wayland does not > > > have > > > this problem (I guess because wayland's view of the screen is > > > straight > > > from the kernel). > > > > > > Without the hwdb entry, the orientation is 90 degrees out without > > > using the acpi matrix and 180 degrees out when using it. I could > > > have > > > gone either way here with appropriate hwdb entries, but my view > > > is > > > that we *should* be using the matrix. > > > > Added Hans de Goede as he has probably run into more of this mess > > than anyone else. Hans, any thoughts on if we are doing something > > wrong on kernel side? Or is the matrix just wrong *sigh* > > I see below that this laptop has a panel which is mounted 90 degrees > rotated, that likely explains why the ACPI matrix does not work. > So the best thing to do here is to just override it with a hwdb > entries. > > IIRC there are already 1 or 2 other hwdb entries which actually > override the ACPI provided matrix because of similar issues. > > Linux userspace expects the matrix in this case to be set so that > it causes e.g. gnome's auto-rotation to put the image upright > even with older gnome versions / mate / xfce which don't know about > the panel being mounted 90 degrees. > > So e.g. "monitor-sensor" will report left-side-up or right-side-up > while the device is actually in normal clamshell mode with the > display up-right. > > This reporting of left-side-up or right-side-up is actually "correct" > looking from the native LCD panel orientation and as mentioned is > done for backward compatibility. This is documented here: > > https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb#L54 > > The way we are handling this is likely incompatible with how Windows > handles this special case of 90° rotated screen + ROTM. Or the > matrix in the ACPI tables could be just wrong... > > > I think 'ROTM' is defined by MS. > > https://learn.microsoft.com/en-us/windows-hardware/drivers/sensors/sensors-acpi-entries > > Right and as such it would be good if we can still add support to > it to the sensor driver in question. Because the ROTM info usually > is correct and avoids the need for adding more and more hwdb entries. > > Note there already is existing support in some other sensor drivers. > > So we probably need to factor out some helper code for this and share > that between sensor drivers. > > > > > The only thing that concerns me is the need for custom kernel > > > parms. > > > It would be better if there was a way to avoid this, so that the > > > user > > > didn't have to mess around with their grub config. Though having > > > said > > > that, the sensors fix as we have it doesn't make things worse - > > > under > > > currently released kernels the screen always starts up sideways > > > unless > > > custom parms are added in grub. > > We actually have a quirk mechanism in the kernel for specifying > the need for: video=DSI-1:panel_orientation=right_side_up and this > will also automatically fix the fbcon orientation, see: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_panel_orientation_quirks.c > > If you submit a patch for this upstream please Cc me. And if after that change, and copy/pasting the orientation from the DSDT into hwdb the sensor and screen move in the expected ways, then maybe stealing the BMC150 driver's bmc150_apply_bosc0200_acpi_orientation() might be a good idea. Once exported through "mount_matrix", iio-sensor-proxy should see it and read it without the need for a hwdb entry. Cheers
