[PATCH 2/3] Support enable Acer Launch Manager mode

[PATCH 2/3] Support enable Acer Launch Manager mode

[Lee, Chun-Yi]

Add a launch_manager parameter for support to enable Acer Launch Manager
mode. After enable it, the communication key will stop the default
behavior to control WLAN/Bluetooth/WWAN rfkill state. It leave usernland
application to handle the rfkill state changed.

Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
 drivers/platform/x86/acer-wmi.c |   74 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 74 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 32285f4..a28a775 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -85,6 +85,7 @@ MODULE_LICENSE("GPL");
 #define AMW0_GUID2		"431F16ED-0C2B-444C-B267-27DEB140CF9C"
 #define WMID_GUID1		"6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3"
 #define WMID_GUID2		"95764E09-FB56-4e83-B31A-37761F60994A"
+#define WMID_GUID3		"61EF69EA-865C-4BC3-A502-A0DEBA0CB531"
 
 /*
  * Acer ACPI event GUIDs
@@ -120,6 +121,20 @@ struct event_return_value {
 	u32 reserved;
 } __attribute__((packed));
 
+struct lm_input_params {
+	u8 function_num;	/* Function Number */
+	u16 commun_devices;	/* Communication type devices default status */
+	u16 devices;		/* Other type devices default status */
+	u8 lm_status;		/* Launch Manager Status */
+	u16 reserved;
+} __attribute__((packed));
+
+struct lm_return_value {
+	u8 error_code;		/* Error Code */
+	u8 ec_return_value;	/* EC Return Value */
+	u16 reserved;
+} __attribute__((packed));
+
 /*
  * Interface capability flags
  */
@@ -150,15 +165,18 @@ static int mailled = -1;
 static int brightness = -1;
 static int threeg = -1;
 static int force_series;
+static bool launch_manager;
 
 module_param(mailled, int, 0444);
 module_param(brightness, int, 0444);
 module_param(threeg, int, 0444);
 module_param(force_series, int, 0444);
+module_param(launch_manager, bool, 0444);
 MODULE_PARM_DESC(mailled, "Set initial state of Mail LED");
 MODULE_PARM_DESC(brightness, "Set initial LCD backlight brightness");
 MODULE_PARM_DESC(threeg, "Set initial state of 3G hardware");
 MODULE_PARM_DESC(force_series, "Force a different laptop series");
+MODULE_PARM_DESC(launch_manager, "Enable Acer Launch Manager mode");
 
 struct acer_data {
 	int mailled;
@@ -1393,6 +1411,53 @@ error_debugfs:
 	return -ENOMEM;
 }
 
+static int acer_wmi_enable_lm(void)
+{
+	struct lm_return_value return_value;
+	acpi_status status;
+	union acpi_object *obj;
+	struct lm_input_params params = {
+		.function_num = 0x1,
+		.commun_devices = 0x0041,	/* WiFi on, 3G on, BT off */
+		.devices = 0xFFFF,
+		.lm_status = 0x41,		/* Launch Manager Active */
+	};
+
+	struct acpi_buffer input = { sizeof(struct lm_input_params), &params };
+	struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+
+	status = wmi_evaluate_method(WMID_GUID3, 0, 0x1, &input, &output);
+	if (ACPI_FAILURE(status))
+		return status;
+
+	obj = output.pointer;
+
+	if (!obj)
+		return -EINVAL;
+	else if (obj->type != ACPI_TYPE_BUFFER) {
+		kfree(obj);
+		return -EINVAL;
+	}
+	if (obj->buffer.length != 4) {
+		printk(ACER_WARNING "Unknown buffer length %d\n",
+			obj->buffer.length);
+		kfree(obj);
+		return -EINVAL;
+	}
+
+	return_value = *((struct lm_return_value *)obj->buffer.pointer);
+	kfree(obj);
+
+	if (return_value.error_code || return_value.ec_return_value)
+		printk(ACER_WARNING "Enabling Launch Manager failed: "
+			"0x%x - 0x%x\n", return_value.error_code,
+			return_value.ec_return_value);
+	else
+		printk(ACER_INFO "Enabled Launch Manager");
+
+	return status;
+}
+
 static int __init acer_wmi_init(void)
 {
 	int err;
@@ -1454,6 +1519,15 @@ static int __init acer_wmi_init(void)
 		       "generic video driver\n");
 	}
 
+	if (wmi_has_guid(WMID_GUID3) && launch_manager) {
+		if (ACPI_FAILURE(acer_wmi_enable_lm())) {
+			printk(ACER_ERR "Cannot enable Launch Manager mode\n");
+			return -ENODEV;
+		}
+	} else if (!wmi_has_guid(WMID_GUID3) && launch_manager) {
+		printk(ACER_INFO "No WMID launch manager enable method\n");
+	}
+
 	if (wmi_has_guid(ACERWMID_EVENT_GUID)) {
 		err = acer_wmi_input_setup();
 		if (err)
-- 
1.6.0.2

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Dmitry Torokhov]

On Wed, Oct 13, 2010 at 11:47:41AM +0800, Lee, Chun-Yi wrote:
> Add a launch_manager parameter for support to enable Acer Launch Manager
> mode. After enable it, the communication key will stop the default
> behavior to control WLAN/Bluetooth/WWAN rfkill state. It leave usernland
> application to handle the rfkill state changed.
> 

Why would user chose one setup over another? I.e do we really need a
module option or maybe we should pick up behavior and stick to it?

-- 
Dmitry

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Dmitry, 

於 三，2010-10-13 於 11:26 -0700，Dmitry Torokhov 提到：
> On Wed, Oct 13, 2010 at 11:47:41AM +0800, Lee, Chun-Yi wrote:
> > Add a launch_manager parameter for support to enable Acer Launch Manager
> > mode. After enable it, the communication key will stop the default
> > behavior to control WLAN/Bluetooth/WWAN rfkill state. It leave usernland
> > application to handle the rfkill state changed.
> > 
> 
> Why would user chose one setup over another? I.e do we really need a
> module option or maybe we should pick up behavior and stick to it?
> 

When Acer notebook ship with Windows, they will preload a userland
application, the name is Launch Manager, it provide a GUI for end user
to change WLAN/BT/3G on/off state.

So, Acer wmi method have this function to provide the userland
application can call it to disable the default EC behavior in wifi
hotkey. After disable the hotkey's default behavior, it will only send
out wmi event when user press wifi key and doesn't touch any WLAN/BT/3G
state.

If Linux distro provide userland application the features like Acer
Launch Manager on Windows, then it can set the launch_manager to 1 to
change the wifi hotkey behavior.
Because the Launch Manager is userland application, so wmi driver only
can provide the function for it to call and don't have any way can
detect it from kernel module.

I thought it similar to disable rfkill_input by /dev/rfkill, the
different is disable rfkill_input need use ioctl, but I put a module
option in acer-wmi driver.


Thank's a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Carlos Corbacho]

On Friday 15 October 2010 09:02:01 Joey Lee wrote:
> > Why would user chose one setup over another? I.e do we really need a
> > module option or maybe we should pick up behavior and stick to it?
> 
> When Acer notebook ship with Windows, they will preload a userland
> application, the name is Launch Manager, it provide a GUI for end user
> to change WLAN/BT/3G on/off state.

[...]

> Because the Launch Manager is userland application, so wmi driver only
> can provide the function for it to call and don't have any way can
> detect it from kernel module.

Dmitry's point is still valid - why do we want to provide the userspace 
behaviour? Why not just handle it all in kernel using rfkill?

We don't have Launch Manager for Linux, and quite frankly, I hope we never see 
it - relying on random, vendor specific applications to drive this kind of 
functionality is just asking for trouble.

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Carios, 

於 五，2010-10-15 於 18:11 +0100，Carlos Corbacho 提到：
> On Friday 15 October 2010 09:02:01 Joey Lee wrote:
> > > Why would user chose one setup over another? I.e do we really need a
> > > module option or maybe we should pick up behavior and stick to it?
> > 
> > When Acer notebook ship with Windows, they will preload a userland
> > application, the name is Launch Manager, it provide a GUI for end user
> > to change WLAN/BT/3G on/off state.
> 
> [...]
> 
> > Because the Launch Manager is userland application, so wmi driver only
> > can provide the function for it to call and don't have any way can
> > detect it from kernel module.
> 
> Dmitry's point is still valid - why do we want to provide the userspace 
> behaviour? Why not just handle it all in kernel using rfkill?
> 

Did you mean put the wifi hotkey behavior to acer-wmi driver or any x86
laptop driver and implement by using rfkill?

The wifi hotkey behavior is highly customization and different OEM have
different behavior. I am not sure put the wifi hotkey rule in kernel is
a good idea.

In the future, there need have a userland rfkill policy daemon to
replace the rfkill-input module in kernel:

