Re: [RFC PATCH 0/3] platform/x86: uniwill-laptop: Another improvement and another feature

[Armin Wolf <W_Armin@gmx.de>]

Am 22.04.26 um 17:30 schrieb Werner Sembach:
> 
> Am 22.04.26 um 13:28 schrieb Armin Wolf:
>> Am 21.04.26 um 22:01 schrieb Werner Sembach:
>>> Hi,
>>>
>>> This series is based on another not yet accepted series
>>> https://lore.kernel.org/all/20260417050912.5582-1-W_Armin@gmx.de/
>>>
>>> RFC because of that, because the third patch is not yet tested, and 
>>> because
>>> I have a question regarding the 3rd patch:
>>>
>>> Should I abstract the call to wmi_evaluate_method away in a wrapper
>>> function in uniwill-wmi somehow, or is it ok to have it straight in the
>>> uniwill-laptop code like that? It is quite self contained.
>>>
>>> Best regards,
>>>
>>> Werner
>>
>> Hi,
>>
>> i prefer having the code for this WMI interface inside a separate 
>> file. I think we have to first rename uniwill-wmi* to uniwill-wmi- 
>> event*, then the new code can live in uniwill-wmi.c
>>
>> However we also need some synchronization mechanism between uniwill- 
>> acpi and the new uniwill-wmi because some code path need to check EC 
>> registers before enabling support for local dimming. I suggest that 
>> you use the component framework for that. Basically the new WMI driver 
>> registers a component during probing, while the EC acts as a component 
>> master _if_ local dimming support is present. When the component and 
>> the component master match a sysfs attribute is registered to allow 
>> userspace application to control this feature.
> 
> Calling the old uniwill-wmi uniwill-wmi-event and the new driver 
> uniwill-wmi from here on:
> 
> I haven't yet worked with the component framework, but i wonder: since 
> the same manual register call structure that we already have for 
> uniwill-wmi-event will be also required for uniwill-wmi, can't this call 
> not also be used to exchange callbacks like for uniwill-wmi-event and 
> the notifier block? just the other way around with uniwill-acpi 
> receiving a callback instead of providing one.
> 
> ofc these callbacks must be guarded in some way to not accidentally call 
> uninitialized code, if uniwill-wmi fails to init or probe

This would indeed be possible, but where would be no mechanism for 
detecting when the WMI driver has finished probing.

I was thinking that the WMI driver uses the component callbacks to pass 
a pointer to its data struct to the component master. Said data struct 
can then by used to change the local dimming status.

I am still not sure when the associated sysfs files should be created. 
We can create them during probing of the EC, but then there will be 
problems should the WMI device take too long/fail to probe. 
Alternatively we can create the sysfs file when the component master 
binds the WMI component, so that the sysfs file will only become visible
once it is operational. We can then issue a uevent towards userspace to 
signal userspace applications that the sysfs attributes of our device 
have changed.

Thanks,
Armin Wolf

> 
>>
>> Thanks,
>> Armin Wolf
>>
>>>
>>> Werner Sembach (3):
>>>    platform/x86: uniwill-laptop: Make super key init lineup with other
>>>      inits
>>>    platform/x86: uniwill-laptop: Implement lightbar for XMG Fusion (L19)
>>>    platform/x86: uniwill-laptop: Offer support to activate local dimming
>>>
>>>   drivers/platform/x86/uniwill/uniwill-acpi.c | 195 ++++++++++++++++++--
>>>   1 file changed, 182 insertions(+), 13 deletions(-)
>>>
>>
>