It seems that I have "INPUT_SPARSEKMAP" in my .config and therefore I
did not have any problems when compiling the kernel with previous
patch.
I tried this patch and it works fine for me.
Tested-by: Alex Hung
On Sun, Jan 3, 2016 at 10:54 PM, Andy Lutomirski wrote:
> From
install ACPI notify
>> handlers by themselves and those are hooked up directly into the ACPICA
>> code.
>>
>> Besides, some drivers may actually want to receive those events while
>> the system is suspending or resuming, so I think this has to be addressed
>> on a per-driver basis.
>
> Hi,
>
> sorry, but I'm not sure I understood everything, so I'll try to
> briefly describe the problem and its current solution.
>
> Currently dell-rbtn listens for the notifications sent to an ACPI
> device and for notification sends an input event to userspace.
>
> The problem we have is that some BIOSes send an extra notification
> on resume and therefore we send an extra input event.
>
> What we want to do is to ignore this ACPI notification without
> affecting the systems whose BIOS does not send this extra
> notification. We know that not all of them send this notification.
>
> What I noticed is that the extra notification is issued by the _WAK
> method and always arrives before dell-rbtn has been resumed, so
> what I did is to add a flag that is set by the suspend and resume
> callbacks of the device driver.
Sorry I screw up my mail filter and I wasn't aware of this thread until now.
BIOS sends this additional ACPI event for the systems with hardware
switch so a driver can update its state; therefore this is done only
once and therefore ignoring the ACPI event sent to dell rbtn once
after resume is sufficient.
I actually tried a solution similar to Gabriele's patch above (one
with rbtn_suspend and rbtn_resume) a while ago and it works fine.
If there is a conclusion and there is a patch to be tested, I am happy
to test it on wider range (I should be able to find 5+ Dell systems
that runs on dell-rbtn).
>
> What we were wondering is whether this would be enough or we
> need to do something different, e.g. ignore all the notifications that
> arrived X seconds after the execution of the resume callback.
>
> Thanks,
> Gabriele
>
>>> Has Dell been involved here?
>>
>> Not that I know of.
>>
>> Thanks,
>> Rafael
>>
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This driver supports various HID events including hotkeys.
Dell XPS 13 9350 requires it for the wireless hotkey.
Signed-off-by: Alex Hung
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 11 ++
drivers/platform/x86/Makefile| 1 +
drivers/platform/x86/intel
On Fri, Dec 18, 2015 at 7:01 AM, Darren Hart wrote:
> On Thu, Dec 17, 2015 at 02:50:39PM -0800, Andy Lutomirski wrote:
>> On Thu, Dec 17, 2015 at 2:15 PM, Darren Hart wrote:
>> > On Thu, Dec 17, 2015 at 03:30:02PM +0800, Alex Hung wrote:
>> >> This driver support
This driver supports various hid events including hotkeys.
Dell XPS 13 9350 requires it for wireless hotkey.
Andy Lutomirski contributed greatly to this driver.
Signed-off-by: Alex Hung
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 11 ++
drivers/platform
On Fri, Jul 10, 2015 at 4:52 AM, Darren Hart wrote:
> On Tue, Jul 07, 2015 at 04:25:18PM +0200, Pali Rohár wrote:
>> On Monday 06 July 2015 15:43:28 Darren Hart wrote:
>> > On Mon, Jul 06, 2015 at 09:35:40AM +0800, Alex Hung wrote:
>> > > ATK4001 is an ACPI device f
15:10:39 Alex Hung wrote:
>> Thanks for the support. I will create v3 based with LED triggers.
>>
>> Just for information. ASUS's wording is as below:
>>
>> Fn+F2 can be used to turn on or off all radio capabilities in the
>> device (as known as airplane mo
e the term airplane-mode do if
asus-rbtn is not preferred. Let me know if there are any suggestions.
On Wed, Jul 1, 2015 at 7:48 PM, Pali Rohár wrote:
> On Wednesday 01 July 2015 00:09:41 Alex Hung wrote:
>> ATK4001 is an independent ACPI device, and Method(HSWC) is its method
>> to con
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 fil
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 wrote:
> On Friday 26 June 2015 23:24:10 Alex Hung wrote:
>> On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár wrote:
>> >
On Fri, Jun 26, 2015 at 10:56 PM, Pali Rohár 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
s any.
On Tue, Jun 23, 2015 at 4:47 AM, Darren Hart wrote:
> On Mon, Jun 22, 2015 at 05:20:05PM +0800, 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 A
-rbtn.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d8afd29..03711ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1673,6 +1673,12 @@ S: Maintained
F: drivers/platform/x86/asus*.c
F: drivers/platform/x86/eeepc*.c
+ASUS RADIO BUTTON DRIVER
+M: Alex Hung
+L: platform-driver
adio button for Windows 8
+ *
+ * Copyright (C) 2015 Alex Hung
+ *
+ * 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
+ * (
Signed-off-by: Alex Hung
---
drivers/platform/x86/hp-wireless.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/platform/x86/hp-wireless.c
b/drivers/platform/x86/hp-wireless.c
index 4e4cc8b..731c69b 100644
--- a/drivers/platform/x86/hp-wireless.c
+++ b/drivers/platform/x86/hp
When Method(CRBT) returns 0 and 1, BIOS will not change hardware pin. As a
result, a keycode KEY_RFKILL is required when wireless hotkey is pressed.
Signed-off-by: Alex Hung
---
drivers/platform/x86/dell-rbtn.c | 99 --
1 file changed, 94 insertions(+), 5
er.
>
> Alex, can you check if scancode of wireless change generated by
> BIOS is on all machines same: 136 (0x88)? And is send by keyboard
> controller (not acpi/wmi)?
>
> On Thursday 25 December 2014 04:13:02 Alex Hung wrote:
>> I usually prefer to stick with formal d
n't think holiday is quite
over for everybody. I will send updates when there is any.
On Mon, Dec 29, 2014 at 4:32 PM, Pali Rohár wrote:
> On Monday 29 December 2014 08:27:21 Alex Hung wrote:
>> On Fri, Dec 26, 2014 at 5:55 AM, Gabriele Mazzotta
>>
>> wrote:
>> >
the scancode table
(http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf)
and found 0x88 is already used - it is the "break" ("release" in Linux
term) code for "7" (the one above Y/U, not number pad). It can be
verified by &quo
40 PM, Gabriele Mazzotta
wrote:
> On Wednesday 24 December 2014 17:13:45 Alex Hung wrote:
>> I uploaded acpidump files [1] (except for XPS 13 which is not
>> available), and this should help clarify what has been tested.
>>
>> Does Inspirion 5721 does not have either DELLAB
stems, but I may need some more detailed instructions.
On Tue, Dec 23, 2014 at 3:16 AM, Gabriele Mazzotta
wrote:
> On Monday 22 December 2014 15:27:57 Alex Hung wrote:
>> = Testing =
>>
>> I tested six Dell systems for two sets of patches for dell radio
>> button - tw
patch which can
>> correctly set rfkill state by software on laptops of your fn key
>> type.
>
> That's what happens on my laptop, but Alex said that the laptops on
> which he worked, ARBT was empty, so I guess it's not always a choice.
> In order not to break things, all the laptops that support both the
> methods must be set to the correct mode through ARBT when the module
> is loaded. If this is not done, then what you say is correct, we should
> not report KEY_RFKILL, or at least do it selectively, but I guess that
> this is not be possible without a whitelist (that we don't have).
>
>> > > > Correct if I'm wrong, but shouldn't his patch have no
>> > > > effects on your laptop? If I'm not wrong, CRBT returns 2
>> > > > on your laptop, so the input device is not even created.
>> > > > Am I missing something?
>> > > >
>> > > > Gabriele
>> > >
>> > > Yes, it has no effect for my laptop.
>>
>>
>
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
x27;s suggestion and Pali's
dell-rbtn.c (btw, will there be updates?). However, I will need a few
days to do the comparison.
Any suggested test cases?
Cheers,
Alex Hung
On Tue, Dec 2, 2014 at 4:42 PM, Pali Rohár wrote:
> On Wednesday 26 November 2014 00:05:28 Darren Hart wrote:
>> On S
ta wrote:
>> On Tuesday 02 December 2014 12:06:45 Gabriele Mazzotta wrote:
>> > On Thursday 27 November 2014 12:41:19 Alex Hung wrote:
>> > > On Sun, Nov 23, 2014 at 8:52 AM, Pali Rohár wrote:
>> > > > On Saturday 22 November 2014 03:09:06 Darren Hart wrote:
g at other platform drivers code some add() methods do give
>> information to the user via pr_{err,warn,info} macros, some don't. My
>> first patch to deal with this just removed the err variable like you
>> have wrote but Darren Hart and Rafael J. Wysocki commented that maybe it
&
On Thu, Nov 27, 2014 at 7:43 PM, Pali Rohár wrote:
> On Thursday 27 November 2014 05:27:01 Alex Hung wrote:
>> On Sat, Nov 22, 2014 at 10:09 AM, Darren Hart
> wrote:
>> > On Sat, Nov 22, 2014 at 11:45:08PM +0100, Pali Rohár wrote:
>> >> Hello,
>> >>
it is not good idea to pass every PS/2 data
>> > from both keyboard, touchpad and trackpoint to dell-laptop
>> > driver and if there is alternative (DELLABCE) it is better
>> > to use it.
>> >
>> > But now I would like to hear what do you think about
E acpi
>> device, I cannot use new dell-wireless driver. And I think only
>> one driver can hit mainline kernel.
>
> I would like to see your patch, it sounds like it might be a better option.
>
> --
> Darren Hart
> Intel Open Source Technology Center
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e KEY_RFKILL to userspace.
Signed-off-by: Alex Hung
---
drivers/platform/x86/Kconfig | 12 +++
drivers/platform/x86/Makefile| 1 +
drivers/platform/x86/dell-wireless.c | 159 +++
3 files changed, 172 insertions(+)
create mode 100644 drivers/pla
userspace applications. I expect to see more simple ACPI devices
to be handled by simple drivers. Combining devices with different
purposes into a single complex driver can be misleading.
Hi Matthew,
Thanks for clarifying it for me.
Cheers,
Alex Hung
On Wed, Nov 12, 2014 at 3:35 AM, Matthew Garrett
Signed-off-by: Alex Hung
---
drivers/platform/x86/Kconfig | 12 +++
drivers/platform/x86/Makefile|1 +
drivers/platform/x86/dell-wireless.c | 159 ++
3 files changed, 172 insertions(+)
create mode 100644 drivers/platform/x86/dell-wireless.c
Hi Matthew,
I reverted 997daa1bd9aca412ab97955a35b26c460c0ec7a4 and add a check in
hp_wmi_rfkill_setup as below:
diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 8ba8956..65fee8a 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -54,
> Matthew Garrett | mj...@srcf.ucam.org
> --
> To unsubscribe from this list: send the line "unsubscribe
> platform-driver-x86" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cheers
Signed-off-by: Alex Hung
---
drivers/platform/x86/Kconfig | 11
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/hp-wireless.c | 132 +
3 files changed, 144 insertions(+)
create mode 100644 drivers/platform/x86/hp-wireless.c
diff
ike I'm wrong and it's purely
> used for sending this event. In that case, don't bother with the keymap
> at all and just hardcode KEY_RFKILL.
> --
> Matthew Garrett
--
Cheers,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe platform-dr
Signed-off-by: Alex Hung
---
drivers/platform/x86/Kconfig | 11 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/hp-wireless.c | 145 +
3 files changed, 157 insertions(+)
create mode 100644 drivers/platform/x86/hp-wireless.c
diff
Signed-off-by: Alex Hung
---
drivers/platform/x86/dell-wmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index fa9a217..60e0900 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86
Some HP BIOS has dummy WMI 0x05 cmd and it causes wireless set cmd to fail.
This patch fixes the problem by detecting "2009 BIOS or later" flag which
determines whether WMI 0x1b is supported and is used to replace WMI 0x05.
Signed-off-by: Alex Hung
---
drivers/platform/x86/hp-
Some new Thinkpad has a mute button with led. This mute led can out-of-sync
with mute in user interface. This kernel parameter disables the hardware
mute and led to avoid confusion. The hotkey will only issue scancode to UI.
Signed-off-by: Alex Hung
---
drivers/platform/x86/thinkpad_acpi.c | 14
Newer thinkpad models have a mute hotkey with a led to indicate
current mute states. Thinkpad BIOS provides ACPI interfaces for
getting and changing the hardware mute along with the led.
Signed-off-by: Alex Hung
---
drivers/platform/x86/thinkpad_acpi.c | 89
Newer Thinkpad models comes with a mute hotkey with a mute led. It also comes
with ACPI AML functions to control hardware mute + led. The patches add supports
to enable/disable and to change mute and its led via thinkpad-acpi.
Alex Hung (2):
thinkpad-acpi: add a kernel parameter to disable
Added in David and Tim who also has some ideas to share.
On Wed, Aug 14, 2013 at 3:00 PM, Matthew Garrett
wrote:
> On Wed, 2013-08-14 at 14:41 +0800, Alex Hung wrote:
>> Hi Matthew,
>>
>> The problem is that thinkpad-acpi does not aware of mute is changed by
>>
user changes mute state by user application.
This patch gives a chance to disable hardware mute.
Signed-off-by: Alex Hung
---
drivers/platform/x86/thinkpad_acpi.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform
Newer thinkpad models have a mute hotkey with a led to indicate
current mute states. Thinkpad BIOS provides ACPI interfaces for
getting and changing the hardware mute along with the led.
Signed-off-by: Alex Hung
---
drivers/platform/x86/thinkpad_acpi.c | 50
Newer Thinkpad models comes with a mute hotkey with a mute led. It also comes
with ACPI AML functions to control hardware mute + led. The patches add sysfs
nodes so it is possible to enable, disable and control from user-space.
Alex Hung (2):
thinkpad-acpi: add sysfs for getting and setting
HP laptops include a POST code error query 0x2A that reports
which point BIOS fails to boot at. The error code is kept in CMOS
until it is cleared.
Signed-off-by: Alex Hung
---
drivers/platform/x86/hp-wmi.c | 47 +
1 file changed, 47 insertions(+)
diff
HP laptops include a POST code error query 0x2A that reports
which point BIOS fails to boot at. The error code is kept in CMOS
until it is cleared.
Signed-off-by: Alex Hung
---
drivers/platform/x86/hp-wmi.c | 47 +
1 file changed, 47 insertions(+)
diff
New HP laptops start generating new events, and hp-wmi prints unknown
event_ids for them. This patch also removes these messages
Signed-off-by: Alex Hung
---
drivers/platform/x86/hp-wmi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/hp
On 07/28/2012 12:15 PM, Matthew Garrett wrote:
On Thu, Jul 19, 2012 at 09:43:21AM +0800, Alex Hung wrote:
+static struct acpi_device *wmi_device;
If a machine exports multiple WMI interfaces then having a static
acpi_device doesn't make sense here. Instead we probably need the API to
Signed-off-by: Alex Hung
---
drivers/platform/x86/wmi.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index a134c26..efc920b 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -114,6
il someone including myself works out a more
comprehensive solution.
Best Regards,
Alex Hung
On 04/11/2012 07:42 PM, Henrique de Moraes Holschuh wrote:
On Wed, 11 Apr 2012, Alex Hung wrote:
I am modifying thinkpad_acpi so it can support the mute led, and I
am looking for suggestions and feedba
On 06/27/2012 02:33 AM, Matthew Garrett wrote:
Is this the expected behaviour (ie, is this what happens on Windows as
well)?
Windows has an hotkey application called ATK. When Fn+F2 is pressed, it
displays options for turning on/off for WLAN and Bluebooth.
ASUS agreed this is better as the
and try to fix each of them. I don't
have a Asus Zenbook Prime but I can check on other available Asus machines.
Best Regards,
Alex Hung
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More ma
assigned in this case.
Signed-off-by: Alex Hung
---
drivers/platform/x86/asus-wmi.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 25e3093..0f69a97 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b
Hi All,
This patch needs to work with another fix in net/rfkill/core.c
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=commit;h=27e49ca95570c4685a32be9d4664f2b0b6d89368
On 06/20/2012 11:26 AM, Alex Hung wrote:
The original key event from Fn+F2 hotkey only toggles the
The original key event from Fn+F2 hotkey only toggles the state of wireless
LAN and leaves other wireless devices such as bluetooth uncontrolled. This
fix change Fn+F2 to generate an event to toggle all wireless devices.
Signed-off-by: Alex Hung
---
drivers/platform/x86/eeepc-wmi.c |2 +-
1
On 04/24/2012 04:40 PM, Alex Hung wrote:
The tp_features.bright_acpimode will not be set correctly for brightness
control because ACPI_VIDEO_HID will not be located in ACPI. As a result,
a duplicated key event will always be sent. acpi_video_backlight_support()
is sufficient to detect standard
: Alex Hung
---
drivers/platform/x86/thinkpad_acpi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 7b82868..7d032d5 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86
lowed && tpacpi_lifecycle != TPACPI_LIFE_INIT)*.
3. However, the changes now will changes the original behaviors (i.e.
"up", "down" and so on) if BIOS supports new SSMS and SHDA methods.
Any feedbacks and suggestions are most appreciated.
Best Regards,
Alex Hung
On 04/11/2012 06:15 PM
Signed-off-by: Alex Hung
---
drivers/platform/x86/thinkpad_acpi.c | 115 +++---
1 files changed, 106 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 7b82868..dc22a4c 100644
--- a/drivers
60 matches
Mail list logo