Documentation/rfkill.txt
The rfkill-input will be:
 * the deprecated rfkill-input module (an input layer handler, being
   replaced by userspace policy code) and

And here have a statement in feature-removal-schedule.txt
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c64fb01627e24725d1f9d535e4426475a4415753#patch1

+What:  CONFIG_RFKILL_INPUT
+When:  2.6.33
+Why:   Should be implemented in userspace, policy daemon.
+Who:   Johannes Berg <johannes@sipsolutions.net>

So, we choice remove rfkill-input then put the logic in x86/platform
driver?
A simple question:
Userland policy daemon or kernel module, which one we want to put the
wifi hotkey behavior implementation?

> We don't have Launch Manager for Linux, and quite frankly, I hope we never see 
> it - relying on random, vendor specific applications to drive this kind of 
> functionality is just asking for trouble.
> 

Acer BIOS team provide the function to OS for disable the EC hehavior,
it's available on window, why we hide it on Linux?
Either userland daemon or kernel module who want to implement the wifi
hotkey behavior, it need enable the launch-manager mode to disable the
default EC behavior on wifi hotkey.

If don't want provide the launch-manager mode parameter to userland, can
we just direct enable it?


Thank's a lot!
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Dmitry Torokhov]

On Sun, Oct 17, 2010 at 08:32:22PM -0600, Joey Lee wrote:
> Hi Carios, 
> 
> 於 五，2010-10-15 於 18:11 +0100，Carlos Corbacho 提到：
> > On Friday 15 October 2010 09:02:01 Joey Lee wrote:
> > > > Why would user chose one setup over another? I.e do we really need a
> > > > module option or maybe we should pick up behavior and stick to it?
> > > 
> > > When Acer notebook ship with Windows, they will preload a userland
> > > application, the name is Launch Manager, it provide a GUI for end user
> > > to change WLAN/BT/3G on/off state.
> > 
> > [...]
> > 
> > > Because the Launch Manager is userland application, so wmi driver only
> > > can provide the function for it to call and don't have any way can
> > > detect it from kernel module.
> > 
> > Dmitry's point is still valid - why do we want to provide the userspace 
> > behaviour? Why not just handle it all in kernel using rfkill?
> > 

Apparently networkign people is not quite happy with rfkill-input
behavior and would like to move policy from the kernel into userspace.
To tell the truth rfkill-input was never supposed to be the main
mechanism but rather something that is usable at bootup and then the
control would be handed off to userspace (if more complex policy is
needed).

> 
> Did you mean put the wifi hotkey behavior to acer-wmi driver or any x86
> laptop driver and implement by using rfkill?
> 
> The wifi hotkey behavior is highly customization and different OEM have
> different behavior. I am not sure put the wifi hotkey rule in kernel is
> a good idea.

OEMs have nothing to do with this, user is the entity that should be in
control.

> 
> In the future, there need have a userland rfkill policy daemon to
> replace the rfkill-input module in kernel:
> 
> Documentation/rfkill.txt
> The rfkill-input will be:
>  * the deprecated rfkill-input module (an input layer handler, being
>    replaced by userspace policy code) and
> 
> And here have a statement in feature-removal-schedule.txt
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c64fb01627e24725d1f9d535e4426475a4415753#patch1
> 
> +What:  CONFIG_RFKILL_INPUT
> +When:  2.6.33
> +Why:   Should be implemented in userspace, policy daemon.
> +Who:   Johannes Berg <johannes@sipsolutions.net>
> 
> So, we choice remove rfkill-input then put the logic in x86/platform
> driver?
> A simple question:
> Userland policy daemon or kernel module, which one we want to put the
> wifi hotkey behavior implementation?
> 
> > We don't have Launch Manager for Linux, and quite frankly, I hope we never see 
> > it - relying on random, vendor specific applications to drive this kind of 
> > functionality is just asking for trouble.
> > 
> 
> Acer BIOS team provide the function to OS for disable the EC hehavior,
> it's available on window, why we hide it on Linux?
> Either userland daemon or kernel module who want to implement the wifi
> hotkey behavior, it need enable the launch-manager mode to disable the
> default EC behavior on wifi hotkey.
> 
> If don't want provide the launch-manager mode parameter to userland, can
> we just direct enable it?
> 

I believe that we simply need to tell EC to keep its hands off RF
switch. As long as key is properly reported through input layer rfkill
should be able to control the RF equipment, either via rfkill-input
in-kernel shortcut or userspace daemon (when it is ready).

Thanks.

-- 
Dmitry

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Dmitry, 

於 日，2010-10-17 於 21:07 -0700，Dmitry Torokhov 提到：
> On Sun, Oct 17, 2010 at 08:32:22PM -0600, Joey Lee wrote:
> > Hi Carios, 
> > 
> > 於 五，2010-10-15 於 18:11 +0100，Carlos Corbacho 提到：
> > > On Friday 15 October 2010 09:02:01 Joey Lee wrote:
> > > > > Why would user chose one setup over another? I.e do we really need a
> > > > > module option or maybe we should pick up behavior and stick to it?
> > > > 
> > > > When Acer notebook ship with Windows, they will preload a userland
> > > > application, the name is Launch Manager, it provide a GUI for end user
> > > > to change WLAN/BT/3G on/off state.
> > > 
> > > [...]
> > > 
> > > > Because the Launch Manager is userland application, so wmi driver only
> > > > can provide the function for it to call and don't have any way can
> > > > detect it from kernel module.
> > > 
> > > Dmitry's point is still valid - why do we want to provide the userspace 
> > > behaviour? Why not just handle it all in kernel using rfkill?
> > > 
> 
> Apparently networkign people is not quite happy with rfkill-input
> behavior and would like to move policy from the kernel into userspace.
> To tell the truth rfkill-input was never supposed to be the main
> mechanism but rather something that is usable at bootup and then the
> control would be handed off to userspace (if more complex policy is
> needed).
> 

Yes, currently, we use ioctl to disable the rfkill-input when our
userland rfkill daemon enabled.

http://www.mail-archive.com/devkit-devel@lists.freedesktop.org/msg00858.html

> > 
> > Did you mean put the wifi hotkey behavior to acer-wmi driver or any x86
> > laptop driver and implement by using rfkill?
> > 
> > The wifi hotkey behavior is highly customization and different OEM have
> > different behavior. I am not sure put the wifi hotkey rule in kernel is
> > a good idea.
> 
> OEMs have nothing to do with this, user is the entity that should be in
> control.
> 
> > 
> > In the future, there need have a userland rfkill policy daemon to
> > replace the rfkill-input module in kernel:
> > 
> > Documentation/rfkill.txt
> > The rfkill-input will be:
> >  * the deprecated rfkill-input module (an input layer handler, being
> >    replaced by userspace policy code) and
> > 
> > And here have a statement in feature-removal-schedule.txt
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c64fb01627e24725d1f9d535e4426475a4415753#patch1
> > 
> > +What:  CONFIG_RFKILL_INPUT
> > +When:  2.6.33
> > +Why:   Should be implemented in userspace, policy daemon.
> > +Who:   Johannes Berg <johannes@sipsolutions.net>
> > 
> > So, we choice remove rfkill-input then put the logic in x86/platform
> > driver?
> > A simple question:
> > Userland policy daemon or kernel module, which one we want to put the
> > wifi hotkey behavior implementation?
> > 
> > > We don't have Launch Manager for Linux, and quite frankly, I hope we never see 
> > > it - relying on random, vendor specific applications to drive this kind of 
> > > functionality is just asking for trouble.
> > > 
> > 
> > Acer BIOS team provide the function to OS for disable the EC hehavior,
> > it's available on window, why we hide it on Linux?
> > Either userland daemon or kernel module who want to implement the wifi
> > hotkey behavior, it need enable the launch-manager mode to disable the
> > default EC behavior on wifi hotkey.
> > 
> > If don't want provide the launch-manager mode parameter to userland, can
> > we just direct enable it?
> > 
> 
> I believe that we simply need to tell EC to keep its hands off RF
> switch. As long as key is properly reported through input layer rfkill
> should be able to control the RF equipment, either via rfkill-input
> in-kernel shortcut or userspace daemon (when it is ready).
> 

I agree EC don't need touch the RF switch by default, I will contact
with them to discuss.

But, 
Currently, the Acer BIOS already shipped to world wide, and BIOS guys
give me tThat's why I contribute launch-manager mode patch to here.


Thank's a lot!
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Carlos Corbacho]

On Monday 18 October 2010 03:32:22 Joey Lee wrote:
> So, we choice remove rfkill-input then put the logic in x86/platform
> driver?
> A simple question:
> Userland policy daemon or kernel module, which one we want to put the
> wifi hotkey behavior implementation?

