Message-ID: <7005e022-dd4c-835c-bdc2-11bbbd214071@redhat.com>
Date:   Wed, 1 Feb 2023 18:55:42 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Darrell Kavanagh <darrell.kavanagh@...il.com>,
        Bastien Nocera <hadess@...ess.net>
Cc:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Jonathan Cameron <jic23@...nel.org>, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Bug#1029850: linux: Driver not loaded for ST Microelectronics
 LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)

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@...ess.net> 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@...il.com> 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
> 

Powered by blists - more mailing lists