Fill up all the video switch keys in the map.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

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: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

0x60 is touchpad enable key, but is misdefined in the keymap.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Maybe this should be shared in another module...
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>

Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are some new video switch keys that used by newer machines.
0xA0 - SDSP HDMI only
0xA1 - SDSP LCD + HDMI
0xA2 - SDSP CRT + HDMI
0xA3 - SDSP TV + HDMI
But in Linux, there is no suitable userspace application to handle this,
so, mapping them all to KEY_SWITCHVIDEOMODE.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

The BIOS of these machines will try to enable/disable wifi/bt in
their own sqeuence. It won't read the enable/disable parameter
in WMI command, but just iterates the wifi/bt's status described below
1st. enable wifi, enable bt
2nd. disable wifi, enable bt
3rd. enable wifi, disable bt
4th. disable wifi, disable bt
That will totally mess up the rfkill status, since we will try to read
wifi and bt's status and reset it again while booting up.

To avoid this, these machines should set the wapf value to 4,
that will let software totally control the wifi/bt's status and
BIOS will do nothing instead of sending out the 0x88(KEY_RFKILL) event
instead of 0x5e(wifi enable), 0x5f(wifi diable), 0x7d(bt enable), and
0x7e(bt disable) through WMI.

With this patch[1], it will handle the KEY_RFKILL event correctly and
will block/unblock wifi and bt together.

1. https://lkml.org/lkml/2012/5/21/75Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Even if it's currently unused.
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Some models work better with different values of wapf, so move the
variable into quriks_entry to make it more easy to give a specific
value to different models.

Based on original patch from AceLan Kao <acelan.kao@canonical.com>

Cc: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Some ASUS ET2012E/I All-in-One machines that use a scalar board
to control the brightness, and they only accept brightness up and down
command. So, I introduced a get_scalar_command() function to pass the
command to the scalar board through WMI.

Besides, we have to store the brightness value locally, for we need the
old value to know the brightness value is increasing or decreasing.

BTW, since there is no way to retrieve the actual brightness(it would be
a fixed value), and the max brightness value would be fixed to 1, so we
have to keep passing the brightness up/down command when we reached the
max brightness value or 0.
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

ref: http://dev.iksaif.net/projects/3/wiki/Asus-laptop_WAPFSigned-off-by: NCorentin Chary <corentin.chary@gmail.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Introduce a new driver for Asus Notebooks shipped with
a WMI device instead of the old ACPI device. The WMI
device is almost the same as the one present in Eee PC,
but the event guid and the keymap are different.

The keymap comes from asus-laptop module.

On Asus notebooks, when you call the WMI device, you always
need a 64bit buffer, even if you only want to get the state
of a device (tested on a G73).
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>