Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Rolf Eike Beer wrote:

Renato S. Yamane wrote:

Rolf Eike Beer wrote:

Richard Hughes wrote:


Yes, although this is out of my area or expertise, sorry.


I've looked a bit but can't find any driver interaction of those
programs. Any further ideas welcome.


Do you try omnibook driver?
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try
this module above and now I can change brightness writing in
/proc/omnibook/lcd and kpowersave can change brightness too.


Oh wow! Even my Multimedia keys get recognized. Thanks very much for your 
pointer.


I think that is a good idea more support to Toshiba Laptops, so 
omnibook+toshiba_acpi is a perfect couple, because some functions works 
with toshiba_acpi and others works with omnibook.


Jaime (in cc too) do a very useful module that work in some laptop 
models that not work on toshiba_acpi and omnibook driver.


So, I think that is a very good idea all work together to do a more 
powerful (and compatible) module in next kernel releases.


Regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Rolf Eike Beer wrote:

Renato S. Yamane wrote:

Rolf Eike Beer wrote:

Richard Hughes wrote:


Yes, although this is out of my area or expertise, sorry.


I've looked a bit but can't find any driver interaction of those
programs. Any further ideas welcome.


Do you try omnibook driver?
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try
this module above and now I can change brightness writing in
/proc/omnibook/lcd and kpowersave can change brightness too.


Oh wow! Even my Multimedia keys get recognized. Thanks very much for your 
pointer.


I think that is a good idea more support to Toshiba Laptops, so 
omnibook+toshiba_acpi is a perfect couple, because some functions works 
with toshiba_acpi and others works with omnibook.


Jaime (in cc too) do a very useful module that work in some laptop 
models that not work on toshiba_acpi and omnibook driver.


So, I think that is a very good idea all work together to do a more 
powerful (and compatible) module in next kernel releases.


Regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Renato S. Yamane wrote:
> Rolf Eike Beer wrote:
> > Richard Hughes wrote:
> >> Yes, although this is out of my area or expertise, sorry.
> >
> > I've looked a bit but can't find any driver interaction of those
> > programs. Any further ideas welcome.
>
> Do you try omnibook driver?
> svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk
>
> toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try
> this module above and now I can change brightness writing in
> /proc/omnibook/lcd and kpowersave can change brightness too.
>
> But, is impossible use multimedia keys (play, pause, browser, etc) and
> couple keys (fn-fx), because Fn key and Multimedia keys don't is
> recognized.

Oh wow! Even my Multimedia keys get recognized. Thanks very much for your 
pointer.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Renato S. Yamane wrote:
 Rolf Eike Beer wrote:
  Richard Hughes wrote:
  Yes, although this is out of my area or expertise, sorry.
 
  I've looked a bit but can't find any driver interaction of those
  programs. Any further ideas welcome.

 Do you try omnibook driver?
 svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

 toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try
 this module above and now I can change brightness writing in
 /proc/omnibook/lcd and kpowersave can change brightness too.

 But, is impossible use multimedia keys (play, pause, browser, etc) and
 couple keys (fn-fx), because Fn key and Multimedia keys don't is
 recognized.

Oh wow! Even my Multimedia keys get recognized. Thanks very much for your 
pointer.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Rolf Eike Beer wrote:

Richard Hughes wrote:

Yes, although this is out of my area or expertise, sorry.


I've looked a bit but can't find any driver interaction of those programs. Any 
further ideas welcome.


Do you try omnibook driver?
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try 
this module above and now I can change brightness writing in 
/proc/omnibook/lcd and kpowersave can change brightness too.


But, is impossible use multimedia keys (play, pause, browser, etc) and 
couple keys (fn-fx), because Fn key and Multimedia keys don't is recognized.


Regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
> On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote:
>> Richard Hughes wrote:
>>> On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
 None of the above keys generated a key event. Neither does
 "Brightness down", but it still works. "Brightness up" generates an event
 and works.
>>
 Kpowersave tells me it can't do brightness switching in software
 (which works in WinXtraPain).
>>
>> Yes, I need a special process running for this. Would it be of some
>> use if I take a look with IRPtracker on it or is that all you need to
>> know?
>
> Yes, although this is out of my area or expertise, sorry.

I've looked a bit but can't find any driver interaction of those programs. Any 
further ideas welcome.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
 On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote:
 Richard Hughes wrote:
 On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
 None of the above keys generated a key event. Neither does
 Brightness down, but it still works. Brightness up generates an event
 and works.

 Kpowersave tells me it can't do brightness switching in software
 (which works in WinXtraPain).

 Yes, I need a special process running for this. Would it be of some
 use if I take a look with IRPtracker on it or is that all you need to
 know?

 Yes, although this is out of my area or expertise, sorry.

I've looked a bit but can't find any driver interaction of those programs. Any 
further ideas welcome.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Rolf Eike Beer wrote:

Richard Hughes wrote:

Yes, although this is out of my area or expertise, sorry.


I've looked a bit but can't find any driver interaction of those programs. Any 
further ideas welcome.


Do you try omnibook driver?
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try 
this module above and now I can change brightness writing in 
/proc/omnibook/lcd and kpowersave can change brightness too.


But, is impossible use multimedia keys (play, pause, browser, etc) and 
couple keys (fn-fx), because Fn key and Multimedia keys don't is recognized.


Regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote:
> Richard Hughes wrote:
> > On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
> > > None of the above keys generated a key event. Neither does
> "Brightness
> > > down", but it still works. "Brightness up" generates an event and
> works.
> > > Kpowersave tells me it can't do brightness switching in software
> (which
> > > works in WinXtraPain).
> Yes, I need a special process running for this. Would it be of some
> use if I take a look with IRPtracker on it or is that all you need to
> know?

Yes, although this is out of my area or expertise, sorry.

Richard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
> On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
> > None of the above keys generated a key event. Neither does "Brightness
> > down", but it still works. "Brightness up" generates an event and works.
> > Kpowersave tells me it can't do brightness switching in software (which
> > works in WinXtraPain).
>
> Do you know how windows does this? Do you have to load a special
> system-try thing to make the keys work?

Yes, I need a special process running for this. Would it be of some use if I 
take a look with IRPtracker on it or is that all you need to know?

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
 On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
  None of the above keys generated a key event. Neither does Brightness
  down, but it still works. Brightness up generates an event and works.
  Kpowersave tells me it can't do brightness switching in software (which
  works in WinXtraPain).

 Do you know how windows does this? Do you have to load a special
 system-try thing to make the keys work?

Yes, I need a special process running for this. Would it be of some use if I 
take a look with IRPtracker on it or is that all you need to know?

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote:
 Richard Hughes wrote:
  On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
   None of the above keys generated a key event. Neither does
 Brightness
   down, but it still works. Brightness up generates an event and
 works.
   Kpowersave tells me it can't do brightness switching in software
 (which
   works in WinXtraPain).
 Yes, I need a special process running for this. Would it be of some
 use if I take a look with IRPtracker on it or is that all you need to
 know?

Yes, although this is out of my area or expertise, sorry.

Richard.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
> On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
> > None of the above keys generated a key event. Neither does "Brightness
> > down", but it still works. "Brightness up" generates an event and works.
> > Kpowersave tells me it can't do brightness switching in software (which
> > works in WinXtraPain).
>
> Do you know how windows does this? Do you have to load a special
> system-try thing to make the keys work?

I'll have a look once I find time to boot Windows.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
> None of the above keys generated a key event. Neither does "Brightness down", 
> but it still works. "Brightness up" generates an event and works. Kpowersave 
> tells me it can't do brightness switching in software (which works in 
> WinXtraPain).

Do you know how windows does this? Do you have to load a special
system-try thing to make the keys work?

Richard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
> Attached patch adds a kernel thread to do polling on Toshiba hardware.

Is there something similar available to support other Toshiba laptops? I own a 
A110-178 that is not supported by the driver but has a lot of keys that I 
can't use currently:

Fn:
-screen zoom (I actually don't care about this one)
-S2RAM
-S2Disk
-Mute*

Multimedia:
-Browser
-Video player
-Play/pause
-Stop
-Forward
-Reverse

*Mute: it's a bit special. If I use it I can an on screen display (mute/sound) 
but regardless of which setting is displayed the sound is still there.

None of the above keys generated a key event. Neither does "Brightness down", 
but it still works. "Brightness up" generates an event and works. Kpowersave 
tells me it can't do brightness switching in software (which works in 
WinXtraPain).

If you need an acpidump or I can do some testing just ask.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
 Attached patch adds a kernel thread to do polling on Toshiba hardware.

Is there something similar available to support other Toshiba laptops? I own a 
A110-178 that is not supported by the driver but has a lot of keys that I 
can't use currently:

Fn:
-screen zoom (I actually don't care about this one)
-S2RAM
-S2Disk
-Mute*

Multimedia:
-Browser
-Video player
-Play/pause
-Stop
-Forward
-Reverse

*Mute: it's a bit special. If I use it I can an on screen display (mute/sound) 
but regardless of which setting is displayed the sound is still there.

None of the above keys generated a key event. Neither does Brightness down, 
but it still works. Brightness up generates an event and works. Kpowersave 
tells me it can't do brightness switching in software (which works in 
WinXtraPain).

