Input: add Wistron driver
A driver for laptop buttons using an x86 BIOS interface that is
apparently used on quite a few laptops and seems to be originating
from Wistron.
This driver currently "knows" only about Fujitsu-Siemens Amilo Pro V2000
(i.e. it can detect the laptop using DMI and it contains the
keycode->key meaning mapping for this laptop) and Xeron SonicPro X 155G
(probably can't be reliably autodetected, requires a module parameter),
adding other laptops should be easy.
In addition to reporting button presses to the input layer the driver
also allows enabling/disabling the embedded wireless NIC (using the
"Wifi" button); this is done using the same BIOS interface, so it seems
only logical to keep the implementation together. Any flexibility
possibly gained by allowing users to remap the function of the "Wifi"
button is IMHO not worth it when weighted against the necessity to run
an user-space daemon to convert button presses to wifi state changes.
Signed-off-by: Miloslav Trmac <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
---
MAINTAINERS | 5
drivers/input/misc/Kconfig | 10
drivers/input/misc/Makefile | 1
drivers/input/misc/wistron_btns.c | 443 ++++++++++++++++++++++++++++++++++++++
4 files changed, 459 insertions(+)
Index: work/drivers/input/misc/Kconfig
===================================================================
--- work.orig/drivers/input/misc/Kconfig
+++ work/drivers/input/misc/Kconfig
@@ -40,6 +40,16 @@ config INPUT_M68K_BEEP
tristate "M68k Beeper support"
depends on M68K
+config INPUT_WISTRON_BTNS
+ tristate "x86 Wistron laptop button interface"
+ depends on X86
+ help
+ Say Y here for support of Winstron laptop button interface, used on
+ laptops of various brands, including Acer and Fujitsu-Siemens.
+
+ To compile this driver as a module, choose M here: the module will
+ be called wistron_btns.
+
config INPUT_UINPUT
tristate "User level driver support"
help
Index: work/drivers/input/misc/Makefile
===================================================================
--- work.orig/drivers/input/misc/Makefile
+++ work/drivers/input/misc/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_INPUT_PCSPKR) += pcspkr.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
obj-$(CONFIG_INPUT_98SPKR) += 98spkr.o
obj-$(CONFIG_INPUT_UINPUT) += uinput.o
+obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
Index: work/drivers/input/misc/wistron_btns.c
===================================================================
--- /dev/null
+++ work/drivers/input/misc/wistron_btns.c
@@ -0,0 +1,443 @@
+/*
+ * Wistron laptop button driver
+ * Copyright (C) 2005 Miloslav Trmac <[email protected]>
+ *
+ * You can redistribute and/or modify this program under the terms of the
+ * GNU General Public License version 2 as published by the Free Software
+ * Foundation.
+ *
+ * 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.
+ */
+#include <asm/io.h>
+#include <linux/dmi.h>
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mc146818rtc.h>
+#include <linux/module.h>
+#include <linux/preempt.h>
+#include <linux/string.h>
+#include <linux/timer.h>
+#include <linux/types.h>
+
+/*
+ * Number of attempts to read data from queue per poll;
+ * the queue can hold up to 31 entries
+ */
+#define MAX_POLL_ITERATIONS 64
+
+#define POLL_FREQUENCY 10 /* Number of polls per second */
+
+#if POLL_FREQUENCY > HZ
+#error "POLL_FREQUENCY too high"
+#endif
+
+MODULE_AUTHOR("Miloslav Trmac <[email protected]>");
+MODULE_DESCRIPTION("Wistron laptop button driver");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION("0.1");
+
+static int force; /* = 0; */
+module_param(force, bool, 0);
+MODULE_PARM_DESC(force, "Load even if computer is not in database");
+
+static char *keymap_name; /* = NULL; */
+module_param_named(keymap, keymap_name, charp, 0);
+MODULE_PARM_DESC(keymap, "Keymap name, if it can't be autodetected");
+
+ /* BIOS interface implementation */
+
+static void __iomem *bios_entry_point; /* BIOS routine entry point */
+static void __iomem *bios_code_map_base;
+static void __iomem *bios_data_map_base;
+
+static u8 cmos_address;
+
+struct regs {
+ u32 eax, ebx, ecx;
+};
+
+static void call_bios(struct regs *regs)
+{
+ unsigned long flags;
+
+ preempt_disable();
+ local_irq_save(flags);
+ asm volatile ("pushl %%ebp;"
+ "movl %7, %%ebp;"
+ "call *%6;"
+ "popl %%ebp"
+ : "=a" (regs->eax), "=b" (regs->ebx), "=c" (regs->ecx)
+ : "0" (regs->eax), "1" (regs->ebx), "2" (regs->ecx),
+ "m" (bios_entry_point), "m" (bios_data_map_base)
+ : "edx", "edi", "esi", "memory");
+ local_irq_restore(flags);
+ preempt_enable();
+}
+
+static size_t __init locate_wistron_bios(void __iomem *base)
+{
+ static const unsigned char __initdata signature[] =
+ { 0x42, 0x21, 0x55, 0x30 };
+ size_t offset;
+
+ for (offset = 0; offset < 0x10000; offset += 0x10) {
+ if (check_signature(base + offset, signature,
+ sizeof(signature)) != 0)
+ return offset;
+ }
+ return -1;
+}
+
+static int __init map_bios(void)
+{
+ void __iomem *base;
+ size_t offset;
+ u32 entry_point;
+
+ base = ioremap(0xF0000, 0x10000); /* Can't fail */
+ offset = locate_wistron_bios(base);
+ if (offset < 0) {
+ printk(KERN_ERR "wistron_btns: BIOS entry point not found\n");
+ iounmap(base);
+ return -ENODEV;
+ }
+
+ entry_point = readl(base + offset + 5);
+ printk(KERN_DEBUG
+ "wistron_btns: BIOS signature found at %p, entry point %08X\n",
+ base + offset, entry_point);
+
+ if (entry_point >= 0xF0000) {
+ bios_code_map_base = base;
+ bios_entry_point = bios_code_map_base + (entry_point & 0xFFFF);
+ } else {
+ iounmap(base);
+ bios_code_map_base = ioremap(entry_point & ~0x3FFF, 0x4000);
+ if (bios_code_map_base == NULL) {
+ printk(KERN_ERR
+ "wistron_btns: Can't map BIOS code at %08X\n",
+ entry_point & ~0x3FFF);
+ goto err;
+ }
+ bios_entry_point = bios_code_map_base + (entry_point & 0x3FFF);
+ }
+ /* The Windows driver maps 0x10000 bytes, we keep only one page... */
+ bios_data_map_base = ioremap(0x400, 0xc00);
+ if (bios_data_map_base == NULL) {
+ printk(KERN_ERR "wistron_btns: Can't map BIOS data\n");
+ goto err_code;
+ }
+ return 0;
+
+err_code:
+ iounmap(bios_code_map_base);
+err:
+ return -ENOMEM;
+}
+
+static void __exit unmap_bios(void)
+{
+ iounmap(bios_code_map_base);
+ iounmap(bios_data_map_base);
+}
+
+ /* BIOS calls */
+
+static u16 bios_pop_queue(void)
+{
+ struct regs regs;
+
+ memset(®s, 0, sizeof (regs));
+ regs.eax = 0x9610;
+ regs.ebx = 0x061C;
+ regs.ecx = 0x0000;
+ call_bios(®s);
+
+ return regs.eax;
+}
+
+static void __init bios_attach(void)
+{
+ struct regs regs;
+
+ memset(®s, 0, sizeof (regs));
+ regs.eax = 0x9610;
+ regs.ebx = 0x012E;
+ call_bios(®s);
+}
+
+static void __exit bios_detach(void)
+{
+ struct regs regs;
+
+ memset(®s, 0, sizeof (regs));
+ regs.eax = 0x9610;
+ regs.ebx = 0x002E;
+ call_bios(®s);
+}
+
+static u8 __init bios_get_cmos_address(void)
+{
+ struct regs regs;
+
+ memset(®s, 0, sizeof (regs));
+ regs.eax = 0x9610;
+ regs.ebx = 0x051C;
+ call_bios(®s);
+
+ return regs.ecx;
+}
+
+static u16 __init bios_wifi_get_default_setting(void)
+{
+ struct regs regs;
+
+ memset(®s, 0, sizeof (regs));
+ regs.eax = 0x9610;
+ regs.ebx = 0x0235;
+ call_bios(®s);
+
+ return regs.eax;
+}
+
+static void bios_wifi_set_state(int enable)
+{
+ struct regs regs;
+
+ memset(®s, 0, sizeof (regs));
+ regs.eax = 0x9610;
+ regs.ebx = enable ? 0x0135 : 0x0035;
+ call_bios(®s);
+}
+
+ /* Hardware database */
+
+struct key_entry {
+ char type; /* See KE_* below */
+ u8 code;
+ unsigned keycode; /* For KE_KEY */
+};
+
+enum { KE_END, KE_KEY, KE_WIFI };
+
+static const struct key_entry *keymap; /* = NULL; Current key map */
+static int have_wifi;
+
+static int __init dmi_matched(struct dmi_system_id *dmi)
+{
+ const struct key_entry *key;
+
+ keymap = dmi->driver_data;
+ for (key = keymap; key->type != KE_END; key++) {
+ if (key->type == KE_WIFI) {
+ have_wifi = 1;
+ break;
+ }
+ }
+ return 1;
+}
+
+static struct key_entry keymap_empty[] = {
+ { KE_END, 0 }
+};
+
+static struct key_entry keymap_fs_amilo_pro_v2000[] = {
+ { KE_KEY, 0x01, KEY_HELP },
+ { KE_KEY, 0x11, KEY_PROG1 },
+ { KE_KEY, 0x12, KEY_PROG2 },
+ { KE_WIFI, 0x30, 0 },
+ { KE_KEY, 0x31, KEY_MAIL },
+ { KE_KEY, 0x36, KEY_WWW },
+ { KE_END, 0 }
+};
+
+static struct key_entry keymap_wistron_ms2141[] = {
+ { KE_KEY, 0x11, KEY_PROG1 },
+ { KE_KEY, 0x12, KEY_PROG2 },
+ { KE_WIFI, 0x30, 0 },
+ { KE_KEY, 0x22, KEY_REWIND },
+ { KE_KEY, 0x23, KEY_FORWARD },
+ { KE_KEY, 0x24, KEY_PLAYPAUSE },
+ { KE_KEY, 0x25, KEY_STOPCD },
+ { KE_KEY, 0x31, KEY_MAIL },
+ { KE_KEY, 0x36, KEY_WWW },
+ { KE_END, 0 }
+};
+
+/*
+ * If your machine is not here (which is currently rather likely), please send
+ * a list of buttons and their key codes (reported when loading this module
+ * with force=1) and the output of dmidecode to $MODULE_AUTHOR.
+ */
+static struct dmi_system_id dmi_ids[] = {
+ {
+ .callback = dmi_matched,
+ .ident = "Fujitsu-Siemens Amilo Pro V2000",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "AMILO Pro V2000"),
+ },
+ .driver_data = keymap_fs_amilo_pro_v2000
+ },
+ { 0, }
+};
+
+static int __init select_keymap(void)
+{
+ if (keymap_name != NULL) {
+ if (strcmp (keymap_name, "1557/MS2141") == 0)
+ keymap = keymap_wistron_ms2141;
+ else {
+ printk(KERN_ERR "wistron_btns: Keymap unknown\n");
+ return -EINVAL;
+ }
+ }
+ dmi_check_system(dmi_ids);
+ if (keymap == NULL) {
+ if (!force) {
+ printk(KERN_ERR "wistron_btns: System unknown\n");
+ return -ENODEV;
+ }
+ keymap = keymap_empty;
+ }
+ return 0;
+}
+
+ /* Input layer interface */
+
+static struct input_dev input_dev = {
+ .name = "Wistron laptop buttons",
+};
+
+static void __init setup_input_dev(void)
+{
+ const struct key_entry *key;
+
+ for (key = keymap; key->type != KE_END; key++) {
+ if (key->type == KE_KEY) {
+ input_dev.evbit[LONG(EV_KEY)] = BIT(EV_KEY);
+ input_dev.keybit[LONG(key->keycode)]
+ |= BIT(key->keycode);
+ }
+ }
+
+ input_register_device(&input_dev);
+}
+
+static void report_key(unsigned keycode)
+{
+ input_report_key(&input_dev, keycode, 1);
+ input_sync(&input_dev);
+ input_report_key(&input_dev, keycode, 0);
+ input_sync(&input_dev);
+}
+
+ /* Driver core */
+
+static int wifi_enabled;
+
+static void poll_bios(unsigned long);
+
+static struct timer_list poll_timer = TIMER_INITIALIZER(poll_bios, 0, 0);
+
+static void handle_key(u8 code)
+{
+ const struct key_entry *key;
+
+ for (key = keymap; key->type != KE_END; key++) {
+ if (code == key->code) {
+ switch (key->type) {
+ case KE_KEY:
+ report_key(key->keycode);
+ break;
+
+ case KE_WIFI:
+ if (have_wifi) {
+ wifi_enabled = !wifi_enabled;
+ bios_wifi_set_state(wifi_enabled);
+ }
+ break;
+
+ case KE_END:
+ default:
+ BUG();
+ }
+ return;
+ }
+ }
+ printk(KERN_NOTICE "wistron_btns: Unknown key code %02X\n", code);
+}
+
+static void poll_bios(unsigned long discard)
+{
+ u8 qlen;
+ u16 val;
+
+ for (;;) {
+ qlen = CMOS_READ(cmos_address);
+ if (qlen == 0)
+ break;
+ val = bios_pop_queue();
+ if (val != 0 && !discard)
+ handle_key((u8)val);
+ }
+
+ mod_timer(&poll_timer, jiffies + HZ / POLL_FREQUENCY);
+}
+
+static int __init wb_module_init(void)
+{
+ int err;
+
+ err = select_keymap();
+ if (err)
+ return err;
+ err = map_bios();
+ if (err)
+ return err;
+ bios_attach();
+ cmos_address = bios_get_cmos_address();
+ if (have_wifi) {
+ switch (bios_wifi_get_default_setting()) {
+ case 0x01:
+ wifi_enabled = 0;
+ break;
+
+ case 0x03:
+ wifi_enabled = 1;
+ break;
+
+ default:
+ have_wifi = 0;
+ break;
+ }
+ if (have_wifi)
+ bios_wifi_set_state(wifi_enabled);
+ }
+
+ setup_input_dev();
+
+ poll_bios(1); /* Flush stale event queue and arm timer */
+
+ return 0;
+}
+
+static void __exit wb_module_exit(void)
+{
+ del_timer_sync(&poll_timer);
+ input_unregister_device(&input_dev);
+ bios_detach();
+ unmap_bios();
+}
+
+module_init(wb_module_init);
+module_exit(wb_module_exit);
Index: work/MAINTAINERS
===================================================================
--- work.orig/MAINTAINERS
+++ work/MAINTAINERS
@@ -2891,6 +2891,11 @@ M: [email protected]
L: [email protected]
S: Maintained
+WISTRON LAPTOP BUTTON DRIVER
+P: Miloslav Trmac
+M: [email protected]
+S: Maintained
+
WL3501 WIRELESS PCMCIA CARD DRIVER
P: Arnaldo Carvalho de Melo
M: [email protected]
>
>Yu, Luming wrote:
>> I just tested module wistron_btn on one Acer Aspire laptop after
>> adding one dmi entry. The wistron_btn found BIOS interfaces.
>> One visible error is the bluetooth light won't turn on upon
>> stroking bluetooth button.
>> Without wistron_btn module, the bluetooth light works.
>> with acpi enabled, I didn't try acpi disabled)
>>
>> wistron_btn polls a cmos address to detect hotkey event. It
>> is not necessary, because there do have ACPI interrupt
>triggered upon
>> hotkeys.
>There are many different laptops using similar interfaces.
>It is a mess :(
>
>If your laptop provides the hotkey events via ACPI, simply don't use
>wistron_btns.
wistron driver should be disabled if acpi hotkey enabled.
>
>> So, my suggestion is to disable this module when ACPI enabled.
>I have a laptop that needs this module (hotkeys are not supported via
>ACPI), but supports ACPI.
Could you share me acpidump output of your laptop?
Please attach it at :
http://bugzilla.kernel.org/show_bug.cgi?id=5692
>On 12/2/05, Yu, Luming <[email protected]> wrote:
>> I just tested module wistron_btn on one Acer Aspire laptop after
>> adding one dmi entry. The wistron_btn found BIOS interfaces.
>> One visible error is the bluetooth light won't turn on upon
>> stroking bluetooth button.
>> Without wistron_btn module, the bluetooth light works.
>> with acpi enabled, I didn't try acpi disabled)
>>
>
>Did you add the new keymap table with KE_BLUETOOTH to go with
>that DMI entry?
Yes, I added.
>
>> wistron_btn polls a cmos address to detect hotkey event. It
>> is not necessary, because there do have ACPI interrupt triggered upon
>> hotkeys.
>>
>
>Unfortunately ACPI does not route these events through the input layer
>so aside from special buttons (like sleep) it is not very useful.
There are acpi daemon for any evetnts that needs user space attention.
I'm not sure if these events should be routed to input layer.
But, we can do that.
>
>> So, my suggestion is to disable this module when ACPI enabled.
>> We need to implement hotkey support from ACPI subsystem for my
>> Acer aspire laptop.
>
>I do not agree.
For my acer aspire laptop.
I added dmi entry, and keymap.
With acpi disabled, bluetooth light doesn't work
With acpi disabled + wistron module, bluetooth light doesn't work.
With acpi enabled + wistron module, bluetooth light doesn't work
With acpi enabled - wistron module, bluetooth works.
>From these test cases, do you still think wistron driver can help my
laptop?
Thanks,
Luming
Yu, Luming wrote:
>>If your laptop provides the hotkey events via ACPI, simply don't use
>>wistron_btns.
>
>
> wistron driver should be disabled if acpi hotkey enabled.
It is implicitly disabled because it contains DMI ids of known laptops,
and its module_init() fails with -ENODEV when used on other hardware,
before ever touching the BIOS.
I therefore can't see how it could break anything unless you have
explicitly supplied module parameters to override this check.
Mirek
Miloslav Trmac wrote:
> Yu, Luming wrote:
>>>> I just tested module wistron_btn on one Acer Aspire laptop after
>>>> adding one dmi entry. The wistron_btn found BIOS interfaces.
>>>If your laptop provides the hotkey events via ACPI, simply don't use
>>>wistron_btns.
>>
>>wistron driver should be disabled if acpi hotkey enabled.
>
> It is implicitly disabled because it contains DMI ids of known laptops,
> and its module_init() fails with -ENODEV when used on other hardware,
> before ever touching the BIOS.
>
> I therefore can't see how it could break anything unless you have
> explicitly supplied module parameters to override this check.
On second thought, do you by "found BIOS interfaces" mean "found BIOS
interfaces when asked to" or "matched the existing Aspire 1500 DMI ID"?
Thanks,
Mirek
>Yu, Luming wrote:
>>>If your laptop provides the hotkey events via ACPI, simply don't use
>>>wistron_btns.
>>
>>
>> wistron driver should be disabled if acpi hotkey enabled.
>It is implicitly disabled because it contains DMI ids of known laptops,
>and its module_init() fails with -ENODEV when used on other hardware,
>before ever touching the BIOS.
>
>I therefore can't see how it could break anything unless you have
>explicitly supplied module parameters to override this check.
> Mirek
>
My concern is if ACPI enabled those box could NOT work with Wistron
driver.
>Miloslav Trmac wrote:
>> Yu, Luming wrote:
>>>>> I just tested module wistron_btn on one Acer Aspire laptop after
>>>>> adding one dmi entry. The wistron_btn found BIOS interfaces.
>
>>>>If your laptop provides the hotkey events via ACPI, simply don't use
>>>>wistron_btns.
>>>
>>>wistron driver should be disabled if acpi hotkey enabled.
>>
>> It is implicitly disabled because it contains DMI ids of
>known laptops,
>> and its module_init() fails with -ENODEV when used on other hardware,
>> before ever touching the BIOS.
>>
>> I therefore can't see how it could break anything unless you have
>> explicitly supplied module parameters to override this check.
>On second thought, do you by "found BIOS interfaces" mean "found BIOS
>interfaces when asked to" or "matched the existing Aspire 1500 DMI ID"?
I found this in dmesg:
wistron_btns: BIOS signature found at c00f6920, entry point 000FDC10
input: Wistron laptop buttons as /class/input/input2
>
>Thanks,
> Mirek
>
On 12/6/05, Yu, Luming <[email protected]> wrote:
> >> wistron_btn polls a cmos address to detect hotkey event. It
> >> is not necessary, because there do have ACPI interrupt triggered upon
> >> hotkeys.
> >>
> >
> >Unfortunately ACPI does not route these events through the input layer
> >so aside from special buttons (like sleep) it is not very useful.
>
> There are acpi daemon for any evetnts that needs user space attention.
> I'm not sure if these events should be routed to input layer.
How do you suggest handle buttons such as "Mail", "WWW", etc? Through
acpid? And then tunnel them to X somewhow?
> But, we can do that.
>
> >
> >> So, my suggestion is to disable this module when ACPI enabled.
> >> We need to implement hotkey support from ACPI subsystem for my
> >> Acer aspire laptop.
> >
> >I do not agree.
>
> For my acer aspire laptop.
> I added dmi entry, and keymap.
>
> With acpi disabled, bluetooth light doesn't work
> With acpi disabled + wistron module, bluetooth light doesn't work.
>
> With acpi enabled + wistron module, bluetooth light doesn't work
>
> With acpi enabled - wistron module, bluetooth works.
> From these test cases, do you still think wistron driver can help my
> laptop?
>
No, you have proven that the driver will not help to your laptop. Now,
as it is, it won't even load on your laptop either, because of
different DMI signature. So why are you complaining? I am pretty sure
Bernhard (who added bluetooth handling) has his working with ACPI.
Bernhard, any input on this?
--
Dmitry
Yu, Luming wrote:
>>On second thought, do you by "found BIOS interfaces" mean "found BIOS
>>interfaces when asked to" or "matched the existing Aspire 1500 DMI ID"?
>
> I found this in dmesg:
>
> wistron_btns: BIOS signature found at c00f6920, entry point 000FDC10
> input: Wistron laptop buttons as /class/input/input2
OK, please attach the output of dmidecode (here or to #5692).
I have attached my acpidump there.
Bero, can you please test whether the ACPI hotkey driver would work for you?
If so, I'll remove the Acer Aspire 1500 entry.
If not, please attach the output of dmidecode too, we'll try to find out
how to differentiate between the laptops
Thanks,
Mirek
On Tuesday 06 December 2005 15:21, Dmitry Torokhov wrote:
Hi, sorry for the delay, just returning from Spain...
> > There are acpi daemon for any evetnts that needs user space attention.
> > I'm not sure if these events should be routed to input layer.
>
> How do you suggest handle buttons such as "Mail", "WWW", etc? Through
> acpid? And then tunnel them to X somewhow?
I think routing them to the input layer makes most sense because they are keys
like everything else -- of course hacking acpid to pass on ACPI key events to
Xorg via the XTest extension is not exactly hard, but that would break the
keys in text mode (who knows, maybe someone wants to map his mail key to
"mutt[RETURN]"?), and of course launching an application from acpid is a bit
hard (acpid runs as root --> need to figure out which user is pressed the
button, switch user IDs, find the correct X display if any, .....) if it's an
input event, solutions for the expected functionality already exist - e.g.
khotkeys.
> > With acpi enabled - wistron module, bluetooth works.
> > From these test cases, do you still think wistron driver can help my
> > laptop?
>
> No, you have proven that the driver will not help to your laptop. Now,
> as it is, it won't even load on your laptop either, because of
> different DMI signature. So why are you complaining? I am pretty sure
> Bernhard (who added bluetooth handling) has his working with ACPI.
> Bernhard, any input on this?
I have ACPI + wistron module. Can't tell if bluetooth actually works because I
don't have any bluetooth hardware, but I can tell the bluetooth LED can be
turned on and off.
ACPI works on this box, but not the ACPI buttons stuff (guess they aren't
following standards...). I'm running a modified 2.6.15-rc5-mm1 here (none of
the modifications touch ACPI though).
On Sun, Dec 11, 2005 at 01:10:13PM +0000, Bernhard Rosenkraenzer wrote:
> On Tuesday 06 December 2005 15:21, Dmitry Torokhov wrote:
>
> Hi, sorry for the delay, just returning from Spain...
>
> > > There are acpi daemon for any evetnts that needs user space attention.
> > > I'm not sure if these events should be routed to input layer.
> >
> > How do you suggest handle buttons such as "Mail", "WWW", etc? Through
> > acpid? And then tunnel them to X somewhow?
>
> I think routing them to the input layer makes most sense because they are keys
> like everything else -- of course hacking acpid to pass on ACPI key events to
> Xorg via the XTest extension is not exactly hard, but that would break the
> keys in text mode (who knows, maybe someone wants to map his mail key to
> "mutt[RETURN]"?), and of course launching an application from acpid is a bit
> hard (acpid runs as root --> need to figure out which user is pressed the
> button, switch user IDs, find the correct X display if any, .....) if it's an
> input event, solutions for the expected functionality already exist - e.g.
> khotkeys.
You also can hack acpid to use uinput to feed the events back to the
input subsystem, but I agree with you that going there directly is
probably the best way to go.
> > > With acpi enabled - wistron module, bluetooth works.
> > > From these test cases, do you still think wistron driver can help my
> > > laptop?
> >
> > No, you have proven that the driver will not help to your laptop. Now,
> > as it is, it won't even load on your laptop either, because of
> > different DMI signature. So why are you complaining? I am pretty sure
> > Bernhard (who added bluetooth handling) has his working with ACPI.
> > Bernhard, any input on this?
>
> I have ACPI + wistron module. Can't tell if bluetooth actually works because I
> don't have any bluetooth hardware, but I can tell the bluetooth LED can be
> turned on and off.
You should see the bluetooth USB device appearing and disappearing in
'lsusb'.
> ACPI works on this box, but not the ACPI buttons stuff (guess they aren't
> following standards...). I'm running a modified 2.6.15-rc5-mm1 here (none of
> the modifications touch ACPI though).
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Stefan Seyfried <[email protected]> wrote:
>
> In article <[email protected]> you wrote:
> > On Sun, Dec 11, 2005 at 01:10:13PM +0000, Bernhard Rosenkraenzer wrote:
> >> I think routing them to the input layer makes most sense because they are keys
> >> like everything else -- of course hacking acpid to pass on ACPI key events to
> >> Xorg via the XTest extension is not exactly hard, but that would break the
> >> keys in text mode (who knows, maybe someone wants to map his mail key to
> >> "mutt[RETURN]"?), and of course launching an application from acpid is a bit
> >> hard (acpid runs as root --> need to figure out which user is pressed the
> >> button, switch user IDs, find the correct X display if any, .....) if it's an
> >> input event, solutions for the expected functionality already exist - e.g.
> >> khotkeys.
> >
> > You also can hack acpid to use uinput to feed the events back to the
> > input subsystem, but I agree with you that going there directly is
> > probably the best way to go.
>
> pcc_acpi already does this successfully and is a pleasure to use.
That's not in the tree any more. Did something replace it?
On Mon, Dec 12, 2005 at 12:13:15AM -0800, Andrew Morton wrote:
> Stefan Seyfried <[email protected]> wrote:
> > pcc_acpi already does this successfully and is a pleasure to use.
>
> That's not in the tree any more. Did something replace it?
No. The ACPI Mafia^H^H^Hintainers :-) no longer accept any hotkey drivers
and IIUC it will be reimplemented in a generic driver. This driver
then should pipe the hotkey events to the input subsystem.
Disclaimer: i cannot judge if the pcc_acpi code is "nice" or particularly
correct, but it works fine (for me).
--
Stefan Seyfried \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, N?rnberg \ -- Leonard Cohen
Stefan Seyfried <[email protected]> wrote:
>
> On Mon, Dec 12, 2005 at 12:13:15AM -0800, Andrew Morton wrote:
> > Stefan Seyfried <[email protected]> wrote:
>
> > > pcc_acpi already does this successfully and is a pleasure to use.
> >
> > That's not in the tree any more. Did something replace it?
>
> No. The ACPI Mafia^H^H^Hintainers :-) no longer accept any hotkey drivers
> and IIUC it will be reimplemented in a generic driver. This driver
> then should pipe the hotkey events to the input subsystem.
hm. It seems a fairly bad idea to remove functionality before that
functionality has been implemented by the other means and has been rolled
out by distros for some time.
On Mon, Dec 12, 2005 at 01:38:44AM -0800, Andrew Morton wrote:
> Stefan Seyfried <[email protected]> wrote:
> > No. The ACPI Mafia^H^H^Hintainers :-) no longer accept any hotkey drivers
> > and IIUC it will be reimplemented in a generic driver. This driver
> > then should pipe the hotkey events to the input subsystem.
>
> hm. It seems a fairly bad idea to remove functionality before that
> functionality has been implemented by the other means and has been rolled
> out by distros for some time.
pcc_acpi never was in the acpi tree or in mainline AFAIK.
But it is nevertheless an example that it is not too hard to route hotkey
events through the input subsystem :-)
--
Stefan Seyfried \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, N?rnberg \ -- Leonard Cohen
Stefan Seyfried <[email protected]> wrote:
>
> On Mon, Dec 12, 2005 at 01:38:44AM -0800, Andrew Morton wrote:
> > Stefan Seyfried <[email protected]> wrote:
> > > No. The ACPI Mafia^H^H^Hintainers :-) no longer accept any hotkey drivers
> > > and IIUC it will be reimplemented in a generic driver. This driver
> > > then should pipe the hotkey events to the input subsystem.
> >
> > hm. It seems a fairly bad idea to remove functionality before that
> > functionality has been implemented by the other means and has been rolled
> > out by distros for some time.
>
> pcc_acpi never was in the acpi tree or in mainline AFAIK.
It was in my tree in March 2005. I guess it's one of those things that
never got merged further.
> But it is nevertheless an example that it is not too hard to route hotkey
> events through the input subsystem :-)
Well whatever - it's an area in which we sorely need more functionality.
How long have we been waiting for the "proper" implementations?