Pass. I really have no opinion on the above, as long as we pick something and 
stick with it (i.e. not-another-rfkill-rewrite).

> > We don't have Launch Manager for Linux, and quite frankly, I hope we
> > never see it - relying on random, vendor specific applications to drive
> > this kind of functionality is just asking for trouble.
> 
> Acer BIOS team provide the function to OS for disable the EC hehavior,
> it's available on window, why we hide it on Linux?

As an aside, just because Windows does something is not a good reason to do it 
or expose on on Linux if it doesn't make any sense.

> Either userland daemon or kernel module who want to implement the wifi
> hotkey behavior, it need enable the launch-manager mode to disable the
> default EC behavior on wifi hotkey.

When did Acer laptops start doing this then? The behaviour they always did in 
the past was that pressing the wireless/ bluetooth/ 3G button sent out a 
scancode, and is was then the job of something else to catch that (be it 
rfkill-input or friends) and for that something else to then toggle the state.

Do the current batch of laptops then just 'magically' toggle the state without 
needing rfkill-input?

(And do you actually have contact with someone on the Acer BIOS team? Because 
I've never managed to get through to anyone at Acer, so would be interested to 
know).

> If don't want provide the launch-manager mode parameter to userland, can
> we just direct enable it?

Well, my point is more that we should figure out what we want, and then stick 
with that. I don't want to add a pointless module paramater that all of three 
people are ever going to use, and then have to support it working both ways.

-Carlos
-- 
E-Mail: carlos@strangeworlds.co.uk
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Corentin Chary]

On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho
<carlos@strangeworlds.co.uk> wrote:
> On Monday 18 October 2010 03:32:22 Joey Lee wrote:
>> So, we choice remove rfkill-input then put the logic in x86/platform
>> driver?
>> A simple question:
>> Userland policy daemon or kernel module, which one we want to put the
>> wifi hotkey behavior implementation?
>
> Pass. I really have no opinion on the above, as long as we pick something and
> stick with it (i.e. not-another-rfkill-rewrite).
>
>> > We don't have Launch Manager for Linux, and quite frankly, I hope we
>> > never see it - relying on random, vendor specific applications to drive
>> > this kind of functionality is just asking for trouble.
>>
>> Acer BIOS team provide the function to OS for disable the EC hehavior,
>> it's available on window, why we hide it on Linux?
>
> As an aside, just because Windows does something is not a good reason to do it
> or expose on on Linux if it doesn't make any sense.
>
>> Either userland daemon or kernel module who want to implement the wifi
>> hotkey behavior, it need enable the launch-manager mode to disable the
>> default EC behavior on wifi hotkey.
>
> When did Acer laptops start doing this then? The behaviour they always did in
> the past was that pressing the wireless/ bluetooth/ 3G button sent out a
> scancode, and is was then the job of something else to catch that (be it
> rfkill-input or friends) and for that something else to then toggle the state.
>
> Do the current batch of laptops then just 'magically' toggle the state without
> needing rfkill-input?
>
> (And do you actually have contact with someone on the Acer BIOS team? Because
> I've never managed to get through to anyone at Acer, so would be interested to
> know).
>
>> If don't want provide the launch-manager mode parameter to userland, can
>> we just direct enable it?
>
> Well, my point is more that we should figure out what we want, and then stick
> with that. I don't want to add a pointless module paramater that all of three
> people are ever going to use, and then have to support it working both ways.
>
> -Carlos

asus-laptop laptop also has that kind of parameter, but mainly because
the behavior of the toggle key is quite random across models. So we
need to set it sometimes.

Anyway, I think it's a good thing to have the choice between "handled by
hardware/BIOS" and "handled by kernel/userspace", as long as the default choice
is coherent and always works correctly.

Most of users will want the key to just toggle wlan/bluetooth. But some of them
will be happy if they can configure the behavior of the key (cycle, only toggle
WLAN, etc...)

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Dmitry Torokhov]

On Mon, Oct 18, 2010 at 09:55:57AM +0200, Corentin Chary wrote:
> On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho
> <carlos@strangeworlds.co.uk> wrote:
> > On Monday 18 October 2010 03:32:22 Joey Lee wrote:
> >> So, we choice remove rfkill-input then put the logic in x86/platform
> >> driver?
> >> A simple question:
> >> Userland policy daemon or kernel module, which one we want to put the
> >> wifi hotkey behavior implementation?
> >
> > Pass. I really have no opinion on the above, as long as we pick something and
> > stick with it (i.e. not-another-rfkill-rewrite).
> >
> >> > We don't have Launch Manager for Linux, and quite frankly, I hope we
> >> > never see it - relying on random, vendor specific applications to drive
> >> > this kind of functionality is just asking for trouble.
> >>
> >> Acer BIOS team provide the function to OS for disable the EC hehavior,
> >> it's available on window, why we hide it on Linux?
> >
> > As an aside, just because Windows does something is not a good reason to do it
> > or expose on on Linux if it doesn't make any sense.
> >
> >> Either userland daemon or kernel module who want to implement the wifi
> >> hotkey behavior, it need enable the launch-manager mode to disable the
> >> default EC behavior on wifi hotkey.
> >
> > When did Acer laptops start doing this then? The behaviour they always did in
> > the past was that pressing the wireless/ bluetooth/ 3G button sent out a
> > scancode, and is was then the job of something else to catch that (be it
> > rfkill-input or friends) and for that something else to then toggle the state.
> >
> > Do the current batch of laptops then just 'magically' toggle the state without
> > needing rfkill-input?
> >
> > (And do you actually have contact with someone on the Acer BIOS team? Because
> > I've never managed to get through to anyone at Acer, so would be interested to
> > know).
> >
> >> If don't want provide the launch-manager mode parameter to userland, can
> >> we just direct enable it?
> >
> > Well, my point is more that we should figure out what we want, and then stick
> > with that. I don't want to add a pointless module paramater that all of three
> > people are ever going to use, and then have to support it working both ways.
> >
> > -Carlos
> 
> asus-laptop laptop also has that kind of parameter, but mainly because
> the behavior of the toggle key is quite random across models. So we
> need to set it sometimes.

Why sometimes?

> 
> Anyway, I think it's a good thing to have the choice between "handled by
> hardware/BIOS" and "handled by kernel/userspace", as long as the default choice
> is coherent and always works correctly.

No, I disagree. Why would you want to have this choice and have to
maintain it if we already have mechanisms to do it either in kernel or
in userspace.
> 
> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> will be happy if they can configure the behavior of the key (cycle, only toggle
> WLAN, etc...)

Right. And as of today by default kernel will do simple toggle but there
is an option for userspace component. Why do we want to bing BIOS into
the picture?

-- 
Dmitry

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Dmitry Torokhov]

On Sun, Oct 17, 2010 at 10:53:05PM -0600, Joey Lee wrote:
> Hi Dmitry, 
> 
> 於 日，2010-10-17 於 21:07 -0700，Dmitry Torokhov 提到：
> > 
> > I believe that we simply need to tell EC to keep its hands off RF
> > switch. As long as key is properly reported through input layer rfkill
> > should be able to control the RF equipment, either via rfkill-input
> > in-kernel shortcut or userspace daemon (when it is ready).
> > 
> 
> I agree EC don't need touch the RF switch by default, I will contact
> with them to discuss.
> 
> But, 
> Currently, the Acer BIOS already shipped to world wide, and BIOS guys
> give me tThat's why I contribute launch-manager mode patch to here.
> 

I understand that certain BIOSes do, by default, toggle the switch. I
also believe that we want to disable this. The question that still is
not answered why we need the module option? Why don't we _always_
tell EC to keep its hands off RF switch?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Corentin Chary]

On Mon, Oct 18, 2010 at 10:14 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Oct 18, 2010 at 09:55:57AM +0200, Corentin Chary wrote:
>> On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho
>> <carlos@strangeworlds.co.uk> wrote:
>> > On Monday 18 October 2010 03:32:22 Joey Lee wrote:
>> >> So, we choice remove rfkill-input then put the logic in x86/platform
>> >> driver?
>> >> A simple question:
>> >> Userland policy daemon or kernel module, which one we want to put the
>> >> wifi hotkey behavior implementation?
>> >
>> > Pass. I really have no opinion on the above, as long as we pick something and
>> > stick with it (i.e. not-another-rfkill-rewrite).
>> >
>> >> > We don't have Launch Manager for Linux, and quite frankly, I hope we
>> >> > never see it - relying on random, vendor specific applications to drive
>> >> > this kind of functionality is just asking for trouble.
>> >>
>> >> Acer BIOS team provide the function to OS for disable the EC hehavior,
>> >> it's available on window, why we hide it on Linux?
>> >
>> > As an aside, just because Windows does something is not a good reason to do it
>> > or expose on on Linux if it doesn't make any sense.
>> >
>> >> Either userland daemon or kernel module who want to implement the wifi
>> >> hotkey behavior, it need enable the launch-manager mode to disable the
>> >> default EC behavior on wifi hotkey.
>> >
>> > When did Acer laptops start doing this then? The behaviour they always did in
>> > the past was that pressing the wireless/ bluetooth/ 3G button sent out a
>> > scancode, and is was then the job of something else to catch that (be it
>> > rfkill-input or friends) and for that something else to then toggle the state.
>> >
>> > Do the current batch of laptops then just 'magically' toggle the state without
>> > needing rfkill-input?
>> >
>> > (And do you actually have contact with someone on the Acer BIOS team? Because
>> > I've never managed to get through to anyone at Acer, so would be interested to
>> > know).
>> >
>> >> If don't want provide the launch-manager mode parameter to userland, can
>> >> we just direct enable it?
>> >
>> > Well, my point is more that we should figure out what we want, and then stick
>> > with that. I don't want to add a pointless module paramater that all of three
>> > people are ever going to use, and then have to support it working both ways.
>> >
>> > -Carlos
>>
>> asus-laptop laptop also has that kind of parameter, but mainly because
>> the behavior of the toggle key is quite random across models. So we
>> need to set it sometimes.
>
> Why sometimes?

The parameter we're talking about is wapf, it's directly linked to WAPF
in the dsdt. WAPF is a bitmask used to control the behavior of the toggle key.
It can: control the device,  control the leds, send key codes.

Here is some doc about what we found on wapf:
https://dev.iksaif.net/projects/acpi4asus/wiki/Asus-laptop_WAPF

By default, we currently write 1 into wapf, because this is the value that
works correctly most of the time. But on some models, the key won't do
anything if you don't set the correct value of wapf.

On windows, the hotk acpi driver (from asus) also sets WAPF, but
if seems to do some hardware check to guess the value to use ... Then
it also handles events, and do actions (toggle wlan devices, etc...).

But all the WAPF/BLED/WLED stuff on asus-laptop isn't really working
properly, mainly because I lacks documentation, and the behavior seems
to be dependent of present hardware (wlan cards mainly).

>>
>> Anyway, I think it's a good thing to have the choice between "handled by
>> hardware/BIOS" and "handled by kernel/userspace", as long as the default choice
>> is coherent and always works correctly.
>
> No, I disagree. Why would you want to have this choice and have to
> maintain it if we already have mechanisms to do it either in kernel or
> in userspace.
>>
>> Most of users will want the key to just toggle wlan/bluetooth. But some of them
>> will be happy if they can configure the behavior of the key (cycle, only toggle
>> WLAN, etc...)
>
> Right. And as of today by default kernel will do simple toggle but there
> is an option for userspace component. Why do we want to bing BIOS into
> the picture?

Because we should consider the BIOS as a fallback method (that may or
may not work). If a newer model comes out, and the kernel/userspace doesn't
know how to handle it, users will be able to use the BIOS while the
driver is being fixed.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Dmitry, 

於 一，2010-10-18 於 01:20 -0700，Dmitry Torokhov 提到：
> On Sun, Oct 17, 2010 at 10:53:05PM -0600, Joey Lee wrote:
> > Hi Dmitry, 
> > 
> > 於 日，2010-10-17 於 21:07 -0700，Dmitry Torokhov 提到：
> > > 
> > > I believe that we simply need to tell EC to keep its hands off RF
> > > switch. As long as key is properly reported through input layer rfkill
> > > should be able to control the RF equipment, either via rfkill-input
> > > in-kernel shortcut or userspace daemon (when it is ready).
> > > 
> > 
> > I agree EC don't need touch the RF switch by default, I will contact
> > with them to discuss.
> > 
> > But, 
> > Currently, the Acer BIOS already shipped to world wide, and BIOS guys
> > give me tThat's why I contribute launch-manager mode patch to here.
> > 
> 
> I understand that certain BIOSes do, by default, toggle the switch. I
> also believe that we want to disable this. The question that still is
> not answered why we need the module option? Why don't we _always_
> tell EC to keep its hands off RF switch?
> 

Fully understood, now.

I also agreed direct enable the launch manager mode to tell EC don't
touch RF. It pother any other RF switch implementation, like
rfkill-input or any other userland daemon.


Thank's
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Carios, 

於 一，2010-10-18 於 08:19 +0100，Carlos Corbacho 提到：
> On Monday 18 October 2010 03:32:22 Joey Lee wrote:
> > So, we choice remove rfkill-input then put the logic in x86/platform
> > driver?
> > A simple question:
> > Userland policy daemon or kernel module, which one we want to put the
> > wifi hotkey behavior implementation?
> 
> Pass. I really have no opinion on the above, as long as we pick something and 
> stick with it (i.e. not-another-rfkill-rewrite).
> 
> > > We don't have Launch Manager for Linux, and quite frankly, I hope we
> > > never see it - relying on random, vendor specific applications to drive
> > > this kind of functionality is just asking for trouble.
> > 
> > Acer BIOS team provide the function to OS for disable the EC hehavior,
> > it's available on window, why we hide it on Linux?
> 
> As an aside, just because Windows does something is not a good reason to do it 
> or expose on on Linux if it doesn't make any sense.
> 

M... We all know the wmi spec is from Microsoft and OEM/ODM base on it
to write their wmi function spec for develop their windows solution.
So, I thought we still need to reference the behavior on windows then do
our desicion on Linux.

Especially Linux kernel response BIOS by _OSI said we are Windows OS.

> > Either userland daemon or kernel module who want to implement the wifi
> > hotkey behavior, it need enable the launch-manager mode to disable the
> > default EC behavior on wifi hotkey.
> 
> When did Acer laptops start doing this then? The behaviour they always did in 
> the past was that pressing the wireless/ bluetooth/ 3G button sent out a 
> scancode, and is was then the job of something else to catch that (be it 
> rfkill-input or friends) and for that something else to then toggle the state.
> 
> Do the current batch of laptops then just 'magically' toggle the state without 
> needing rfkill-input?
> 

I will check when they start to use wmi event to replace the scancode or
maybe Acer ship wmi with different notebook family.
My 0001 patch transfer the wmi event to keycode, so, rfkill-input can
catch the keycode to work.

I agreed Dmitry's suggestion, we just direct enable the launch manager
mode to stop EC touch RF switch. Either use rfkill-input or userland
daemon to control the RF switch, we all need disable the default EC
behavior, it causes sometimes will enable/disalbe wifi/bluetooth switch
twice.

> (And do you actually have contact with someone on the Acer BIOS team? Because 
> I've never managed to get through to anyone at Acer, so would be interested to 
> know).
> 

Thank's for your suggestion, I will try to check your question.

> > If don't want provide the launch-manager mode parameter to userland, can
> > we just direct enable it?
> 
> Well, my point is more that we should figure out what we want, and then stick 
> with that. I don't want to add a pointless module paramater that all of three 
> people are ever going to use, and then have to support it working both ways.
> 

Like the above, I thought we just direct enable the lanuch manager mode
when acer-wmi driver detected the WMID3 available.


Thank's
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Corentin, 

於 一，2010-10-18 於 09:55 +0200，Corentin Chary 提到：
> On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho
> <carlos@strangeworlds.co.uk> wrote:
> > On Monday 18 October 2010 03:32:22 Joey Lee wrote:
> >> So, we choice remove rfkill-input then put the logic in x86/platform
> >> driver?
> >> A simple question:
> >> Userland policy daemon or kernel module, which one we want to put the
> >> wifi hotkey behavior implementation?
> >
> > Pass. I really have no opinion on the above, as long as we pick something and
> > stick with it (i.e. not-another-rfkill-rewrite).
> >
> >> > We don't have Launch Manager for Linux, and quite frankly, I hope we
> >> > never see it - relying on random, vendor specific applications to drive
> >> > this kind of functionality is just asking for trouble.
> >>
> >> Acer BIOS team provide the function to OS for disable the EC hehavior,
> >> it's available on window, why we hide it on Linux?
> >
> > As an aside, just because Windows does something is not a good reason to do it
> > or expose on on Linux if it doesn't make any sense.
> >
> >> Either userland daemon or kernel module who want to implement the wifi
> >> hotkey behavior, it need enable the launch-manager mode to disable the
> >> default EC behavior on wifi hotkey.
> >
> > When did Acer laptops start doing this then? The behaviour they always did in
> > the past was that pressing the wireless/ bluetooth/ 3G button sent out a
> > scancode, and is was then the job of something else to catch that (be it
> > rfkill-input or friends) and for that something else to then toggle the state.
> >
> > Do the current batch of laptops then just 'magically' toggle the state without
> > needing rfkill-input?
> >
> > (And do you actually have contact with someone on the Acer BIOS team? Because
> > I've never managed to get through to anyone at Acer, so would be interested to
> > know).
> >
> >> If don't want provide the launch-manager mode parameter to userland, can
> >> we just direct enable it?
> >
> > Well, my point is more that we should figure out what we want, and then stick
> > with that. I don't want to add a pointless module paramater that all of three
> > people are ever going to use, and then have to support it working both ways.
> >
> > -Carlos
> 
> asus-laptop laptop also has that kind of parameter, but mainly because
> the behavior of the toggle key is quite random across models. So we
> need to set it sometimes.
> 
> Anyway, I think it's a good thing to have the choice between "handled by
> hardware/BIOS" and "handled by kernel/userspace", as long as the default choice
> is coherent and always works correctly.
> 

I didn't see a good mechanism that was provided by Acer or MSI BIOS to
set the wifi key behavior like you said in Asus BIOS.
Their EC just control the RF switch follow a default priority, like:
	wlan on, bt on, 3G on
	wlan on, bt off, 3G off
	...
	wlan off, bt off, 3G off

The logic is not fully the same with different hardware model.
And, 
As I know, on Windows, they sometimes also disable the default behavior
because they have something like hotkey manager or launch manager to
handle it.

> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> will be happy if they can configure the behavior of the key (cycle, only toggle
> WLAN, etc...)
> 

I thought just direct disable the default EC behavior then leave a
userland daemon to control the behavior, it will grab the wifi key event
then control rfkill state by follow user's customization rules.


Thank's
Joey Lee


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Corentin Chary]

On Tue, Oct 19, 2010 at 11:55 AM, Joey Lee <jlee@novell.com> wrote:
> Hi Corentin,
>
> 於 一，2010-10-18 於 09:55 +0200，Corentin Chary 提到：
>> On Mon, Oct 18, 2010 at 9:19 AM, Carlos Corbacho
>> <carlos@strangeworlds.co.uk> wrote:
>> > On Monday 18 October 2010 03:32:22 Joey Lee wrote:
>> >> So, we choice remove rfkill-input then put the logic in x86/platform
>> >> driver?
>> >> A simple question:
>> >> Userland policy daemon or kernel module, which one we want to put the
>> >> wifi hotkey behavior implementation?
>> >
>> > Pass. I really have no opinion on the above, as long as we pick something and
>> > stick with it (i.e. not-another-rfkill-rewrite).
>> >
>> >> > We don't have Launch Manager for Linux, and quite frankly, I hope we
>> >> > never see it - relying on random, vendor specific applications to drive
>> >> > this kind of functionality is just asking for trouble.
>> >>
>> >> Acer BIOS team provide the function to OS for disable the EC hehavior,
>> >> it's available on window, why we hide it on Linux?
>> >
>> > As an aside, just because Windows does something is not a good reason to do it
>> > or expose on on Linux if it doesn't make any sense.
>> >
>> >> Either userland daemon or kernel module who want to implement the wifi
>> >> hotkey behavior, it need enable the launch-manager mode to disable the
>> >> default EC behavior on wifi hotkey.
>> >
>> > When did Acer laptops start doing this then? The behaviour they always did in
>> > the past was that pressing the wireless/ bluetooth/ 3G button sent out a
>> > scancode, and is was then the job of something else to catch that (be it
>> > rfkill-input or friends) and for that something else to then toggle the state.
>> >
>> > Do the current batch of laptops then just 'magically' toggle the state without
>> > needing rfkill-input?
>> >
>> > (And do you actually have contact with someone on the Acer BIOS team? Because
>> > I've never managed to get through to anyone at Acer, so would be interested to
>> > know).
>> >
>> >> If don't want provide the launch-manager mode parameter to userland, can
>> >> we just direct enable it?
>> >
>> > Well, my point is more that we should figure out what we want, and then stick
>> > with that. I don't want to add a pointless module paramater that all of three
>> > people are ever going to use, and then have to support it working both ways.
>> >
>> > -Carlos
>>
>> asus-laptop laptop also has that kind of parameter, but mainly because
>> the behavior of the toggle key is quite random across models. So we
>> need to set it sometimes.
>>
>> Anyway, I think it's a good thing to have the choice between "handled by
>> hardware/BIOS" and "handled by kernel/userspace", as long as the default choice
>> is coherent and always works correctly.
>>
>
> I didn't see a good mechanism that was provided by Acer or MSI BIOS to
> set the wifi key behavior like you said in Asus BIOS.
> Their EC just control the RF switch follow a default priority, like:
>        wlan on, bt on, 3G on
>        wlan on, bt off, 3G off
>        ...
>        wlan off, bt off, 3G off
>
> The logic is not fully the same with different hardware model.
> And,
> As I know, on Windows, they sometimes also disable the default behavior
> because they have something like hotkey manager or launch manager to
> handle it.
>
>> Most of users will want the key to just toggle wlan/bluetooth. But some of them
>> will be happy if they can configure the behavior of the key (cycle, only toggle
>> WLAN, etc...)
>>
>
> I thought just direct disable the default EC behavior then leave a
> userland daemon to control the behavior, it will grab the wifi key event
> then control rfkill state by follow user's customization rules.

What I'm saying is: I don't really care what's the default behavior is,
but if the EC provide a somewhat reliable way to make the key work
without any userspace daemon involved, I think we should allow
the user to use this mode (even if it's with an obscure module
parameter or sysfs file).

But .. maybe if someone want this default "raw" behavior,
he should just not load this module.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Corentin, 

於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
> >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> >> will be happy if they can configure the behavior of the key (cycle, only toggle
> >> WLAN, etc...)
> >>
> >
> > I thought just direct disable the default EC behavior then leave a
> > userland daemon to control the behavior, it will grab the wifi key event
> > then control rfkill state by follow user's customization rules.
> 
> What I'm saying is: I don't really care what's the default behavior is,
> but if the EC provide a somewhat reliable way to make the key work
> without any userspace daemon involved, I think we should allow
> the user to use this mode (even if it's with an obscure module
> parameter or sysfs file).
> 
> But .. maybe if someone want this default "raw" behavior,
> he should just not load this module.
> 

Fully understood, now.

Like you siad, we need define a policy for:

 - If user want the default "raw" behavior, what do they need to do?
	I thought if the wmi driver doesn't load by default, then user 
       will get a "raw" behavior.

 - If any distro want provide userland solution, how can they disable 
   the default "raw" behavior?
	If anybody want to disable the "raw" behavior, just load the wmi 
       driver.

Does it right?

Thank's
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Corentin Chary]

On Tue, Oct 19, 2010 at 1:15 PM, Joey Lee <jlee@novell.com> wrote:
> Hi Corentin,
>
> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
>> >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
>> >> will be happy if they can configure the behavior of the key (cycle, only toggle
>> >> WLAN, etc...)
>> >>
>> >
>> > I thought just direct disable the default EC behavior then leave a
>> > userland daemon to control the behavior, it will grab the wifi key event
>> > then control rfkill state by follow user's customization rules.
>>
>> What I'm saying is: I don't really care what's the default behavior is,
>> but if the EC provide a somewhat reliable way to make the key work
>> without any userspace daemon involved, I think we should allow
>> the user to use this mode (even if it's with an obscure module
>> parameter or sysfs file).
>>
>> But .. maybe if someone want this default "raw" behavior,
>> he should just not load this module.
>>
>
> Fully understood, now.
>
> Like you siad, we need define a policy for:
>
>  - If user want the default "raw" behavior, what do they need to do?
>        I thought if the wmi driver doesn't load by default, then user
>       will get a "raw" behavior.
>
>  - If any distro want provide userland solution, how can they disable
>   the default "raw" behavior?
>        If anybody want to disable the "raw" behavior, just load the wmi
>       driver.
>
> Does it right?

Yeah, seems to be ok...
-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Corentin, 

於 二，2010-10-19 於 05:15 -0600，Joey Lee 提到：
> Hi Corentin, 
> 
> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> > >> will be happy if they can configure the behavior of the key (cycle, only toggle
> > >> WLAN, etc...)
> > >>
> > >
> > > I thought just direct disable the default EC behavior then leave a
> > > userland daemon to control the behavior, it will grab the wifi key event
> > > then control rfkill state by follow user's customization rules.
> > 
> > What I'm saying is: I don't really care what's the default behavior is,
> > but if the EC provide a somewhat reliable way to make the key work
> > without any userspace daemon involved, I think we should allow
> > the user to use this mode (even if it's with an obscure module
> > parameter or sysfs file).
> > 
> > But .. maybe if someone want this default "raw" behavior,
> > he should just not load this module.
> > 
> 
> Fully understood, now.
> 
> Like you siad, we need define a policy for:
> 
>  - If user want the default "raw" behavior, what do they need to do?
> 	I thought if the wmi driver doesn't load by default, then user 
>        will get a "raw" behavior.
> 
But... 
The wmi driver doesn't just provide the RF switch function, it's also
have other functions like transfer wmi event to key code.

