Hello, you can create new trigger and use that...
On Tuesday 30 June 2015 18:09:41 Alex Hung wrote:
> 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
--
Pali Rohár
pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
