Pali,
Thanks for comments, but will you be able to provide more details so
it is more clear how this works?
On Mon, Jun 29, 2015 at 8:29 PM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> On Friday 26 June 2015 23:24:10 Alex Hung wrote:
>> On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
>> > Hi!
>> >
>> > On Wednesday 24 June 2015 10:57:51 Alex Hung wrote:
>> >> ASUS introduced a new approach to handle wireless hotkey
>> >> since Windows 8. When the hotkey is pressed, BIOS generates
>> >> a notification 0x88 to a new ACPI device, ATK4001. This
>> >> new driver not only translates the notification to KEY_RFKILL
>> >> but also toggles its LED accordingly.
>> >>
>> >> Signed-off-by: Alex Hung <alex.hung@xxxxxxxxxxxxx>
>> >
>> > ...
>> >
>> >> +static int asus_radio_led_set(bool blocked)
>> >> +{
>> >> + acpi_status status;
>> >> + union acpi_object arg0 = { ACPI_TYPE_INTEGER };
>> >> + struct acpi_object_list args = { 1, &arg0 };
>> >> + unsigned long long output;
>> >> +
>> >> + arg0.integer.value = blocked;
>> >> + status = acpi_evaluate_integer(asus_rbtn_device->handle, "HSWC",
>> >> + &args, &output);
>> >
>> > What is this ACPI call doing? Just set LED control? Or something more?
>> >
>> >> + if (!ACPI_SUCCESS(status) || output == 0) {
>> >> + pr_err("fail to change wireless LED.\n");
>> >> + return -EINVAL;
>> >> + }
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int asus_rfkill_set(void *data, bool blocked)
>> >> +{
>> >> + radio_led_state = blocked ? 0 : 1;
>> >> +
>> >> + return asus_radio_led_set(radio_led_state);
>> >> +}
>> >
>> > In my opinion this is not good idea that "rfkill block" call from
>> > userspace just change LED on/off state and nothing more...
>> >
>> > If above ACPI call just change LED, then should not be this in LED
>> > subsystem instead rfkill one? Or why do you prefer to use rfkill
>> > interface instead led?
>>
>> It indeed controls LED only at the moment. My intention was to have
>> have everything work without the need to modify any userspace
>> applications. Current it is 1) aus-rbtn issues KEY_RFKILL 2) an
>> userspace application changes rfkill states, and 3) both radio and LED
>> work. It will also work when a user enable/disable wireless devices
>> on a user application which uses rfkill interface.
>>
>> Come to think about it now, I may have to handle LED with WLAN and BT
>> but I will have to find a system with both devices later.
>>
>> I am not too familiar with userspace applications v.s. LED. Is it
>> possible to do the same (i.e. without touching userspace)? I think
>> rfkill is good interface to handle whatever needs doing when changing
>> wireless states, such as LED controls. However, if other approach can
>> meet the need I am happy to investigate.
>>
>
> There are triggers for led which automatically enable/disable led. I
> think that configuring default wifi/bluetooth trigger for that new led
> could work...
>
> --
> Pali Rohár
> pali.rohar@xxxxxxxxx
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