If you need an acpidump or I can do some testing just ask.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
 None of the above keys generated a key event. Neither does Brightness down, 
 but it still works. Brightness up generates an event and works. Kpowersave 
 tells me it can't do brightness switching in software (which works in 
 WinXtraPain).

Do you know how windows does this? Do you have to load a special
system-try thing to make the keys work?

Richard.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
 On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
  None of the above keys generated a key event. Neither does Brightness
  down, but it still works. Brightness up generates an event and works.
  Kpowersave tells me it can't do brightness switching in software (which
  works in WinXtraPain).

 Do you know how windows does this? Do you have to load a special
 system-try thing to make the keys work?

I'll have a look once I find time to boot Windows.

Eike


signature.asc
Description: This is a digitally signed message part.

Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Richard Hughes wrote:

What's the status of this patch? Good for merging? Do you want me to
redo the current patch using input-polldev and the new setkeycode stuff?


A detail:
I receive error message (no such device) when I try load toshiba_acpi on 
my Toshiba M45-S355 (BIOS is Toshiba and NOT Phoenix).


So, I can't change brightness of LCD.

To solve it, I use omnibook driver available in:


Last SVN can get with:
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

With omnibook driver I can change brightness writing in /proc/omnibook/lcd

Only one problem: multimedia keys don't is recognized by xev and I can't 
configure it with omnibook driver.


Best regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Richard Hughes wrote:

What's the status of this patch? Good for merging? Do you want me to
redo the current patch using input-polldev and the new setkeycode stuff?


A detail:
I receive error message (no such device) when I try load toshiba_acpi on 
my Toshiba M45-S355 (BIOS is Toshiba and NOT Phoenix).


So, I can't change brightness of LCD.

To solve it, I use omnibook driver available in:
http://omnibook.sourceforge.net

Last SVN can get with:
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

With omnibook driver I can change brightness writing in /proc/omnibook/lcd

Only one problem: multimedia keys don't is recognized by xev and I can't 
configure it with omnibook driver.


Best regards,
Renato S. Yamane
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Fri, 2007-06-08 at 10:23 -0400, Dmitry Torokhov wrote:
> On 6/7/07, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
> > >
> > >
> > > It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
> > > Lock/Screensaver
> > > so your interpretation is indeed correct. I guess I better add an
> > > alias to
> > > input.h
> >
> > What's the status of this patch? Good for merging?
> 
> Not my call - John is the official maintainer of the driver. However
> from input layer POV it looks good.

Good, thanks.

> > Do you want me to
> > redo the current patch using input-polldev
> 
> The patch I send to you earlier already does this. I am attaching a
> refreshed version that used KEY_COFFEE instead of KEY_BREAK.

Brilliant, these look great.

> > and the new setkeycode stuff?
> 
> And I have the patch doing this as well (attached). If you could
> please give it a try I'd appreciate it.

You beat me to it {hastily removes item from TODO...} :-)

I'll give it a try as soon as possible, thanks.

Richard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Dmitry Torokhov]

On 6/7/07, Richard Hughes <[EMAIL PROTECTED]> wrote:

On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
>
>
> It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
> Lock/Screensaver
> so your interpretation is indeed correct. I guess I better add an
> alias to
> input.h

What's the status of this patch? Good for merging?


Not my call - John is the official maintainer of the driver. However
from input layer POV it looks good.


Do you want me to
redo the current patch using input-polldev


The patch I send to you earlier already does this. I am attaching a
refreshed version that used KEY_COFFEE instead of KEY_BREAK.


and the new setkeycode stuff?


And I have the patch doing this as well (attached). If you could
please give it a try I'd appreciate it.

--
Dmitry
From: Richard Hughes <[EMAIL PROTECTED]>
Subject: toshiba_acpi: integrate with INPUT layer

Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events now matched to a list of toshiba specific
scancodes, and are squirted to userspace using the INPUT subsystem.

This means that toshiba laptops buttons "just work" without any
userspace daemon (using uinput) such as fnfx or bodges such as using a
userspace hal addon. Doing the polling in kernel is more efficient, and
makes stuff just work out of the box. You can assign the keys using
standard X keymaps, or using tools such as gnome-keybinding-properties.

Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
 Documentation/kernel-parameters.txt |   11 +
 drivers/acpi/Kconfig|1 
 drivers/acpi/toshiba_acpi.c |  333 
 3 files changed, 278 insertions(+), 67 deletions(-)

Index: linux/drivers/acpi/Kconfig
===
--- linux.orig/drivers/acpi/Kconfig
+++ linux/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
depends on X86
select BACKLIGHT_CLASS_DEVICE
+   select INPUT_POLLDEV
---help---
  This driver adds support for access to certain system settings
  on "legacy free" Toshiba laptops.  These laptops can be recognized by
Index: linux/drivers/acpi/toshiba_acpi.c
===
--- linux.orig/drivers/acpi/toshiba_acpi.c
+++ linux/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  * engineering the Windows drivers
  * Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
  * Rob Miller - TV out and hotkeys help
- *
+ * Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION   "0.18"
+#define TOSHIBA_ACPI_VERSION   "0.19"
 #define PROC_INTERFACE_VERSION 1
 
 #include 
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -55,6 +56,7 @@ MODULE_LICENSE("GPL");
 #define MY_ERR KERN_ERR MY_LOGPREFIX
 #define MY_NOTICE KERN_NOTICE MY_LOGPREFIX
 #define MY_INFO KERN_INFO MY_LOGPREFIX
+#define MY_DEBUG KERN_DEBUG MY_LOGPREFIX
 
 /* Toshiba ACPI method paths */
 #define METHOD_LCD_BRIGHTNESS  "\\_SB_.PCI0.VGA_.LCD_._BCM"
@@ -99,6 +101,17 @@ MODULE_LICENSE("GPL");
 #define HCI_VIDEO_OUT_CRT  0x2
 #define HCI_VIDEO_OUT_TV   0x4
 
+/* key definitions */
+#define HCI_HKEY_FN0x0100
+#define HCI_HKEY_MUTE  0x0101
+#define HCI_HKEY_BREAK 0x013b
+#define HCI_HKEY_SEARCH0x013c
+#define HCI_HKEY_SUSPEND   0x013d
+#define HCI_HKEY_HIBERNATE 0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN0x0140
+#define HCI_HKEY_BRIGHTNESSUP  0x0141
+#define HCI_HKEY_WLAN  0x0142
+
 /* utility
  */
 
