Date:	Tue, 30 Jun 2015 19:04:40 +0200
From:	Pali Rohár <pali.rohar@...il.com>
To:	Alex Hung <alex.hung@...onical.com>
Cc:	Darren Hart <dvhart@...radead.org>,
	Corentin Chary <corentin.chary@...il.com>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	acpi4asus-user@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8

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@...il.com>
> 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@...il.com>
> >> 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@...il.com> 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@...onical.com>
> >> >> > 
> >> >> > ...
> >> >> > 
> >> >> >> +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@...il.com
> > 
> > --
> > Pali Rohár
> > pali.rohar@...il.com

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists