2011-02-26 09:20:31 +00:00
|
|
|
/*
|
|
|
|
|
* Asus PC WMI hotkey driver
|
|
|
|
|
*
|
|
|
|
|
* Copyright(C) 2010 Intel Corporation.
|
|
|
|
|
* Copyright(C) 2010-2011 Corentin Chary <corentin.chary@gmail.com>
|
|
|
|
|
*
|
|
|
|
|
* Portions based on wistron_btns.c:
|
|
|
|
|
* Copyright (C) 2005 Miloslav Trmac <mitr@volny.cz>
|
|
|
|
|
* Copyright (C) 2005 Bernhard Rosenkraenzer <bero@arklinux.org>
|
|
|
|
|
* Copyright (C) 2005 Dmitry Torokhov <dtor@mail.ru>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _ASUS_WMI_H_
|
|
|
|
|
#define _ASUS_WMI_H_
|
|
|
|
|
|
|
|
|
|
#include <linux/platform_device.h>
|
|
|
|
|
|
2011-07-01 09:34:27 +00:00
|
|
|
#define ASUS_WMI_KEY_IGNORE (-1)
|
2012-11-29 08:12:38 +00:00
|
|
|
#define ASUS_WMI_BRN_DOWN 0x20
|
|
|
|
|
#define ASUS_WMI_BRN_UP 0x2f
|
2011-07-01 09:34:27 +00:00
|
|
|
|
2011-02-26 09:20:31 +00:00
|
|
|
struct module;
|
|
|
|
|
struct key_entry;
|
|
|
|
|
struct asus_wmi;
|
|
|
|
|
|
2012-03-20 08:53:08 +00:00
|
|
|
struct quirk_entry {
|
2016-06-13 20:57:31 +00:00
|
|
|
bool no_rfkill;
|
2012-03-20 08:53:08 +00:00
|
|
|
bool hotplug_wireless;
|
|
|
|
|
bool scalar_panel_brightness;
|
asus-wmi: store backlight power status for AIO machine
Due to some implementation reasons, ASUS ET2012 All-in-One machines
can't report the correct backlight power status, it will always return
1. To track the backlight power status correctly, we have to store the
status by ourselves.
BTW, by the BIOS design, the backlight power will be turn on/off
sequently, no matter what the value of the parameter will be.
More over, the brightness adjustment command will turn on the backlight
power. Those behaviors will make us fail to track the backlight power
status.
For example, While we are trying to turn on the backlight power,
we will send out the brightness adjustment command and then trying to
figure out if we have to turn on the backlight power, then send out
the command. But, the real case is that, the backlight power turns on
while sending the brightness adjustment command, and then we send out
the command to turn on the backlight power, it actually will turn off
the backlight power and the backlight power status we recorded becomes
wrong. So, we have to seperate these two commands by a if statement.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-03-20 08:53:09 +00:00
|
|
|
bool store_backlight_power;
|
2012-06-13 07:32:06 +00:00
|
|
|
bool wmi_backlight_power;
|
2016-08-28 08:12:06 +00:00
|
|
|
bool wmi_backlight_native;
|
2012-03-20 08:53:10 +00:00
|
|
|
int wapf;
|
asus-wmi: add display toggle quirk
For machines with AMD graphic chips, it will send out WMI event and ACPI
interrupt at the same time while hitting the hotkey. BIOS will notify the
system the next display output mode throught WMI event code, so that
windows' application can show an OSD to tell the user which mode will be
taken effect. User can hit the display toggle key many times within 2
seconds to choose the mode they want. After 2 seconds, WMI dirver should
send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose.
And then BIOS will raise another ACPI interrupt to tell the system to
really switch the display mode.
In Linux desktop, we don't have this kind of OSD to let users to choose
the mode they want, so we don't need to call WMIMethod(SDSP) to have
another ACPI interrupt. To simplify the problem, we just have to ignore
the WMI event, and let the first ACPI interrupt to send out the key event.
For the need, here comes another quirk to add machines with this kind of
behavior. When the WMI driver receives the display toggle WMI event, and
found the machin is in the list, it will do nothing and let ACPI video
driver to report the key event.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
2012-10-03 09:26:31 +00:00
|
|
|
/*
|
|
|
|
|
* For machines with AMD graphic chips, it will send out WMI event
|
|
|
|
|
* and ACPI interrupt at the same time while hitting the hotkey.
|
|
|
|
|
* To simplify the problem, we just have to ignore the WMI event,
|
|
|
|
|
* and let the ACPI interrupt to send out the key event.
|
|
|
|
|
*/
|
|
|
|
|
int no_display_toggle;
|
2012-03-20 08:53:08 +00:00
|
|
|
};
|
|
|
|
|
|
2011-02-26 09:20:31 +00:00
|
|
|
struct asus_wmi_driver {
|
2012-03-20 08:53:08 +00:00
|
|
|
int brightness;
|
asus-wmi: store backlight power status for AIO machine
Due to some implementation reasons, ASUS ET2012 All-in-One machines
can't report the correct backlight power status, it will always return
1. To track the backlight power status correctly, we have to store the
status by ourselves.
BTW, by the BIOS design, the backlight power will be turn on/off
sequently, no matter what the value of the parameter will be.
More over, the brightness adjustment command will turn on the backlight
power. Those behaviors will make us fail to track the backlight power
status.
For example, While we are trying to turn on the backlight power,
we will send out the brightness adjustment command and then trying to
figure out if we have to turn on the backlight power, then send out
the command. But, the real case is that, the backlight power turns on
while sending the brightness adjustment command, and then we send out
the command to turn on the backlight power, it actually will turn off
the backlight power and the backlight power status we recorded becomes
wrong. So, we have to seperate these two commands by a if statement.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-03-20 08:53:09 +00:00
|
|
|
int panel_power;
|
asus-wmi: record wlan status while controlled by userapp
If the user bit is set, that mean BIOS can't set and record the wlan
status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED
(0x00010012) while we query the wlan status by id ASUS_WMI_DEVID_WLAN
(0x00010011) through WMI.
So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED
(0x00010012) while setting the wlan status through WMI.
This is also the behavior that windows app will do.
Quote from ASUS application engineer
===
When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return
(1) 0x00050001 (On)
(2) 0x00050000 (Off)
(3) 0x00030001 (On)
(4) 0x00030000 (Off)
(5) 0x00000002 (Unknown)
(1), (2) means that the model has hardware GPIO for WLAN, you can call
WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off.
(3), (4) means that the model doesn’t have hardware GPIO, you need to use
API or driver library to turn WLAN on/off, and call
WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status.
After you set WLAN LED status, you can see the WLAN status is changed with
WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly
(ex: Windows), you can use it for synchronization.
(5) means that the model doesn’t have WLAN device.
WLAN is the ONLY special case with upper rule.
For other device, like Bluetooth, you just need use
WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0)
to set.
===
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
2012-07-26 09:13:31 +00:00
|
|
|
int wlan_ctrl_by_user;
|
2011-02-26 09:20:31 +00:00
|
|
|
|
|
|
|
|
const char *name;
|
|
|
|
|
struct module *owner;
|
|
|
|
|
|
|
|
|
|
const char *event_guid;
|
|
|
|
|
|
|
|
|
|
const struct key_entry *keymap;
|
|
|
|
|
const char *input_name;
|
|
|
|
|
const char *input_phys;
|
2012-03-20 08:53:08 +00:00
|
|
|
struct quirk_entry *quirks;
|
2011-07-01 09:34:27 +00:00
|
|
|
/* Returns new code, value, and autorelease values in arguments.
|
|
|
|
|
* Return ASUS_WMI_KEY_IGNORE in code if event should be ignored. */
|
|
|
|
|
void (*key_filter) (struct asus_wmi_driver *driver, int *code,
|
|
|
|
|
unsigned int *value, bool *autorelease);
|
2011-02-26 09:20:31 +00:00
|
|
|
|
|
|
|
|
int (*probe) (struct platform_device *device);
|
2012-03-20 08:53:08 +00:00
|
|
|
void (*detect_quirks) (struct asus_wmi_driver *driver);
|
2011-02-26 09:20:31 +00:00
|
|
|
|
|
|
|
|
struct platform_driver platform_driver;
|
|
|
|
|
struct platform_device *platform_device;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int asus_wmi_register_driver(struct asus_wmi_driver *driver);
|
|
|
|
|
void asus_wmi_unregister_driver(struct asus_wmi_driver *driver);
|
|
|
|
|
|
|
|
|
|
#endif /* !_ASUS_WMI_H_ */
|