@@ -213,10 +226,21 @@ static acpi_status hci_read1(u32 reg, u3
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
 
+static int hotkeys_over_input = 1;
+module_param(hotkeys_over_input, bool, 0444);
+MODULE_PARM_DESC(hotkeys_over_input,
+   "Enable delivery of hotkey events via input layer.");
+
+static int hotkeys_poll_interval = 500;/* msecs */
+module_param(hotkeys_poll_interval, uint, 0444);
+MODULE_PARM_DESC(hotkeys_poll_interval,
+   "How often to poll hotkey state (default is 500 msec)");
+
 typedef struct _ProcItem {
const char *name;
char *(*read_func) (char *);
@@ -438,32 +462,47 @@ static unsigned long write_fan(const cha
return count;
 }
 
+static u32 hci_poll_keys_once(u32 *value)
+{
+   u32 hci_result;
+
+   hci_read1(HCI_SYSTEM_EVENT, value, _result);
+   if (hci_result == HCI_NOT_SUPPORTED) {
+   /* This is a workaround for 

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Fri, 2007-06-08 at 10:23 -0400, Dmitry Torokhov wrote:
 On 6/7/07, Richard Hughes [EMAIL PROTECTED] wrote:
  On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
  
  
   It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
   Lock/Screensaver
   so your interpretation is indeed correct. I guess I better add an
   alias to
   input.h
 
  What's the status of this patch? Good for merging?
 
 Not my call - John is the official maintainer of the driver. However
 from input layer POV it looks good.

Good, thanks.

  Do you want me to
  redo the current patch using input-polldev
 
 The patch I send to you earlier already does this. I am attaching a
 refreshed version that used KEY_COFFEE instead of KEY_BREAK.

Brilliant, these look great.

  and the new setkeycode stuff?
 
 And I have the patch doing this as well (attached). If you could
 please give it a try I'd appreciate it.

You beat me to it {hastily removes item from TODO...} :-)

I'll give it a try as soon as possible, thanks.

Richard.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Dmitry Torokhov]

On 6/7/07, Richard Hughes [EMAIL PROTECTED] wrote:

On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:


 It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
 Lock/Screensaver
 so your interpretation is indeed correct. I guess I better add an
 alias to
 input.h

What's the status of this patch? Good for merging?


Not my call - John is the official maintainer of the driver. However
from input layer POV it looks good.


Do you want me to
redo the current patch using input-polldev


The patch I send to you earlier already does this. I am attaching a
refreshed version that used KEY_COFFEE instead of KEY_BREAK.


and the new setkeycode stuff?


And I have the patch doing this as well (attached). If you could
please give it a try I'd appreciate it.

--
Dmitry
From: Richard Hughes [EMAIL PROTECTED]
Subject: toshiba_acpi: integrate with INPUT layer

Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events now matched to a list of toshiba specific
scancodes, and are squirted to userspace using the INPUT subsystem.

This means that toshiba laptops buttons just work without any
userspace daemon (using uinput) such as fnfx or bodges such as using a
userspace hal addon. Doing the polling in kernel is more efficient, and
makes stuff just work out of the box. You can assign the keys using
standard X keymaps, or using tools such as gnome-keybinding-properties.

Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
 Documentation/kernel-parameters.txt |   11 +
 drivers/acpi/Kconfig|1 
 drivers/acpi/toshiba_acpi.c |  333 
 3 files changed, 278 insertions(+), 67 deletions(-)

Index: linux/drivers/acpi/Kconfig
===
--- linux.orig/drivers/acpi/Kconfig
+++ linux/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
tristate Toshiba Laptop Extras
depends on X86
select BACKLIGHT_CLASS_DEVICE
+   select INPUT_POLLDEV
---help---
  This driver adds support for access to certain system settings
  on legacy free Toshiba laptops.  These laptops can be recognized by
Index: linux/drivers/acpi/toshiba_acpi.c
===
--- linux.orig/drivers/acpi/toshiba_acpi.c
+++ linux/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  * engineering the Windows drivers
  * Yasushi Nagato - changes for linux kernel 2.4 - 2.5
  * Rob Miller - TV out and hotkeys help
- *
+ * Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION   0.18
+#define TOSHIBA_ACPI_VERSION   0.19
 #define PROC_INTERFACE_VERSION 1
 
 #include linux/kernel.h
@@ -42,6 +42,7 @@
 #include linux/types.h
 #include linux/proc_fs.h
 #include linux/backlight.h
+#include linux/input-polldev.h
 
 #include asm/uaccess.h
 
@@ -55,6 +56,7 @@ MODULE_LICENSE(GPL);
 #define MY_ERR KERN_ERR MY_LOGPREFIX
 #define MY_NOTICE KERN_NOTICE MY_LOGPREFIX
 #define MY_INFO KERN_INFO MY_LOGPREFIX
+#define MY_DEBUG KERN_DEBUG MY_LOGPREFIX
 
 /* Toshiba ACPI method paths */
 #define METHOD_LCD_BRIGHTNESS  \\_SB_.PCI0.VGA_.LCD_._BCM
@@ -99,6 +101,17 @@ MODULE_LICENSE(GPL);
 #define HCI_VIDEO_OUT_CRT  0x2
 #define HCI_VIDEO_OUT_TV   0x4
 
+/* key definitions */
+#define HCI_HKEY_FN0x0100
+#define HCI_HKEY_MUTE  0x0101
+#define HCI_HKEY_BREAK 0x013b
+#define HCI_HKEY_SEARCH0x013c
+#define HCI_HKEY_SUSPEND   0x013d
+#define HCI_HKEY_HIBERNATE 0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN0x0140
+#define HCI_HKEY_BRIGHTNESSUP  0x0141
+#define HCI_HKEY_WLAN  0x0142
+
 /* utility
  */
 
@@ -213,10 +226,21 @@ static acpi_status hci_read1(u32 reg, u3
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
 
+static int hotkeys_over_input = 1;
+module_param(hotkeys_over_input, bool, 0444);
+MODULE_PARM_DESC(hotkeys_over_input,
+   Enable delivery of hotkey events via input layer.);
+
+static int hotkeys_poll_interval = 500;/* msecs */
+module_param(hotkeys_poll_interval, uint, 0444);
+MODULE_PARM_DESC(hotkeys_poll_interval,
+   How often to poll hotkey state (default is 500 msec));
+
 typedef struct _ProcItem {
const char *name;
char *(*read_func) (char *);
@@ -438,32 +462,47 @@ static unsigned long write_fan(const cha
return count;
 }
 
+static u32 hci_poll_keys_once(u32 *value)
+{
+   u32 hci_result;
+
+   hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+   if (hci_result == 

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
> 
> 
> It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
> Lock/Screensaver
> so your interpretation is indeed correct. I guess I better add an
> alias to
> input.h

What's the status of this patch? Good for merging? Do you want me to
redo the current patch using input-polldev and the new setkeycode stuff?

Richard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Sun, 2007-06-03 at 00:48 -0400, Dmitry Torokhov wrote:
 
 
 It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal
 Lock/Screensaver
 so your interpretation is indeed correct. I guess I better add an
 alias to
 input.h

What's the status of this patch? Good for merging? Do you want me to
redo the current patch using input-polldev and the new setkeycode stuff?

Richard.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Dmitry Torokhov]

On Saturday 02 June 2007 10:23, Matthew Garrett wrote:
> On Sat, Jun 02, 2007 at 01:50:52PM +0100, Richard Hughes wrote:
> > > KEY_SCREENLOCK? KEY_SCREENSAVER?
> > 
> > Either of these keys would be good to add.
> 
> We've been interpreting "KEY_COFFEE" as screenlock (as in "I've gone for 
> a coffee break, lock the screen").
> 

It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal Lock/Screensaver
so your interpretation is indeed correct. I guess I better add an alias to
input.h

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Matthew Garrett]

On Sat, Jun 02, 2007 at 01:50:52PM +0100, Richard Hughes wrote:
> > KEY_SCREENLOCK? KEY_SCREENSAVER?
> 
> Either of these keys would be good to add.

We've been interpreting "KEY_COFFEE" as screenlock (as in "I've gone for 
a coffee break, lock the screen").

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Fri, 2007-06-01 at 12:45 -0400, Dmitry Torokhov wrote:
> The patch was pretty good, I did not quite like the driver
> registration code so I tried to clean it up.

Cool, cheers.

> What do you think about
> the attached patch (not tested due to the lack of hardware). If you
> are OK with it please add your signed-off-by because version of the
> patch I grabbed did not have it.

Attached patch looks good - I can't test it until next week, but looks
logically correct to me. I would also like to add the oddball proc event
notification system to the removal-schedule document, but this can be a
fight for another day.

> > > Also I don't think you want to use
> > > KEY_BREAK. What is the expected function of that key?

To lock the screen. We probably want to replace HCI_HKEY_BREAK with
HCI_HKEY_LOCK, as the picture on the keys is a little padlock.

> > It's a "lock" key, I really want KEY_LOCK added to input.h, but that
> > might prove difficult. For now I've used KEY_CLEAR, yell if you think
> > there's a better one to substitute or if you guys want me to add get a
> > constant added to input.h.
> 
> Iam still struggling with the purpose of the key. What would you
> extect to happen when youser presses this key? Screen gets locked?
> KEY_SCREENLOCK? KEY_SCREENSAVER?

Either of these keys would be good to add.

So yes, patch looks good, cheers for the improvements.

Signed-off-by: Richard Hughes <[EMAIL PROTECTED]>

Thanks again,

Richard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Fri, 2007-06-01 at 12:45 -0400, Dmitry Torokhov wrote:
 The patch was pretty good, I did not quite like the driver
 registration code so I tried to clean it up.

Cool, cheers.

 What do you think about
 the attached patch (not tested due to the lack of hardware). If you
 are OK with it please add your signed-off-by because version of the
 patch I grabbed did not have it.

Attached patch looks good - I can't test it until next week, but looks
logically correct to me. I would also like to add the oddball proc event
notification system to the removal-schedule document, but this can be a
fight for another day.

   Also I don't think you want to use
   KEY_BREAK. What is the expected function of that key?

To lock the screen. We probably want to replace HCI_HKEY_BREAK with
HCI_HKEY_LOCK, as the picture on the keys is a little padlock.

  It's a lock key, I really want KEY_LOCK added to input.h, but that
  might prove difficult. For now I've used KEY_CLEAR, yell if you think
  there's a better one to substitute or if you guys want me to add get a
  constant added to input.h.
 
 Iam still struggling with the purpose of the key. What would you
 extect to happen when youser presses this key? Screen gets locked?
 KEY_SCREENLOCK? KEY_SCREENSAVER?

Either of these keys would be good to add.

So yes, patch looks good, cheers for the improvements.

Signed-off-by: Richard Hughes [EMAIL PROTECTED]

Thanks again,

Richard.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Matthew Garrett]

On Sat, Jun 02, 2007 at 01:50:52PM +0100, Richard Hughes wrote:
  KEY_SCREENLOCK? KEY_SCREENSAVER?
 
 Either of these keys would be good to add.

We've been interpreting KEY_COFFEE as screenlock (as in I've gone for 
a coffee break, lock the screen).

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Dmitry Torokhov]

On Saturday 02 June 2007 10:23, Matthew Garrett wrote:
 On Sat, Jun 02, 2007 at 01:50:52PM +0100, Richard Hughes wrote:
   KEY_SCREENLOCK? KEY_SCREENSAVER?
  
  Either of these keys would be good to add.
 
 We've been interpreting KEY_COFFEE as screenlock (as in I've gone for 
 a coffee break, lock the screen).
 

It looks like KEY_COFFE comes from 0x0c/0x19e - AL Terminal Lock/Screensaver
so your interpretation is indeed correct. I guess I better add an alias to
input.h

-- 
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Dmitry Torokhov]

Hi Richard,

On 5/31/07, Richard Hughes <[EMAIL PROTECTED]> wrote:

On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
> Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
> toshiba supplied daemon that polls, so I think we have to just bite the
> bullet.

... adding in reply in different thread...

On Thu, 2007-05-31 at 10:37 -0400, Dmitry Torokhov wrote:
> Please use input-polldev to set up polled devices. It
> will create work queue for you and will make sure that polling is
> stopped when device is closed.

Okay, I had never heard of this. I've done the suggested changes in the
attached patch. Please can you have a look and make sure I'm being sane.



The patch was pretty good, I did not quite like the driver
registration code so I tried to clean it up. What do you think about
the attached patch (not tested due to the lack of hardware). If you
are OK with it please add your signed-off-by because version of the
patch I grabbed did not have it.


> Also I don't think you want to use
> KEY_BREAK. What is the expected function of that key?

It's a "lock" key, I really want KEY_LOCK added to input.h, but that
might prove difficult. For now I've used KEY_CLEAR, yell if you think
there's a better one to substitute or if you guys want me to add get a
constant added to input.h.


Iam still struggling with the purpose of the key. What would you
extect to happen when youser presses this key? Screen gets locked?
KEY_SCREENLOCK? KEY_SCREENSAVER?

--
Dmitry
From: Richard Hughes <[EMAIL PROTECTED]>
Subject: toshiba_acpi: integrate with INPUT layer

Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events now matched to a list of toshiba specific
scancodes, and are squirted to userspace using the INPUT subsystem.

This means that toshiba laptops buttons "just work" without any
userspace daemon (using uinput) such as fnfx or bodges such as using a
userspace hal addon. Doing the polling in kernel is more efficient, and
makes stuff just work out of the box. You can assign the keys using
standard X keymaps, or using tools such as gnome-keybinding-properties.

Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
 Documentation/kernel-parameters.txt |   11 +
 drivers/acpi/Kconfig|1 
 drivers/acpi/toshiba_acpi.c |  333 
 3 files changed, 278 insertions(+), 67 deletions(-)

Index: linux/drivers/acpi/Kconfig
===
--- linux.orig/drivers/acpi/Kconfig
+++ linux/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
depends on X86
select BACKLIGHT_CLASS_DEVICE
+   select INPUT_POLLDEV
---help---
  This driver adds support for access to certain system settings
  on "legacy free" Toshiba laptops.  These laptops can be recognized by
Index: linux/drivers/acpi/toshiba_acpi.c
===
--- linux.orig/drivers/acpi/toshiba_acpi.c
+++ linux/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  * engineering the Windows drivers
  * Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
  * Rob Miller - TV out and hotkeys help
- *
+ * Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION   "0.18"
+#define TOSHIBA_ACPI_VERSION   "0.19"
 #define PROC_INTERFACE_VERSION 1
 
 #include 
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -55,6 +56,7 @@ MODULE_LICENSE("GPL");
 #define MY_ERR KERN_ERR MY_LOGPREFIX
 #define MY_NOTICE KERN_NOTICE MY_LOGPREFIX
 #define MY_INFO KERN_INFO MY_LOGPREFIX
+#define MY_DEBUG KERN_DEBUG MY_LOGPREFIX
 
 /* Toshiba ACPI method paths */
 #define METHOD_LCD_BRIGHTNESS  "\\_SB_.PCI0.VGA_.LCD_._BCM"
@@ -99,6 +101,17 @@ MODULE_LICENSE("GPL");
 #define HCI_VIDEO_OUT_CRT  0x2
 #define HCI_VIDEO_OUT_TV   0x4
 
+/* key definitions */
+#define HCI_HKEY_FN0x0100
+#define HCI_HKEY_MUTE  0x0101
+#define HCI_HKEY_BREAK 0x013b
+#define HCI_HKEY_SEARCH0x013c
+#define HCI_HKEY_SUSPEND   0x013d
+#define HCI_HKEY_HIBERNATE 0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN0x0140
+#define HCI_HKEY_BRIGHTNESSUP  0x0141
+#define HCI_HKEY_WLAN  0x0142
+
 /* utility
  */
 
@@ -213,10 +226,21 @@ static acpi_status hci_read1(u32 reg, u3
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
 
+static int hotkeys_over_input = 1;
+module_param(hotkeys_over_input, bool, 0444);

Re: Add INPUT support to toshiba_acpi

[Dmitry Torokhov]

Hi Richard,

On 5/31/07, Richard Hughes [EMAIL PROTECTED] wrote:

On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
 Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
 toshiba supplied daemon that polls, so I think we have to just bite the
 bullet.

... adding in reply in different thread...

On Thu, 2007-05-31 at 10:37 -0400, Dmitry Torokhov wrote:
 Please use input-polldev to set up polled devices. It
 will create work queue for you and will make sure that polling is
 stopped when device is closed.

Okay, I had never heard of this. I've done the suggested changes in the
attached patch. Please can you have a look and make sure I'm being sane.



The patch was pretty good, I did not quite like the driver
registration code so I tried to clean it up. What do you think about
the attached patch (not tested due to the lack of hardware). If you
are OK with it please add your signed-off-by because version of the
patch I grabbed did not have it.


 Also I don't think you want to use
 KEY_BREAK. What is the expected function of that key?

It's a lock key, I really want KEY_LOCK added to input.h, but that
might prove difficult. For now I've used KEY_CLEAR, yell if you think
there's a better one to substitute or if you guys want me to add get a
constant added to input.h.


Iam still struggling with the purpose of the key. What would you
extect to happen when youser presses this key? Screen gets locked?
KEY_SCREENLOCK? KEY_SCREENSAVER?

--
Dmitry
From: Richard Hughes [EMAIL PROTECTED]
Subject: toshiba_acpi: integrate with INPUT layer

Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events now matched to a list of toshiba specific
scancodes, and are squirted to userspace using the INPUT subsystem.

This means that toshiba laptops buttons just work without any
userspace daemon (using uinput) such as fnfx or bodges such as using a
userspace hal addon. Doing the polling in kernel is more efficient, and
makes stuff just work out of the box. You can assign the keys using
standard X keymaps, or using tools such as gnome-keybinding-properties.

Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
 Documentation/kernel-parameters.txt |   11 +
 drivers/acpi/Kconfig|1 
 drivers/acpi/toshiba_acpi.c |  333 
 3 files changed, 278 insertions(+), 67 deletions(-)

Index: linux/drivers/acpi/Kconfig
===
--- linux.orig/drivers/acpi/Kconfig
+++ linux/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
tristate Toshiba Laptop Extras
depends on X86
select BACKLIGHT_CLASS_DEVICE
+   select INPUT_POLLDEV
---help---
  This driver adds support for access to certain system settings
  on legacy free Toshiba laptops.  These laptops can be recognized by
Index: linux/drivers/acpi/toshiba_acpi.c
===
--- linux.orig/drivers/acpi/toshiba_acpi.c
+++ linux/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  * engineering the Windows drivers
  * Yasushi Nagato - changes for linux kernel 2.4 - 2.5
  * Rob Miller - TV out and hotkeys help
- *
+ * Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION   0.18
+#define TOSHIBA_ACPI_VERSION   0.19
 #define PROC_INTERFACE_VERSION 1
 
 #include linux/kernel.h
@@ -42,6 +42,7 @@
 #include linux/types.h
 #include linux/proc_fs.h
 #include linux/backlight.h
+#include linux/input-polldev.h
 
 #include asm/uaccess.h
 
@@ -55,6 +56,7 @@ MODULE_LICENSE(GPL);
 #define MY_ERR KERN_ERR MY_LOGPREFIX
 #define MY_NOTICE KERN_NOTICE MY_LOGPREFIX
 #define MY_INFO KERN_INFO MY_LOGPREFIX
+#define MY_DEBUG KERN_DEBUG MY_LOGPREFIX
 
 /* Toshiba ACPI method paths */
 #define METHOD_LCD_BRIGHTNESS  \\_SB_.PCI0.VGA_.LCD_._BCM
@@ -99,6 +101,17 @@ MODULE_LICENSE(GPL);
 #define HCI_VIDEO_OUT_CRT  0x2
 #define HCI_VIDEO_OUT_TV   0x4
 
+/* key definitions */
+#define HCI_HKEY_FN0x0100
+#define HCI_HKEY_MUTE  0x0101
+#define HCI_HKEY_BREAK 0x013b
+#define HCI_HKEY_SEARCH0x013c
+#define HCI_HKEY_SUSPEND   0x013d
+#define HCI_HKEY_HIBERNATE 0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN0x0140
+#define HCI_HKEY_BRIGHTNESSUP  0x0141
+#define HCI_HKEY_WLAN  0x0142
+
 /* utility
  */
 
@@ -213,10 +226,21 @@ static acpi_status hci_read1(u32 reg, u3
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
 
+static int hotkeys_over_input = 1;

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Thu, 2007-05-31 at 18:46 +0200, Andreas Mohr wrote:
> HCI_EMPTY is *by far* the most frequent state to occur I think
> (users won't press keys all the time), thus it's probably better(?)
> for branch prediction to have this placed first, right?
> Not that it matters too much instruction-wise, but still...

Sure.

> Apart from that I'm very happy to see progress on this front
> (speaking as a "proud" owner of an old Toshiba notebook requiring
> this stuff).

Good - this stuff should just work :-)

> And I'd definitely move the multiple identical "Re-enabled hotkeys" parts
> into one single non-inlined(!) function for the same reason.
> Not to mention that it's BUTT UGLY to have the *same* fat
> multi-line comment duplicated bazillion times.

Agree. New patch (untested) attached.

Thanks for review,

Richard.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 139f41f..38835b6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
 	tristate "Toshiba Laptop Extras"
 	depends on X86
 	select BACKLIGHT_CLASS_DEVICE
+	select INPUT_POLLDEV
 	---help---
 	  This driver adds support for access to certain system settings
 	  on "legacy free" Toshiba laptops.  These laptops can be recognized by
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..f802609 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.18"
+#define TOSHIBA_ACPI_VERSION	"0.19"
 #define PROC_INTERFACE_VERSION	1
 
 #include 
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -99,6 +100,16 @@ MODULE_LICENSE("GPL");
 #define HCI_VIDEO_OUT_CRT		0x2
 #define HCI_VIDEO_OUT_TV		0x4
 
+/* key definitions */
+#define HCI_HKEY_MUTE			0x0101
+#define HCI_HKEY_LOCK			0x013b
+#define HCI_HKEY_SEARCH			0x013c
+#define HCI_HKEY_SUSPEND		0x013d
+#define HCI_HKEY_HIBERNATE		0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN		0x0140
+#define HCI_HKEY_BRIGHTNESSUP		0x0141
+#define HCI_HKEY_WLAN			0x0142
+
 /* utility
  */
 
@@ -213,9 +224,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -438,34 +455,60 @@ static unsigned long write_fan(const char *buffer, unsigned long count)
 	return count;
 }
 
-static char *read_keys(char *p)
+/* returns zero if hci event is invalid */
+static u32 get_hci_system_event_value(void)
 {
 	u32 hci_result;
 	u32 value;
+	u32 retval = 0;
+
+	/* read a system event from the queue */
+	hci_read1(HCI_SYSTEM_EVENT, , _result);
+
+	switch (hci_result) {
+	case HCI_EMPTY:
+		/* better luck next time */
+		break;
+	case HCI_SUCCESS:
+		/* value is the data in the queue */
+		retval = value;
+		break;
+	case HCI_NOT_SUPPORTED:
+		/* This is a workaround for an unresolved issue on
+		 * some machines where system events sporadically
+		 * become disabled. */
+		hci_write1(HCI_SYSTEM_EVENT, 1, _result);
+		printk(MY_NOTICE "Re-enabled hotkeys\n");
+		break;
+	default:
+		/* there was an unknown error */
+		printk(MY_ERR "Error reading hotkey status\n");
+	}
+	return retval;
+}
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, , _result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, _result);
-			printk(MY_NOTICE "Re-enabled hotkeys\n");
-		} else {
-			printk(MY_ERR "Error reading hotkey status\n");
-			goto end;
+/* deprecate this interface... */
+static char *read_keys(char *p)
+{
+	u32 value;
+
+	if (hotkeys_over_input) {
+		key_event_valid = 0;
+		last_key_event = 0;
+	} else {
+		if (!key_event_valid) {
+			value = get_hci_system_event_value();
+			if (value != 0) {
+key_event_valid = 1;
+last_key_event = value;
+			}
 		}
 	}
 
 	p += sprintf(p, "hotkey_ready:%d\n", key_event_valid);
 	p += sprintf(p, "hotkey:  0x%04x\n", last_key_event);
+	p += sprintf(p, "hotkeys_via_input:   %d\n", hotkeys_over_input);
 
-  end:
 	return p;
 }
 
@@ -534,15 +577,103 @@ static acpi_status 

Re: Add INPUT support to toshiba_acpi

[Andreas Mohr]

Hi,

On Thu, May 31, 2007 at 04:46:56PM +0100, Richard Hughes wrote:

+   if (!hotkeys_over_input) {
+   if (!key_event_valid) {
+   hci_read1(HCI_SYSTEM_EVENT, , _result);
+   if (hci_result == HCI_SUCCESS) {
+   key_event_valid = 1;
+   last_key_event = value;
+   } else if (hci_result == HCI_EMPTY) {
+   /* better luck next time */

HCI_EMPTY is *by far* the most frequent state to occur I think
(users won't press keys all the time), thus it's probably better(?)
for branch prediction to have this placed first, right?
Not that it matters too much instruction-wise, but still...

Apart from that I'm very happy to see progress on this front
(speaking as a "proud" owner of an old Toshiba notebook requiring
this stuff).

Oh, and maybe merge the sprintf()s into a single one to reduce code size.

And I'd definitely move the multiple identical "Re-enabled hotkeys" parts
into one single non-inlined(!) function for the same reason.
Not to mention that it's BUTT UGLY to have the *same* fat
multi-line comment duplicated bazillion times.

Thanks a lot!

Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
> Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
> toshiba supplied daemon that polls, so I think we have to just bite the
> bullet.

... adding in reply in different thread...

On Thu, 2007-05-31 at 10:37 -0400, Dmitry Torokhov wrote:
> Please use input-polldev to set up polled devices. It
> will create work queue for you and will make sure that polling is
> stopped when device is closed. 

Okay, I had never heard of this. I've done the suggested changes in the
attached patch. Please can you have a look and make sure I'm being sane.

> Also I don't think you want to use
> KEY_BREAK. What is the expected function of that key?

It's a "lock" key, I really want KEY_LOCK added to input.h, but that
might prove difficult. For now I've used KEY_CLEAR, yell if you think
there's a better one to substitute or if you guys want me to add get a
constant added to input.h.

Thanks for the review.

Richard.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 139f41f..38835b6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
 	tristate "Toshiba Laptop Extras"
 	depends on X86
 	select BACKLIGHT_CLASS_DEVICE
+	select INPUT_POLLDEV
 	---help---
 	  This driver adds support for access to certain system settings
 	  on "legacy free" Toshiba laptops.  These laptops can be recognized by
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..2b1a3d9 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.18"
+#define TOSHIBA_ACPI_VERSION	"0.19"
 #define PROC_INTERFACE_VERSION	1
 
 #include 
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -99,6 +100,16 @@ MODULE_LICENSE("GPL");
 #define HCI_VIDEO_OUT_CRT		0x2
 #define HCI_VIDEO_OUT_TV		0x4
 
+/* key definitions */
+#define HCI_HKEY_MUTE			0x0101
+#define HCI_HKEY_BREAK			0x013b
+#define HCI_HKEY_SEARCH			0x013c
+#define HCI_HKEY_SUSPEND		0x013d
+#define HCI_HKEY_HIBERNATE		0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN		0x0140
+#define HCI_HKEY_BRIGHTNESSUP		0x0141
+#define HCI_HKEY_WLAN			0x0142
+
 /* utility
  */
 
@@ -213,9 +224,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -443,27 +460,33 @@ static char *read_keys(char *p)
 	u32 hci_result;
 	u32 value;
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, , _result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, _result);
-			printk(MY_NOTICE "Re-enabled hotkeys\n");
-		} else {
-			printk(MY_ERR "Error reading hotkey status\n");
-			goto end;
+	if (!hotkeys_over_input) {
+		if (!key_event_valid) {
+			hci_read1(HCI_SYSTEM_EVENT, , _result);
+			if (hci_result == HCI_SUCCESS) {
+key_event_valid = 1;
+last_key_event = value;
+			} else if (hci_result == HCI_EMPTY) {
+/* better luck next time */
+			} else if (hci_result == HCI_NOT_SUPPORTED) {
+/* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+hci_write1(HCI_SYSTEM_EVENT, 1, _result);
+printk(MY_NOTICE "Re-enabled hotkeys\n");
+			} else {
+printk(MY_ERR "Error reading hotkey status\n");
+goto end;
+			}
 		}
+	} else {
+		key_event_valid = 0;
+		last_key_event = 0;
 	}
 
 	p += sprintf(p, "hotkey_ready:%d\n", key_event_valid);
 	p += sprintf(p, "hotkey:  0x%04x\n", last_key_event);
+	p += sprintf(p, "hotkeys_via_input:   %d\n", hotkeys_over_input);
 
   end:
 	return p;
@@ -534,15 +557,127 @@ static acpi_status __exit remove_device(void)
 }
 
 static struct backlight_ops toshiba_backlight_data = {
-.get_brightness = get_lcd,
-.update_status  = set_lcd_status,
+	.get_brightness = get_lcd,
+	.update_status  = set_lcd_status,
 };
 
+static void toshiba_deliver_button_event(struct input_dev *input, u32 

Re: Add INPUT support to toshiba_acpi

[Bastien Nocera]

On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
> Attached patch adds a kernel thread to do polling on Toshiba hardware.
> 
> Toshiba hardware is a little oddball, and does not provide ACPI events
> on some key presses, typically Fn hotkey buttons. The key interface is
> now polled, and events now matched to a list of toshiba specific
> scancodes, and are squirted to userspace using the INPUT subsystem.
> 
> This means that toshiba laptops buttons "just work" without any
> userspace daemon (using uinput) such as fnfx or bodges such as using a
> userspace hal addon. Doing the polling in kernel is more efficient, and
> makes stuff just work out of the box. You can assign the keys using
> standard X keymaps, or using tools such as gnome-keybinding-properties.
> 
> This is similar to other patches sent for the thinkpad_acpi driver, and
> is part of the "Unf*ck my keyboard" initiative to make multimedia keys
> just work.
> 
> Changes from the first patch involve switching to a workqueue for the
> polling, not breaking the spaces in "hotkeys_via_input" and also masking
> out the fn key button up.

A couple of things:
- use a switch statement in toshiba_deliver_button_event(), would look a
bit cleaner.
- make the magic number #defines
- not sure if it's possible, but you should disable the workqueue
altogether if nothing has the input device opened.

Hopefully we'll find a way to receive an interrupt, or some kind of
event when the keys are pressed in the future, and completely avoid the
polling. In the meantime, it should be minimised.

Cheers

-- 
Bastien Nocera <[EMAIL PROTECTED]> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Thu, 2007-05-31 at 13:53 +0100, Bastien Nocera wrote:
> On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
> > Attached patch adds a kernel thread to do polling on Toshiba hardware.
> > 
> > Toshiba hardware is a little oddball, and does not provide ACPI events
> > on some key presses, typically Fn hotkey buttons. The key interface is
> > now polled, and events now matched to a list of toshiba specific
> > scancodes, and are squirted to userspace using the INPUT subsystem.
> > 
> > This means that toshiba laptops buttons "just work" without any
> > userspace daemon (using uinput) such as fnfx or bodges such as using a
> > userspace hal addon. Doing the polling in kernel is more efficient, and
> > makes stuff just work out of the box. You can assign the keys using
> > standard X keymaps, or using tools such as gnome-keybinding-properties.
> > 
> > This is similar to other patches sent for the thinkpad_acpi driver, and
> > is part of the "Unf*ck my keyboard" initiative to make multimedia keys
> > just work.
> > 
> > Changes from the first patch involve switching to a workqueue for the
> > polling, not breaking the spaces in "hotkeys_via_input" and also masking
> > out the fn key button up.
> 
> A couple of things:
> - use a switch statement in toshiba_deliver_button_event(), would look a
> bit cleaner.

Agree, done.

> - make the magic number #defines

Agree, done.

> - not sure if it's possible, but you should disable the workqueue
> altogether if nothing has the input device opened.

Do we get an event when the [input]->users value changes? If not, we
could do 1Hz (users > 0) checking when the input device is unclaimed,
and then switch to 4Hz polling when the input device is open.

> Hopefully we'll find a way to receive an interrupt, or some kind of
> event when the keys are pressed in the future, and completely avoid the
> polling. In the meantime, it should be minimised.

Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
toshiba supplied daemon that polls, so I think we have to just bite the
bullet.

New patch attached.

Richard.

diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..cf4ab76 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events, based on a patch from Daniel Silverstone
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.18"
+#define TOSHIBA_ACPI_VERSION	"0.19"
 #define PROC_INTERFACE_VERSION	1
 
 #include 
@@ -42,6 +42,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -99,6 +101,16 @@ MODULE_LICENSE("GPL");
 #define HCI_VIDEO_OUT_CRT		0x2
 #define HCI_VIDEO_OUT_TV		0x4
 
+/* key definitions */
+#define HCI_HKEY_MUTE			0x0101
+#define HCI_HKEY_BREAK			0x013b
+#define HCI_HKEY_SEARCH			0x013c
+#define HCI_HKEY_SUSPEND		0x013d
+#define HCI_HKEY_HIBERNATE		0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN		0x0140
+#define HCI_HKEY_BRIGHTNESSUP		0x0141
+#define HCI_HKEY_WLAN			0x0142
+
 /* utility
  */
 
@@ -213,9 +225,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_dev *toshiba_input;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -443,27 +461,33 @@ static char *read_keys(char *p)
 	u32 hci_result;
 	u32 value;
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, , _result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, _result);
-			printk(MY_NOTICE "Re-enabled hotkeys\n");
-		} else {
-			printk(MY_ERR "Error reading hotkey status\n");
-			goto end;
+	if (!hotkeys_over_input) {
+		if (!key_event_valid) {
+			hci_read1(HCI_SYSTEM_EVENT, , _result);
+			if (hci_result == HCI_SUCCESS) {
+key_event_valid = 1;
+last_key_event = value;
+			} else if (hci_result == HCI_EMPTY) {
+/* better luck next time */
+			} else if (hci_result == HCI_NOT_SUPPORTED) {
+/* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+hci_write1(HCI_SYSTEM_EVENT, 1, _result);
+printk(MY_NOTICE "Re-enabled hotkeys\n");
+			} else {
+printk(MY_ERR "Error reading 

Add INPUT support to toshiba_acpi

[Richard Hughes]

Attached patch adds a kernel thread to do polling on Toshiba hardware.

Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events now matched to a list of toshiba specific
scancodes, and are squirted to userspace using the INPUT subsystem.

This means that toshiba laptops buttons "just work" without any
userspace daemon (using uinput) such as fnfx or bodges such as using a
userspace hal addon. Doing the polling in kernel is more efficient, and
makes stuff just work out of the box. You can assign the keys using
standard X keymaps, or using tools such as gnome-keybinding-properties.

This is similar to other patches sent for the thinkpad_acpi driver, and
is part of the "Unf*ck my keyboard" initiative to make multimedia keys
just work.

Changes from the first patch involve switching to a workqueue for the
polling, not breaking the spaces in "hotkeys_via_input" and also masking
out the fn key button up.

 toshiba_acpi.c |  228 +++--
 1 file changed, 206 insertions(+), 22 deletions(-)

Signed-off-by: Richard Hughes <[EMAIL PROTECTED]>

--- origin/toshiba_acpi.c	2007-05-18 09:56:03.0 +0100
+++ toshiba_acpi.c	2007-05-31 13:24:02.0 +0100
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 -> 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events, based on a patch from Daniel Silverstone
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	"0.18"
+#define TOSHIBA_ACPI_VERSION	"0.19"
 #define PROC_INTERFACE_VERSION	1
 
 #include 
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -213,9 +214,15 @@ static acpi_status hci_read1(u32 reg, u3
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_dev *toshiba_input;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -443,27 +450,33 @@ static char *read_keys(char *p)
 	u32 hci_result;
 	u32 value;
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, , _result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, _result);
-			printk(MY_NOTICE "Re-enabled hotkeys\n");
-		} else {
-			printk(MY_ERR "Error reading hotkey status\n");
-			goto end;
+	if (!hotkeys_over_input) {
+		if (!key_event_valid) {
+			hci_read1(HCI_SYSTEM_EVENT, , _result);
+			if (hci_result == HCI_SUCCESS) {
+key_event_valid = 1;
+last_key_event = value;
+			} else if (hci_result == HCI_EMPTY) {
+/* better luck next time */
+			} else if (hci_result == HCI_NOT_SUPPORTED) {
+/* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+hci_write1(HCI_SYSTEM_EVENT, 1, _result);
+printk(MY_NOTICE "Re-enabled hotkeys\n");
+			} else {
+printk(MY_ERR "Error reading hotkey status\n");
+goto end;
+			}
 		}
+	} else {
+		key_event_valid = 0;
+		last_key_event = 0;
 	}
 
 	p += sprintf(p, "hotkey_ready:%d\n", key_event_valid);
 	p += sprintf(p, "hotkey:  0x%04x\n", last_key_event);
+	p += sprintf(p, "hotkeys_via_input:   %d\n", hotkeys_over_input);
 
   end:
 	return p;
@@ -534,15 +547,121 @@ static acpi_status __exit remove_device(
 }
 
 static struct backlight_ops toshiba_backlight_data = {
-.get_brightness = get_lcd,
-.update_status  = set_lcd_status,
+	.get_brightness = get_lcd,
+	.update_status  = set_lcd_status,
 };
 
+static void toshiba_keys_fire(struct work_struct *work);
+static struct workqueue_struct *toshiba_keys_wq;
+static DECLARE_DELAYED_WORK(toshiba_keys_work, toshiba_keys_fire);
+
+static void toshiba_deliver_button_event(u32 value)
+{
+	int keycode = KEY_UNKNOWN;
+	int key_down = 1;
+
+	if (!toshiba_input)
+		return;
+
+	/* translate MSB to key up */
+	if (value & 0x80) {
+		value &= ~0x80;
+		key_down = 0;
+	}
+
+	/* ignore FN on its own */
+	if (value == 0x0100)
+		return;
+
+	/* translate keys to keycodes */
+	if (value == 0x101)
+		keycode = KEY_MUTE;
+	else if (value == 0x13b)
+		keycode = KEY_BREAK;
+	else if (value == 0x13c)
+		keycode = KEY_SEARCH;
+	else if (value == 0x13d)
+		keycode = KEY_SLEEP;
+	else if (value == 0x13e)
+		keycode = KEY_SUSPEND;
+	else if (value == 

Add INPUT support to toshiba_acpi

[Richard Hughes]

Attached patch adds a kernel thread to do polling on Toshiba hardware.

Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events now matched to a list of toshiba specific
scancodes, and are squirted to userspace using the INPUT subsystem.

This means that toshiba laptops buttons just work without any
userspace daemon (using uinput) such as fnfx or bodges such as using a
userspace hal addon. Doing the polling in kernel is more efficient, and
makes stuff just work out of the box. You can assign the keys using
standard X keymaps, or using tools such as gnome-keybinding-properties.

This is similar to other patches sent for the thinkpad_acpi driver, and
is part of the Unf*ck my keyboard initiative to make multimedia keys
just work.

Changes from the first patch involve switching to a workqueue for the
polling, not breaking the spaces in hotkeys_via_input and also masking
out the fn key button up.

 toshiba_acpi.c |  228 +++--
 1 file changed, 206 insertions(+), 22 deletions(-)

Signed-off-by: Richard Hughes [EMAIL PROTECTED]

--- origin/toshiba_acpi.c	2007-05-18 09:56:03.0 +0100
+++ toshiba_acpi.c	2007-05-31 13:24:02.0 +0100
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 - 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events, based on a patch from Daniel Silverstone
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	0.18
+#define TOSHIBA_ACPI_VERSION	0.19
 #define PROC_INTERFACE_VERSION	1
 
 #include linux/kernel.h
@@ -42,6 +42,7 @@
 #include linux/types.h
 #include linux/proc_fs.h
 #include linux/backlight.h
+#include linux/input.h
 
 #include asm/uaccess.h
 
@@ -213,9 +214,15 @@ static acpi_status hci_read1(u32 reg, u3
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_dev *toshiba_input;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -443,27 +450,33 @@ static char *read_keys(char *p)
 	u32 hci_result;
 	u32 value;
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
-			printk(MY_NOTICE Re-enabled hotkeys\n);
-		} else {
-			printk(MY_ERR Error reading hotkey status\n);
-			goto end;
+	if (!hotkeys_over_input) {
+		if (!key_event_valid) {
+			hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+			if (hci_result == HCI_SUCCESS) {
+key_event_valid = 1;
+last_key_event = value;
+			} else if (hci_result == HCI_EMPTY) {
+/* better luck next time */
+			} else if (hci_result == HCI_NOT_SUPPORTED) {
+/* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
+printk(MY_NOTICE Re-enabled hotkeys\n);
+			} else {
+printk(MY_ERR Error reading hotkey status\n);
+goto end;
+			}
 		}
+	} else {
+		key_event_valid = 0;
+		last_key_event = 0;
 	}
 
 	p += sprintf(p, hotkey_ready:%d\n, key_event_valid);
 	p += sprintf(p, hotkey:  0x%04x\n, last_key_event);
+	p += sprintf(p, hotkeys_via_input:   %d\n, hotkeys_over_input);
 
   end:
 	return p;
@@ -534,15 +547,121 @@ static acpi_status __exit remove_device(
 }
 
 static struct backlight_ops toshiba_backlight_data = {
-.get_brightness = get_lcd,
-.update_status  = set_lcd_status,
+	.get_brightness = get_lcd,
+	.update_status  = set_lcd_status,
 };
 
+static void toshiba_keys_fire(struct work_struct *work);
+static struct workqueue_struct *toshiba_keys_wq;
+static DECLARE_DELAYED_WORK(toshiba_keys_work, toshiba_keys_fire);
+
+static void toshiba_deliver_button_event(u32 value)
+{
+	int keycode = KEY_UNKNOWN;
+	int key_down = 1;
+
+	if (!toshiba_input)
+		return;
+
+	/* translate MSB to key up */
+	if (value  0x80) {
+		value = ~0x80;
+		key_down = 0;
+	}
+
+	/* ignore FN on its own */
+	if (value == 0x0100)
+		return;
+
+	/* translate keys to keycodes */
+	if (value == 0x101)
+		keycode = KEY_MUTE;
+	else if (value == 0x13b)
+		keycode = KEY_BREAK;
+	else if (value == 0x13c)
+		keycode = KEY_SEARCH;
+	else if (value == 0x13d)
+		keycode = KEY_SLEEP;

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Thu, 2007-05-31 at 13:53 +0100, Bastien Nocera wrote:
 On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
  Attached patch adds a kernel thread to do polling on Toshiba hardware.
  
  Toshiba hardware is a little oddball, and does not provide ACPI events
  on some key presses, typically Fn hotkey buttons. The key interface is
  now polled, and events now matched to a list of toshiba specific
  scancodes, and are squirted to userspace using the INPUT subsystem.
  
  This means that toshiba laptops buttons just work without any
  userspace daemon (using uinput) such as fnfx or bodges such as using a
  userspace hal addon. Doing the polling in kernel is more efficient, and
  makes stuff just work out of the box. You can assign the keys using
  standard X keymaps, or using tools such as gnome-keybinding-properties.
  
  This is similar to other patches sent for the thinkpad_acpi driver, and
  is part of the Unf*ck my keyboard initiative to make multimedia keys
  just work.
  
  Changes from the first patch involve switching to a workqueue for the
  polling, not breaking the spaces in hotkeys_via_input and also masking
  out the fn key button up.
 
 A couple of things:
 - use a switch statement in toshiba_deliver_button_event(), would look a
 bit cleaner.

Agree, done.

 - make the magic number #defines

Agree, done.

 - not sure if it's possible, but you should disable the workqueue
 altogether if nothing has the input device opened.

Do we get an event when the [input]-users value changes? If not, we
could do 1Hz (users  0) checking when the input device is unclaimed,
and then switch to 4Hz polling when the input device is open.

 Hopefully we'll find a way to receive an interrupt, or some kind of
 event when the keys are pressed in the future, and completely avoid the
 polling. In the meantime, it should be minimised.

Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
toshiba supplied daemon that polls, so I think we have to just bite the
bullet.

New patch attached.

Richard.

diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..cf4ab76 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 - 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events, based on a patch from Daniel Silverstone
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	0.18
+#define TOSHIBA_ACPI_VERSION	0.19
 #define PROC_INTERFACE_VERSION	1
 
 #include linux/kernel.h
@@ -42,6 +42,8 @@
 #include linux/types.h
 #include linux/proc_fs.h
 #include linux/backlight.h
+#include linux/input.h
+#include linux/workqueue.h
 
 #include asm/uaccess.h
 
@@ -99,6 +101,16 @@ MODULE_LICENSE(GPL);
 #define HCI_VIDEO_OUT_CRT		0x2
 #define HCI_VIDEO_OUT_TV		0x4
 
+/* key definitions */
+#define HCI_HKEY_MUTE			0x0101
+#define HCI_HKEY_BREAK			0x013b
+#define HCI_HKEY_SEARCH			0x013c
+#define HCI_HKEY_SUSPEND		0x013d
+#define HCI_HKEY_HIBERNATE		0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN		0x0140
+#define HCI_HKEY_BRIGHTNESSUP		0x0141
+#define HCI_HKEY_WLAN			0x0142
+
 /* utility
  */
 
@@ -213,9 +225,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_dev *toshiba_input;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -443,27 +461,33 @@ static char *read_keys(char *p)
 	u32 hci_result;
 	u32 value;
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
-			printk(MY_NOTICE Re-enabled hotkeys\n);
-		} else {
-			printk(MY_ERR Error reading hotkey status\n);
-			goto end;
+	if (!hotkeys_over_input) {
+		if (!key_event_valid) {
+			hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+			if (hci_result == HCI_SUCCESS) {
+key_event_valid = 1;
+last_key_event = value;
+			} else if (hci_result == HCI_EMPTY) {
+/* better luck next time */
+			} else if (hci_result == HCI_NOT_SUPPORTED) {
+/* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
+printk(MY_NOTICE Re-enabled 

Re: Add INPUT support to toshiba_acpi

[Bastien Nocera]

On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
 Attached patch adds a kernel thread to do polling on Toshiba hardware.
 
 Toshiba hardware is a little oddball, and does not provide ACPI events
 on some key presses, typically Fn hotkey buttons. The key interface is
 now polled, and events now matched to a list of toshiba specific
 scancodes, and are squirted to userspace using the INPUT subsystem.
 
 This means that toshiba laptops buttons just work without any
 userspace daemon (using uinput) such as fnfx or bodges such as using a
 userspace hal addon. Doing the polling in kernel is more efficient, and
 makes stuff just work out of the box. You can assign the keys using
 standard X keymaps, or using tools such as gnome-keybinding-properties.
 
 This is similar to other patches sent for the thinkpad_acpi driver, and
 is part of the Unf*ck my keyboard initiative to make multimedia keys
 just work.
 
 Changes from the first patch involve switching to a workqueue for the
 polling, not breaking the spaces in hotkeys_via_input and also masking
 out the fn key button up.

A couple of things:
- use a switch statement in toshiba_deliver_button_event(), would look a
bit cleaner.
- make the magic number #defines
- not sure if it's possible, but you should disable the workqueue
altogether if nothing has the input device opened.

Hopefully we'll find a way to receive an interrupt, or some kind of
event when the keys are pressed in the future, and completely avoid the
polling. In the meantime, it should be minimised.

Cheers

-- 
Bastien Nocera [EMAIL PROTECTED] 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
 Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
 toshiba supplied daemon that polls, so I think we have to just bite the
 bullet.

... adding in reply in different thread...

On Thu, 2007-05-31 at 10:37 -0400, Dmitry Torokhov wrote:
 Please use input-polldev to set up polled devices. It
 will create work queue for you and will make sure that polling is
 stopped when device is closed. 

Okay, I had never heard of this. I've done the suggested changes in the
attached patch. Please can you have a look and make sure I'm being sane.

 Also I don't think you want to use
 KEY_BREAK. What is the expected function of that key?

It's a lock key, I really want KEY_LOCK added to input.h, but that
might prove difficult. For now I've used KEY_CLEAR, yell if you think
there's a better one to substitute or if you guys want me to add get a
constant added to input.h.

Thanks for the review.

Richard.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 139f41f..38835b6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
 	tristate Toshiba Laptop Extras
 	depends on X86
 	select BACKLIGHT_CLASS_DEVICE
+	select INPUT_POLLDEV
 	---help---
 	  This driver adds support for access to certain system settings
 	  on legacy free Toshiba laptops.  These laptops can be recognized by
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..2b1a3d9 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 - 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	0.18
+#define TOSHIBA_ACPI_VERSION	0.19
 #define PROC_INTERFACE_VERSION	1
 
 #include linux/kernel.h
@@ -42,6 +42,7 @@
 #include linux/types.h
 #include linux/proc_fs.h
 #include linux/backlight.h
+#include linux/input-polldev.h
 
 #include asm/uaccess.h
 
@@ -99,6 +100,16 @@ MODULE_LICENSE(GPL);
 #define HCI_VIDEO_OUT_CRT		0x2
 #define HCI_VIDEO_OUT_TV		0x4
 
+/* key definitions */
+#define HCI_HKEY_MUTE			0x0101
+#define HCI_HKEY_BREAK			0x013b
+#define HCI_HKEY_SEARCH			0x013c
+#define HCI_HKEY_SUSPEND		0x013d
+#define HCI_HKEY_HIBERNATE		0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN		0x0140
+#define HCI_HKEY_BRIGHTNESSUP		0x0141
+#define HCI_HKEY_WLAN			0x0142
+
 /* utility
  */
 
@@ -213,9 +224,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -443,27 +460,33 @@ static char *read_keys(char *p)
 	u32 hci_result;
 	u32 value;
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
-			printk(MY_NOTICE Re-enabled hotkeys\n);
-		} else {
-			printk(MY_ERR Error reading hotkey status\n);
-			goto end;
+	if (!hotkeys_over_input) {
+		if (!key_event_valid) {
+			hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+			if (hci_result == HCI_SUCCESS) {
+key_event_valid = 1;
+last_key_event = value;
+			} else if (hci_result == HCI_EMPTY) {
+/* better luck next time */
+			} else if (hci_result == HCI_NOT_SUPPORTED) {
+/* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
+printk(MY_NOTICE Re-enabled hotkeys\n);
+			} else {
+printk(MY_ERR Error reading hotkey status\n);
+goto end;
+			}
 		}
+	} else {
+		key_event_valid = 0;
+		last_key_event = 0;
 	}
 
 	p += sprintf(p, hotkey_ready:%d\n, key_event_valid);
 	p += sprintf(p, hotkey:  0x%04x\n, last_key_event);
+	p += sprintf(p, hotkeys_via_input:   %d\n, hotkeys_over_input);
 
   end:
 	return p;
@@ -534,15 +557,127 @@ static acpi_status __exit remove_device(void)
 }
 
 static struct backlight_ops toshiba_backlight_data = {
-.get_brightness = get_lcd,
-.update_status  = set_lcd_status,
+	.get_brightness = get_lcd,
+	.update_status  = set_lcd_status,
 

Re: Add INPUT support to toshiba_acpi

[Andreas Mohr]

Hi,

On Thu, May 31, 2007 at 04:46:56PM +0100, Richard Hughes wrote:

+   if (!hotkeys_over_input) {
+   if (!key_event_valid) {
+   hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+   if (hci_result == HCI_SUCCESS) {
+   key_event_valid = 1;
+   last_key_event = value;
+   } else if (hci_result == HCI_EMPTY) {
+   /* better luck next time */

HCI_EMPTY is *by far* the most frequent state to occur I think
(users won't press keys all the time), thus it's probably better(?)
for branch prediction to have this placed first, right?
Not that it matters too much instruction-wise, but still...

Apart from that I'm very happy to see progress on this front
(speaking as a proud owner of an old Toshiba notebook requiring
this stuff).

Oh, and maybe merge the sprintf()s into a single one to reduce code size.

And I'd definitely move the multiple identical Re-enabled hotkeys parts
into one single non-inlined(!) function for the same reason.
Not to mention that it's BUTT UGLY to have the *same* fat
multi-line comment duplicated bazillion times.

Thanks a lot!

Andreas Mohr
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Add INPUT support to toshiba_acpi

[Richard Hughes]

On Thu, 2007-05-31 at 18:46 +0200, Andreas Mohr wrote:
 HCI_EMPTY is *by far* the most frequent state to occur I think
 (users won't press keys all the time), thus it's probably better(?)
 for branch prediction to have this placed first, right?
 Not that it matters too much instruction-wise, but still...

Sure.

 Apart from that I'm very happy to see progress on this front
 (speaking as a proud owner of an old Toshiba notebook requiring
 this stuff).

Good - this stuff should just work :-)

 And I'd definitely move the multiple identical Re-enabled hotkeys parts
 into one single non-inlined(!) function for the same reason.
 Not to mention that it's BUTT UGLY to have the *same* fat
 multi-line comment duplicated bazillion times.

Agree. New patch (untested) attached.

Thanks for review,

Richard.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 139f41f..38835b6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -222,6 +222,7 @@ config ACPI_TOSHIBA
 	tristate Toshiba Laptop Extras
 	depends on X86
 	select BACKLIGHT_CLASS_DEVICE
+	select INPUT_POLLDEV
 	---help---
 	  This driver adds support for access to certain system settings
 	  on legacy free Toshiba laptops.  These laptops can be recognized by
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index 3906d47..f802609 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -27,13 +27,13 @@
  *		engineering the Windows drivers
  *	Yasushi Nagato - changes for linux kernel 2.4 - 2.5
  *	Rob Miller - TV out and hotkeys help
- *
+ *	Richard Hughes - emit INPUT events for hotkeys
  *
  *  TODO
  *
  */
 
-#define TOSHIBA_ACPI_VERSION	0.18
+#define TOSHIBA_ACPI_VERSION	0.19
 #define PROC_INTERFACE_VERSION	1
 
 #include linux/kernel.h
@@ -42,6 +42,7 @@
 #include linux/types.h
 #include linux/proc_fs.h
 #include linux/backlight.h
+#include linux/input-polldev.h
 
 #include asm/uaccess.h
 
@@ -99,6 +100,16 @@ MODULE_LICENSE(GPL);
 #define HCI_VIDEO_OUT_CRT		0x2
 #define HCI_VIDEO_OUT_TV		0x4
 
+/* key definitions */
+#define HCI_HKEY_MUTE			0x0101
+#define HCI_HKEY_LOCK			0x013b
+#define HCI_HKEY_SEARCH			0x013c
+#define HCI_HKEY_SUSPEND		0x013d
+#define HCI_HKEY_HIBERNATE		0x013e
+#define HCI_HKEY_BRIGHTNESSDOWN		0x0140
+#define HCI_HKEY_BRIGHTNESSUP		0x0141
+#define HCI_HKEY_WLAN			0x0142
+
 /* utility
  */
 
@@ -213,9 +224,15 @@ static acpi_status hci_read1(u32 reg, u32 * out1, u32 * result)
 
 static struct proc_dir_entry *toshiba_proc_dir /*= 0*/ ;
 static struct backlight_device *toshiba_backlight_device;
+static struct input_polled_dev *toshiba_poll_dev;
 static int force_fan;
 static int last_key_event;
 static int key_event_valid;
+static int hotkeys_over_input = 1;
+static int hotkeys_check_per_sec = 2;
+
+module_param(hotkeys_over_input, uint, 0400);
+module_param(hotkeys_check_per_sec, uint, 0400);
 
 typedef struct _ProcItem {
 	const char *name;
@@ -438,34 +455,60 @@ static unsigned long write_fan(const char *buffer, unsigned long count)
 	return count;
 }
 
-static char *read_keys(char *p)
+/* returns zero if hci event is invalid */
+static u32 get_hci_system_event_value(void)
 {
 	u32 hci_result;
 	u32 value;
+	u32 retval = 0;
+
+	/* read a system event from the queue */
+	hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+
+	switch (hci_result) {
+	case HCI_EMPTY:
+		/* better luck next time */
+		break;
+	case HCI_SUCCESS:
+		/* value is the data in the queue */
+		retval = value;
+		break;
+	case HCI_NOT_SUPPORTED:
+		/* This is a workaround for an unresolved issue on
+		 * some machines where system events sporadically
+		 * become disabled. */
+		hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
+		printk(MY_NOTICE Re-enabled hotkeys\n);
+		break;
+	default:
+		/* there was an unknown error */
+		printk(MY_ERR Error reading hotkey status\n);
+	}
+	return retval;
+}
 
-	if (!key_event_valid) {
-		hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
-		if (hci_result == HCI_SUCCESS) {
-			key_event_valid = 1;
-			last_key_event = value;
-		} else if (hci_result == HCI_EMPTY) {
-			/* better luck next time */
-		} else if (hci_result == HCI_NOT_SUPPORTED) {
-			/* This is a workaround for an unresolved issue on
-			 * some machines where system events sporadically
-			 * become disabled. */
-			hci_write1(HCI_SYSTEM_EVENT, 1, hci_result);
-			printk(MY_NOTICE Re-enabled hotkeys\n);
-		} else {
-			printk(MY_ERR Error reading hotkey status\n);
-			goto end;
+/* deprecate this interface... */
+static char *read_keys(char *p)
+{
+	u32 value;
+
+	if (hotkeys_over_input) {
+		key_event_valid = 0;
+		last_key_event = 0;
+	} else {
+		if (!key_event_valid) {
+			value = get_hci_system_event_value();
+			if (value != 0) {
+key_event_valid = 1;
+last_key_event = value;
+			}
 		}
 	}
 
 	p += sprintf(p, hotkey_ready:%d\n, key_event_valid);
 	p += sprintf(p, hotkey:  0x%04x\n, last_key_event);
+	p += sprintf(p, hotkeys_via_input:   %d\n,