Re: [PATCH v13 0/7] Merge redmi-wmi into bitland-mifs-wmi

[Hans de Goede]

Hi,

On 21-Oct-26 2:34 PM, 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.
> 
> Bitland is the ODM manufacturer for various Xiaomi Redmibook models. Both
> platforms share the exact same keyboard event stream WMI GUID
> (46C93E13-EE9B-4262-8488-563BCA757FEF). While redmi-wmi previously parsed
> the 4-byte payload as a bulk u32 scancode, bitland-mifs-wmi deconstructed
> it into discrete type/id/value fields.
> 
> Redmi operations were not contained in this patch series, future reverse
> engineering is required.
> 
> This series introduce a newly reported mic-mute hotkey definition
> for Redmibooks, dropped the previous redmi-wmi driver and intrudoced
> the quirks table for the bitland-mifs-wmi driver.
> 
> I don't have a Redmi or other Bitland device. So I cannot work on the
> real device.
> 
> Features are working properly on my device (Lecoo Bellator N176).
> 
> I leave the future reverse engineering work to the community.
> 
> Tests are welcome.
> 
> And by the way, the no_set member in bitland_profile_entry means a
> platform profile is only report by the firmware but not available for
> set.
> 
> Does accept_zero_function still necessary since the driver now permits
> 0x0 function field on SET operations?
> 
> 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?

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.