Thanks for the information, and I really appreciate it.
I took a quick look at my HP laptop and it has a led as below:
/sys/class/leds/hp::hddprotect$ cat trigger
[none] AC-online BAT0-charging-or-full BAT0-charging BAT0-full
BAT0-charging-blink-full-solid usb-gadget usb-host cpu0 cpu1 cpu2 cpu3
cpu4 cpu5 cpu6 cpu7 mmc0 rfkill1 rfkill2 rfkill8
and I learned that LED can be triggered by rfkill. I also checked
asus-wmi and its default_trigger is its rfkill name "asus-wlan".
ATK4001 is an independent ACPI device, and Method(HSWC) is its method
to control LED (actually it has other functions but only LED is needed
so far). asus-rbtn does not have anything to be triggered because it
only translate an ACPI event to KEY_RFKILL unless a rfkill is created,
but this wouldn't make sense that I use both rfkill and led when I can
only use one.
The other concern is that I'd like the LED to be ORed by both WLAN and
BT in long term. default_trigger seems to be linked to one trigger.
On Tue, Jun 30, 2015 at 4:58 PM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> Hi!
>
> Ideally, try to touch led trigger configuration from userspace yourself,
> so you will see how it works. Take some machine which has some
> configurable led exported in /sys/class/leds/ and try to set some
> trigger via "trigger" entry.
>
> I think that default trigger for led device (from kernel) can be set via
> "default_trigger" property in struct led_classdev. See file linux/leds.h
>
> On Tuesday 30 June 2015 16:38:18 Alex Hung wrote:
>> 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
>>
>>
>>
>
> --
> 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
