Re: [PATCH v14 RESEND 0/6] Merge redmi-wmi into bitland-mifs-wmi

[Hans de Goede]

Hi,

On 26-Oct-26 11:20 AM, Mingyou Chen wrote:
> This patch series consolidates the standalone 'redmi-wmi' driver into the
> 'bitland-mifs-wmi' driver to eliminate code duplication and centralize
> the maintenance of overlapping ACPI WMI event streams.

<snip>

> And I've got a question, from sashiko's comment in my v12
> 
> https://sashiko.dev/#/patchset/20261012133648.132363-1-qby140326%40gmail.com
> 
>> Will this result in the loss of KEY_PERFORMANCE events on event-only legacy
>> devices?
>> Looking at bitland_mifs_wmi_probe() in drivers/platform/x86/bitland-mifs-wmi.c,
>> if dev_type == BITLAND_WMI_EVENT, it returns early after registering the input
>> device:
>> 	if (dev_type == BITLAND_WMI_EVENT) {
>> 		/* Register input device for hotkeys */
>> 		drv_data->input_dev = devm_input_allocate_device(&wdev->dev);
>> 		...
>> 		return input_register_device(drv_data->input_dev);
>> 	}
>> When the performance key is pressed, bitland_mifs_wmi_notify() intercepts it,
>> invokes the bitland_notifier_list, and returns without reporting an input event:
>> 	case WMI_EVENT_PERFORMANCE_PLAN:
>> 	case WMI_EVENT_PERFORMANCE_PLAN_ALT:
>> 		blocking_notifier_call_chain(&bitland_notifier_list,
>> 					     BITLAND_NOTIFY_PLATFORM_PROFILE,
>> 					     NULL);
>> 		return;
>> Because the platform profile and notifier were not registered during probe
>> for event-only devices, does this mean the events are silently dropped instead
>> of emitting KEY_PERFORMANCE like the old driver did?
> 
> I ackknowledged that KEY_PERFORMANCE (WMI_EVENT_PERFORMANCE_PLAN_ALT in
> bitland-mifs-wmi) looks like an event in this LKML thread
> 
>> Since the event reports a change that has already happened,
>> platform_profile_notify() is the natural way to pass it on, as
>> suggested in my v6 reply: power-profiles-daemon then re-reads the
>> profile, which is harmless after the driver's own writes too. If
>> KEY_PERFORMANCE should stay for on-screen displays (Ibragim asked to
>> keep these events observable), it may be worth not reporting it for the
>> event that echoes the driver's own write, or at least saying in a
>> comment that it reports a mode change that already happened. On
>> Ibragim's TM2209 the profile SET is reported not to work [3], so there
>> 0x16 can only come from Fn+K and the echo does not exist; Ibragim, can
>> you confirm?
> 
> https://lore.kernel.org/all/20261008152647.1510152-1-uselessfire@xxxxxxxxx/
> 
> So should I follow sashiko's advice?

Copy and pasting my v13 reply about this here to make sure it gets seen:

What I think should happen here is that *if* there is a platform-profile-handler,
then platform_profile_notify() should be used (1). OTOH if there is no
platform-profile-handler (the mentioned event-only mode) then reporting this
to userspace as KEY_PERFORMANCE as was done before makes sense to me.

Does that sound reasonable?

Regards,

Hans



1) This assumes the event indicates a platform-profile-change has happened, if
it is a request for a platform-profile-change then platform_profile_cycle();
should be used instead.