User doesn't load wmi driver will have "raw" RF switch behavior, but
lost other more functions.

>  - If any distro want provide userland solution, how can they disable 
>    the default "raw" behavior?
> 	If anybody want to disable the "raw" behavior, just load the wmi 
>        driver.
Maybe we still add kernel module parameter?


Thank's
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Corentin Chary]

On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <jlee@novell.com> wrote:
> Hi Corentin,
>
> 於 二，2010-10-19 於 05:15 -0600，Joey Lee 提到：
>> Hi Corentin,
>>
>> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
>> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
>> > >> will be happy if they can configure the behavior of the key (cycle, only toggle
>> > >> WLAN, etc...)
>> > >>
>> > >
>> > > I thought just direct disable the default EC behavior then leave a
>> > > userland daemon to control the behavior, it will grab the wifi key event
>> > > then control rfkill state by follow user's customization rules.
>> >
>> > What I'm saying is: I don't really care what's the default behavior is,
>> > but if the EC provide a somewhat reliable way to make the key work
>> > without any userspace daemon involved, I think we should allow
>> > the user to use this mode (even if it's with an obscure module
>> > parameter or sysfs file).
>> >
>> > But .. maybe if someone want this default "raw" behavior,
>> > he should just not load this module.
>> >
>>
>> Fully understood, now.
>>
>> Like you siad, we need define a policy for:
>>
>>  - If user want the default "raw" behavior, what do they need to do?
>>       I thought if the wmi driver doesn't load by default, then user
>>        will get a "raw" behavior.
>>
> But...
> The wmi driver doesn't just provide the RF switch function, it's also
> have other functions like transfer wmi event to key code.
>
> User doesn't load wmi driver will have "raw" RF switch behavior, but
> lost other more functions.
>
>>  - If any distro want provide userland solution, how can they disable
>>    the default "raw" behavior?
>>       If anybody want to disable the "raw" behavior, just load the wmi
>>        driver.
> Maybe we still add kernel module parameter?
>

Indeed, I think it would be a good idea to let the user do that.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Dmitry Torokhov]

On Tue, Oct 19, 2010 at 03:28:43PM +0200, Corentin Chary wrote:
> On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <jlee@novell.com> wrote:
> > Hi Corentin,
> >
> > 於 二，2010-10-19 於 05:15 -0600，Joey Lee 提到：
> >> Hi Corentin,
> >>
> >> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
> >> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> >> > >> will be happy if they can configure the behavior of the key (cycle, only toggle
> >> > >> WLAN, etc...)
> >> > >>
> >> > >
> >> > > I thought just direct disable the default EC behavior then leave a
> >> > > userland daemon to control the behavior, it will grab the wifi key event
> >> > > then control rfkill state by follow user's customization rules.
> >> >
> >> > What I'm saying is: I don't really care what's the default behavior is,
> >> > but if the EC provide a somewhat reliable way to make the key work
> >> > without any userspace daemon involved, I think we should allow
> >> > the user to use this mode (even if it's with an obscure module
> >> > parameter or sysfs file).

But we already have the in-kernel solution that provides this behavior.
It is called rfkill-input and it is the in-kernel bridge between input
devices that emit KEY_WLAN etc. and rfkill switches. There is no need to
have yet another mechanism (most likely fighting with default in-kernel
one) doing the same thing. So for boxes tat do support this launcher
mode we should simply enable it. _Always_.

And once the userspace manager[s] become standard we can just rely on
their presence. Like right now you can't really live without udev, dbus,
etc. if you want to have reasonably behaving box (embedded setups out of
scope here).

> >> >
> >> > But .. maybe if someone want this default "raw" behavior,
> >> > he should just not load this module.
> >> >
> >>
> >> Fully understood, now.
> >>
> >> Like you siad, we need define a policy for:
> >>
> >>  - If user want the default "raw" behavior, what do they need to do?
> >>       I thought if the wmi driver doesn't load by default, then user
> >>        will get a "raw" behavior.
> >>
> > But...
> > The wmi driver doesn't just provide the RF switch function, it's also
> > have other functions like transfer wmi event to key code.
> >
> > User doesn't load wmi driver will have "raw" RF switch behavior, but
> > lost other more functions.
> >
> >>  - If any distro want provide userland solution, how can they disable
> >>    the default "raw" behavior?
> >>       If anybody want to disable the "raw" behavior, just load the wmi
> >>        driver.
> > Maybe we still add kernel module parameter?
> >
> 
> Indeed, I think it would be a good idea to let the user do that.
> 

And I do not think so for the reasons outlined. We have chosen the
direction already (dictated by the existence of keys not directly
connected withg RF switches) and we should follow through with it, so
all boxes and drivers behave as uniformly as possible.

Thanks.

-- 
Dmitry

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Corentin Chary]

On Tue, Oct 19, 2010 at 5:49 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 03:28:43PM +0200, Corentin Chary wrote:
>> On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <jlee@novell.com> wrote:
>> > Hi Corentin,
>> >
>> > 於 二，2010-10-19 於 05:15 -0600，Joey Lee 提到：
>> >> Hi Corentin,
>> >>
>> >> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
>> >> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
>> >> > >> will be happy if they can configure the behavior of the key (cycle, only toggle
>> >> > >> WLAN, etc...)
>> >> > >>
>> >> > >
>> >> > > I thought just direct disable the default EC behavior then leave a
>> >> > > userland daemon to control the behavior, it will grab the wifi key event
>> >> > > then control rfkill state by follow user's customization rules.
>> >> >
>> >> > What I'm saying is: I don't really care what's the default behavior is,
>> >> > but if the EC provide a somewhat reliable way to make the key work
>> >> > without any userspace daemon involved, I think we should allow
>> >> > the user to use this mode (even if it's with an obscure module
>> >> > parameter or sysfs file).
>
> But we already have the in-kernel solution that provides this behavior.
> It is called rfkill-input and it is the in-kernel bridge between input
> devices that emit KEY_WLAN etc. and rfkill switches. There is no need to
> have yet another mechanism (most likely fighting with default in-kernel
> one) doing the same thing. So for boxes tat do support this launcher
> mode we should simply enable it. _Always_.
>
> And once the userspace manager[s] become standard we can just rely on
> their presence. Like right now you can't really live without udev, dbus,
> etc. if you want to have reasonably behaving box (embedded setups out of
> scope here).
>
>> >> >
>> >> > But .. maybe if someone want this default "raw" behavior,
>> >> > he should just not load this module.
>> >> >
>> >>
>> >> Fully understood, now.
>> >>
>> >> Like you siad, we need define a policy for:
>> >>
>> >>  - If user want the default "raw" behavior, what do they need to do?
>> >>       I thought if the wmi driver doesn't load by default, then user
>> >>        will get a "raw" behavior.
>> >>
>> > But...
>> > The wmi driver doesn't just provide the RF switch function, it's also
>> > have other functions like transfer wmi event to key code.
>> >
>> > User doesn't load wmi driver will have "raw" RF switch behavior, but
>> > lost other more functions.
>> >
>> >>  - If any distro want provide userland solution, how can they disable
>> >>    the default "raw" behavior?
>> >>       If anybody want to disable the "raw" behavior, just load the wmi
>> >>        driver.
>> > Maybe we still add kernel module parameter?
>> >
>>
>> Indeed, I think it would be a good idea to let the user do that.
>>
>
> And I do not think so for the reasons outlined. We have chosen the
> direction already (dictated by the existence of keys not directly
> connected withg RF switches) and we should follow through with it, so
> all boxes and drivers behave as uniformly as possible.
>

Then, let's not add this parameter. Anyway the potential user base who
may acer-wmi without this mode is probably very low.

But I still think that having a parameter to enable this "raw" mode
would be helpful in some case, for example, "the keycode changed and
is not yet mapped to KEY_WLAN", or "wimax is not yet supported by
acer-wmi and there is not (yet) a rfkill interface for it". This would
be a quirk mode, only enabled for some very special cases, like
acpi_osi="Linux" or acpi_backlight="vendor".

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Dmitry Torokhov]

