Re: [PATCH] arm64: dts: qcom: x1e80100-dell-xps13-9345: enable onboard accelerometers

[Konrad Dybcio]

On 3/23/26 6:05 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 04:06:53PM +0100, Konrad Dybcio wrote:
>> On 3/2/26 2:25 PM, Aleksandrs Vinarskis wrote:
>>>
>>> On Monday, March 2nd, 2026 at 13:14, Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>>>
>>>> On 2/28/26 6:46 PM, Aleksandrs Vinarskis wrote:
>>>>> Particular laptop comes with two sets of sensors:
>>>>> 1. Motherboard: accelerometer
>>>>> 2. Display/Camera module: accelerometer, ambient ligth (and more)
>>>>>    sensor
>>>>>
>>>>> Define both i2c busses (bitbanged), sensors and respective rotation
>>>>> matrices.
>>>>
>>>> These GPIOs correspond to ADSP/SSC-bound QUPs. It may be that you're
>>>> poking at the same bus as the DSP is, concurrently.
>>>
>>> Indeed, Val already pointed out that there is hexagonrpcd to access
>>> sensors behind Sensor Core from DSP. I found corresponding .json sensor
>>> files in Windows for all x3 sensors, but could not make it work yet.
>>>
>>> Without these additional things in userspace it does not cause any
>>> conflicts: I've been using this for a week now, no i2c communication
>>> issues and device orientation information is present.
>>>
>>> The question is then if we want to keep this series which ignores DSP
>>> capabilities with the advantage that it will work for everyone with
>>> the new kernel vs doing it 'correct' way over DSP which requires
>>> additional json (and binary blobs?) and userpsace configuration,
>>> meaning that most users will never have these sensors?
>>
>> I don't know what's the endgame for sensors. Maybe +Dmitry knows whether
>> there's any action on that point.
>>
>> Going through the DSP allows you to keep aggregating the data at close
>> to no power cost (""low power island""), notably without waking up the
>> CPUs if there's no other work. That, plus I'm somewhat skeptical about
>> going behind its back, since it may be that a firmware update or some
>> other trigger makes it start trying to communicate with them.
> 
> The sensors story would require DSP libraries matching the firmware,
> sensors descriptions and several still-closed-source libraries to work.
> There is an open-source libssc project, but I don't know if anybody has
> tested it on this platform (and it will still require DSP libs to
> function).
> 
>>
>> But I'm not 100% against this either
> 
> I guess it is a necessary evil until we get libssc to work on it.

Aleksandrs, if you're interested in trying that one out:

https://codeberg.org/DylanVanAssche/libssc.git

Konrad