Hi, On 2/1/23 18:50, Darrell Kavanagh wrote: > Thank you. I don't have anything that could be called a big machine. > The fastest processor I have access to is a Core m3-8100Y - that's in > a Chromebook with 4GB memory - it can run Linux in a chroot or > officially in Google's VM. I also have an ancient gen 2 core i5-2410M > machine which is slower than the m3 in theory, but that has 6GB of > memory. > > Is the kernel build more processor or memory bound? It is mostly processor bound, esp. wtih something like make -j4, make -j16 will start taking some RAM, but with make -j4 I expect you to be fully CPU bound. Regards, Hans > On Wed, 1 Feb 2023 at 16:12, Bastien Nocera <hadess@xxxxxxxxxx> wrote: >> >> 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 >