On Tue, Oct 19, 2010 at 06:03:09PM +0200, Corentin Chary wrote:
> On Tue, Oct 19, 2010 at 5:49 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Tue, Oct 19, 2010 at 03:28:43PM +0200, Corentin Chary wrote:
> >> On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <jlee@novell.com> wrote:
> >> > Hi Corentin,
> >> >
> >> > 於 二，2010-10-19 於 05:15 -0600，Joey Lee 提到：
> >> >> Hi Corentin,
> >> >>
> >> >> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
> >> >> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> >> >> > >> will be happy if they can configure the behavior of the key (cycle, only toggle
> >> >> > >> WLAN, etc...)
> >> >> > >>
> >> >> > >
> >> >> > > I thought just direct disable the default EC behavior then leave a
> >> >> > > userland daemon to control the behavior, it will grab the wifi key event
> >> >> > > then control rfkill state by follow user's customization rules.
> >> >> >
> >> >> > What I'm saying is: I don't really care what's the default behavior is,
> >> >> > but if the EC provide a somewhat reliable way to make the key work
> >> >> > without any userspace daemon involved, I think we should allow
> >> >> > the user to use this mode (even if it's with an obscure module
> >> >> > parameter or sysfs file).
> >
> > But we already have the in-kernel solution that provides this behavior.
> > It is called rfkill-input and it is the in-kernel bridge between input
> > devices that emit KEY_WLAN etc. and rfkill switches. There is no need to
> > have yet another mechanism (most likely fighting with default in-kernel
> > one) doing the same thing. So for boxes tat do support this launcher
> > mode we should simply enable it. _Always_.
> >
> > And once the userspace manager[s] become standard we can just rely on
> > their presence. Like right now you can't really live without udev, dbus,
> > etc. if you want to have reasonably behaving box (embedded setups out of
> > scope here).
> >
> >> >> >
> >> >> > But .. maybe if someone want this default "raw" behavior,
> >> >> > he should just not load this module.
> >> >> >
> >> >>
> >> >> Fully understood, now.
> >> >>
> >> >> Like you siad, we need define a policy for:
> >> >>
> >> >>  - If user want the default "raw" behavior, what do they need to do?
> >> >>       I thought if the wmi driver doesn't load by default, then user
> >> >>        will get a "raw" behavior.
> >> >>
> >> > But...
> >> > The wmi driver doesn't just provide the RF switch function, it's also
> >> > have other functions like transfer wmi event to key code.
> >> >
> >> > User doesn't load wmi driver will have "raw" RF switch behavior, but
> >> > lost other more functions.
> >> >
> >> >>  - If any distro want provide userland solution, how can they disable
> >> >>    the default "raw" behavior?
> >> >>       If anybody want to disable the "raw" behavior, just load the wmi
> >> >>        driver.
> >> > Maybe we still add kernel module parameter?
> >> >
> >>
> >> Indeed, I think it would be a good idea to let the user do that.
> >>
> >
> > And I do not think so for the reasons outlined. We have chosen the
> > direction already (dictated by the existence of keys not directly
> > connected withg RF switches) and we should follow through with it, so
> > all boxes and drivers behave as uniformly as possible.
> >
> 
> Then, let's not add this parameter. Anyway the potential user base who
> may acer-wmi without this mode is probably very low.
> 
> But I still think that having a parameter to enable this "raw" mode
> would be helpful in some case, for example, "the keycode changed and
> is not yet mapped to KEY_WLAN", or "wimax is not yet supported by
> acer-wmi and there is not (yet) a rfkill interface for it". This would
> be a quirk mode, only enabled for some very special cases, like
> acpi_osi="Linux" or acpi_backlight="vendor".

I see. I guess I'd rather people reported the issue and we provided the
fix that have them work around the issue (maybe) and we never hearing
about it. This way fix hapepns quicker and work for everyone instead of
only the person discovered the magic option.

I think we discussed it enough, I'll defer to Matthew whether to take
the patch with the switch or the one enabling the mode unconditionally.

Thanks.

-- 
Dmitry

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi Carlos, 

於 二，2010-10-19 於 02:09 -0600，Joey Lee 提到： 
> > As an aside, just because Windows does something is not a good reason to do it 
> > or expose on on Linux if it doesn't make any sense.
> > 
> 
> M... We all know the wmi spec is from Microsoft and OEM/ODM base on it
> to write their wmi function spec for develop their windows solution.
> So, I thought we still need to reference the behavior on windows then do
> our desicion on Linux.
> 
> Especially Linux kernel response BIOS by _OSI said we are Windows OS.
> 
> > > Either userland daemon or kernel module who want to implement the wifi
> > > hotkey behavior, it need enable the launch-manager mode to disable the
> > > default EC behavior on wifi hotkey.
> > 
> > When did Acer laptops start doing this then? The behaviour they always did in 
> > the past was that pressing the wireless/ bluetooth/ 3G button sent out a 
> > scancode, and is was then the job of something else to catch that (be it 
> > rfkill-input or friends) and for that something else to then toggle the state.
> > 
> > Do the current batch of laptops then just 'magically' toggle the state without 
> > needing rfkill-input?
> > 
> 
> I will check when they start to use wmi event to replace the scancode or
> maybe Acer ship wmi with different notebook family.
> My 0001 patch transfer the wmi event to keycode, so, rfkill-input can
> catch the keycode to work.
> 
> I agreed Dmitry's suggestion, we just direct enable the launch manager
> mode to stop EC touch RF switch. Either use rfkill-input or userland
> daemon to control the RF switch, we all need disable the default EC
> behavior, it causes sometimes will enable/disalbe wifi/bluetooth switch
> twice.
> 
> > (And do you actually have contact with someone on the Acer BIOS team? Because 
> > I've never managed to get through to anyone at Acer, so would be interested to 
> > know).
> > 
> 
> Thank's for your suggestion, I will try to check your question.
> 

After check.
Acer moved to WMI for hotkey function on notebook/netbook from 2010. 

But if the hotkey have standard scan code (Ex. Volume up/down,
Play/Pause, ¡K), it will keep scan code.


> > > If don't want provide the launch-manager mode parameter to userland, can
> > > we just direct enable it?
> > 
> > Well, my point is more that we should figure out what we want, and then stick 
> > with that. I don't want to add a pointless module paramater that all of three 
> > people are ever going to use, and then have to support it working both ways.
> > 
> 
> Like the above, I thought we just direct enable the lanuch manager mode
> when acer-wmi driver detected the WMID3 available.
> 

Also check why have default EC "raw" behavior in wifi hotkey before
enable launch manager mode, That's because they want to cover end user
install Windows 98 or other old Windows not support wmi.


Thank's
Joey Lee

Re: [PATCH 2/3] Support enable Acer Launch Manager mode

[Joey Lee]

Hi all, 

於 二，2010-10-19 於 09:49 -0700，Dmitry Torokhov 提到：
> On Tue, Oct 19, 2010 at 06:03:09PM +0200, Corentin Chary wrote:
> > On Tue, Oct 19, 2010 at 5:49 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> > > On Tue, Oct 19, 2010 at 03:28:43PM +0200, Corentin Chary wrote:
> > >> On Tue, Oct 19, 2010 at 3:25 PM, Joey Lee <jlee@novell.com> wrote:
> > >> > Hi Corentin,
> > >> >
> > >> > 於 二，2010-10-19 於 05:15 -0600，Joey Lee 提到：
> > >> >> Hi Corentin,
> > >> >>
> > >> >> 於 二，2010-10-19 於 12:51 +0200，Corentin Chary 提到：
> > >> >> > >> Most of users will want the key to just toggle wlan/bluetooth. But some of them
> > >> >> > >> will be happy if they can configure the behavior of the key (cycle, only toggle
> > >> >> > >> WLAN, etc...)
> > >> >> > >>
> > >> >> > >
> > >> >> > > I thought just direct disable the default EC behavior then leave a
> > >> >> > > userland daemon to control the behavior, it will grab the wifi key event
> > >> >> > > then control rfkill state by follow user's customization rules.
> > >> >> >
> > >> >> > What I'm saying is: I don't really care what's the default behavior is,
> > >> >> > but if the EC provide a somewhat reliable way to make the key work
> > >> >> > without any userspace daemon involved, I think we should allow
> > >> >> > the user to use this mode (even if it's with an obscure module
> > >> >> > parameter or sysfs file).
> > >
> > > But we already have the in-kernel solution that provides this behavior.
> > > It is called rfkill-input and it is the in-kernel bridge between input
> > > devices that emit KEY_WLAN etc. and rfkill switches. There is no need to
> > > have yet another mechanism (most likely fighting with default in-kernel
> > > one) doing the same thing. So for boxes tat do support this launcher
> > > mode we should simply enable it. _Always_.
> > >
> > > And once the userspace manager[s] become standard we can just rely on
> > > their presence. Like right now you can't really live without udev, dbus,
> > > etc. if you want to have reasonably behaving box (embedded setups out of
> > > scope here).
> > >
> > >> >> >
> > >> >> > But .. maybe if someone want this default "raw" behavior,
> > >> >> > he should just not load this module.
> > >> >> >
> > >> >>
> > >> >> Fully understood, now.
> > >> >>
> > >> >> Like you siad, we need define a policy for:
> > >> >>
> > >> >>  - If user want the default "raw" behavior, what do they need to do?
> > >> >>       I thought if the wmi driver doesn't load by default, then user
> > >> >>        will get a "raw" behavior.
> > >> >>
> > >> > But...
> > >> > The wmi driver doesn't just provide the RF switch function, it's also
> > >> > have other functions like transfer wmi event to key code.
> > >> >
> > >> > User doesn't load wmi driver will have "raw" RF switch behavior, but
> > >> > lost other more functions.
> > >> >
> > >> >>  - If any distro want provide userland solution, how can they disable
> > >> >>    the default "raw" behavior?
> > >> >>       If anybody want to disable the "raw" behavior, just load the wmi
> > >> >>        driver.
> > >> > Maybe we still add kernel module parameter?
> > >> >
> > >>
> > >> Indeed, I think it would be a good idea to let the user do that.
> > >>
> > >
> > > And I do not think so for the reasons outlined. We have chosen the
> > > direction already (dictated by the existence of keys not directly
> > > connected withg RF switches) and we should follow through with it, so
> > > all boxes and drivers behave as uniformly as possible.
> > >
> > 
> > Then, let's not add this parameter. Anyway the potential user base who
> > may acer-wmi without this mode is probably very low.
> > 
> > But I still think that having a parameter to enable this "raw" mode
> > would be helpful in some case, for example, "the keycode changed and
> > is not yet mapped to KEY_WLAN", or "wimax is not yet supported by
> > acer-wmi and there is not (yet) a rfkill interface for it". This woul> > be a quirk mode, only enabled for some very special cases, like
> > acpi_osi="Linux" or acpi_backlight="vendor".
> 
> I see. I guess I'd rather people reported the issue and we provided the
> fix that have them work around the issue (maybe) and we never hearing
> about it. This way fix hapepns quicker and work for everyone instead of
> only the person discovered the magic option.
> 
> I think we discussed it enough, I'll defer to Matthew whether to take
> the patch with the switch or the one enabling the mode unconditionally.
> 

I will send 4 patches again...

Follow our conclusion, I modified the launch manager patch to enabled it
by default and provide a kernel module option for enable ec raw
behavior:

>From d590461aa239b6db646fe5bd9e10e5ebeba63df7 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <jlee@novell.com>
Date: Sun, 31 Oct 2010 00:03:36 -0400
Subject: [PATCH 2/4] Enabled Acer Launch Manager mode

Enabled Acer Launch Manager mode to disable the EC raw behavior for
communication devices when WMID3 method available. And, we also add a
ec_raw_mode kernel module option for enable The EC raw behavior mode
when anyone what reset it back.
When Acer Launch Manager mode enabled, EC will stop to touch any
communication devices' RF state or power state that causes conflict
with rfkill_input or any userland daemon to charge the rfkill rules.

Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
 drivers/platform/x86/acer-wmi.c |  113
+++++++++++++++++++++++++++++++++++++++
 1 files changed, 113 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/acer-wmi.c
b/drivers/platform/x86/acer-wmi.c
index 930df56..0b870d3 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -85,6 +85,7 @@ MODULE_LICENSE("GPL");
 #define AMW0_GUID2		"431F16ED-0C2B-444C-B267-27DEB140CF9C"
 #define WMID_GUID1		"6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3"
 #define WMID_GUID2		"95764E09-FB56-4e83-B31A-37761F60994A"
+#define WMID_GUID3		"61EF69EA-865C-4BC3-A502-A0DEBA0CB531"
 
 /*
  * Acer ACPI event GUIDs
@@ -120,6 +121,20 @@ struct event_return_value {
 	u32 reserved;
 } __attribute__((packed));
 
+struct lm_input_params {
+	u8 function_num;	/* Function Number */
+	u16 commun_devices;	/* Communication type devices default status */
+	u16 devices;		/* Other type devices default status */
+	u8 lm_status;		/* Launch Manager Status */
+	u16 reserved;
+} __attribute__((packed));
+
+struct lm_return_value {
+	u8 error_code;		/* Error Code */
+	u8 ec_return_value;	/* EC Return Value */
+	u16 reserved;
+} __attribute__((packed));
+
 /*
  * Interface capability flags
  */
@@ -150,15 +165,18 @@ static int mailled = -1;
 static int brightness = -1;
 static int threeg = -1;
 static int force_series;
+static bool ec_raw_mode;
 
 module_param(mailled, int, 0444);
 module_param(brightness, int, 0444);
 module_param(threeg, int, 0444);
 module_param(force_series, int, 0444);
+module_param(ec_raw_mode, bool, 0444);
 MODULE_PARM_DESC(mailled, "Set initial state of Mail LED");
 MODULE_PARM_DESC(brightness, "Set initial LCD backlight brightness");
 MODULE_PARM_DESC(threeg, "Set initial state of 3G hardware");
 MODULE_PARM_DESC(force_series, "Force a different laptop series");
+MODULE_PARM_DESC(ec_raw_mode, "Enable EC raw mode");
 
 struct acer_data {
 	int mailled;
@@ -1393,6 +1411,87 @@ error_debugfs:
 	return -ENOMEM;
 }
 
+static acpi_status
+wmid3_set_lm_mode(struct lm_input_params *params,
+			struct lm_return_value *return_value)
+{
+	acpi_status status;
+	union acpi_object *obj;
+
+	struct acpi_buffer input = { sizeof(struct lm_input_params), params };
+	struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+
+	status = wmi_evaluate_method(WMID_GUID3, 0, 0x1, &input, &output);
+	if (ACPI_FAILURE(status))
+		return status;
+
+	obj = output.pointer;
+
+	if (!obj)
+		return -EINVAL;
+	else if (obj->type != ACPI_TYPE_BUFFER) {
+		kfree(obj);
+		return -EINVAL;
+	}
+	if (obj->buffer.length != 4) {
+		printk(ACER_WARNING "Unknown buffer length %d\n",
+			obj->buffer.length);
+		kfree(obj);
+		return -EINVAL;
+	}
+
+	*return_value = *((struct lm_return_value *)obj->buffer.pointer);
+	kfree(obj);
+
+	return status;
+}
+
+static int acer_wmi_enable_ec_raw(void)
+{
+	struct lm_return_value return_value;
+	acpi_status status;
+	struct lm_input_params params = {
+		.function_num = 0x1,
+		.commun_devices = 0xFFFF,
+		.devices = 0xFFFF,
+		.lm_status = 0x00,		/* Launch Manager Deactive */
+	};
+
+	status = wmid3_set_lm_mode(&params, &return_value);
+
+	if (return_value.error_code || return_value.ec_return_value)
+		printk(ACER_WARNING "Enabling EC raw mode failed: "
+			"0x%x - 0x%x\n", return_value.error_code,
+			return_value.ec_return_value);
+	else
+		printk(ACER_INFO "Enabled EC raw mode");
+
+	return status;
+}
+
+static int acer_wmi_enable_lm(void)
+{
+	struct lm_return_value return_value;
+	acpi_status status;
+	struct lm_input_params params = {
+		.function_num = 0x1,
+		.commun_devices = 0x0041,	/* WiFi on, 3G on, BT off */
+		.devices = 0xFFFF,
+		.lm_status = 0x41,		/* Launch Manager Active */
+	};
+
+	status = wmid3_set_lm_mode(&params, &return_value);
+
+	if (return_value.error_code || return_value.ec_return_value)
+		printk(ACER_WARNING "Enabling Launch Manager failed: "
+			"0x%x - 0x%x\n", return_value.error_code,
+			return_value.ec_return_value);
+	else
+		printk(ACER_INFO "Enabled Launch Manager");
+
+	return status;
+}
+
 static int __init acer_wmi_init(void)
 {
 	int err;
@@ -1454,6 +1553,20 @@ static int __init acer_wmi_init(void)
 		       "generic video driver\n");
 	}
 
+	if (wmi_has_guid(WMID_GUID3)) {
+		if (ec_raw_mode) {
+			if (ACPI_FAILURE(acer_wmi_enable_ec_raw())) {
+				printk(ACER_ERR "Cannot enable EC raw mode\n");
+				return -ENODEV;
+			}
+		} else if (ACPI_FAILURE(acer_wmi_enable_lm())) {
+			printk(ACER_ERR "Cannot enable Launch Manager mode\n");
+			return -ENODEV;
+		}
+	} else if (!wmi_has_guid(WMID_GUID3) && ec_raw_mode) {
+		printk(ACER_INFO "No WMID EC raw mode enable method\n");
+	}
+
 	if (wmi_has_guid(ACERWMID_EVENT_GUID)) {
 		err = acer_wmi_input_setup();
 		if (err)
-- 
1.6.0.2



--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html