Re: [PATCH 0/2] wistron_btns: More keymaps

Re: [PATCH 0/2] wistron_btns: More keymaps

[Dmitry Torokhov]

Hi Eric,

On 3/13/07, Eric Piel <Eric.Piel@tremplin-utc.net> wrote:
> Hello,
>
> As a sequel to my patch "Wistron button support for TravelMate 610" of
> last week, here is a bigger addition of keymaps for the wistron_btns.
>
> Patch 1 adds all the database of acerhk which fits this driver (about 25
> more laptops).
> Patch 2 adds a generic map that should fit most users but has the
> disadvantage of not being automatic.
>
> Dmitry, I've tried to make them against your tree. Still, if they don't
> apply cleanly, just tell me and I'll try harder!
>

I have couple of comments/requests:

1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
lid, they correspond to Accpication Control Open and Close keys from
USB HID HUT spec:

     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf

SW_LID shoudl be used to signal lid state instead.

2. I also have a concern about using KEY_SCREEN to signal toggling
display on and off. I am CCing Vojtech - he must know what the
original intent of this key code was. BTW, when user presses
corresponding button - does the display actually goes off? Maybe we
need another switch.

3. The number of keymap tables grew considerably ;) Do you think it
woudl make sense to allocate memory for keymap at device creation time
and copy selected keymap and them mark all original keymaps as
__initdata so they are discarded one module completed initialization?

Thank you.

-- 
Dmitry

Re: [PATCH 0/2] wistron_btns: More keymaps

[Éric Piel]

03/14/2007 02:54 PM, Dmitry Torokhov wrote/a écrit:
> Hi Eric,
> 
:
> I have couple of comments/requests:
> 
> 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
> lid, they correspond to Accpication Control Open and Close keys from
> USB HID HUT spec:
> 
>     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> 
> SW_LID shoudl be used to signal lid state instead.
The keycodes put in the keymap are simply the same as in acerhk, just 
because I couldn't think of better. Indeed, KEY_OPEN and KEY_CLOSE seem 
to badly fit if they might be interpreted by userland as opening or 
closing a document! That would be better to generate a SW_LID event, but 
I'm not sure how to do that, is it just about using 
input_report_switch(x, SW_LID, 0 or 1) instead of using 
input_report_key()? Probably I need to update input_dev->swbit as well. 
Do I have to anything else to generate switch events?

Sincerely, I don't think anyone is using this info (especially because 
probably the info is also passed though ACPI) so that would be fine with 
me to just not generate any event :-P Tell me if you think it worths it.


> 2. I also have a concern about using KEY_SCREEN to signal toggling
> display on and off. I am CCing Vojtech - he must know what the
> original intent of this key code was. BTW, when user presses
> corresponding button - does the display actually goes off? Maybe we
> need another switch.
Only few laptops generate an event for this key (most of the laptop 
simply switch the screen). I don't have access to any of those, so I've 
no idea if it's the userland which has to control the display or if it's 
just information for the userland. Maybe Olaf knows? I don't think it's 
possible to convert it to a switch event because it doesn't report the 
information about if screen is on or off.

On the same topic, there are some "KEY_MEDIA" generated when key to 
change display output is pressed. Is it fine for you or do have a more 
suiting keycode in mind?


> 3. The number of keymap tables grew considerably ;) Do you think it
> woudl make sense to allocate memory for keymap at device creation time
> and copy selected keymap and them mark all original keymaps as
> __initdata so they are discarded one module completed initialization?
In the patch, I've reduced the keymap structure to only take 32bits per 
key. So, in the absolute, it's not that terrible with each keymap taking 
about 40 bytes. Still, it wouldn't hurt to save space knowing that it's 
likely that the list keeps growing up. It shouldn't be hard to do as you 
propose with the __initdata.

I had thought about a different way: as the generic keymap should fit 
most of the laptop, we could save only the difference of a given laptop 
to this keymap (then behaving more like a "quirk"). This would have the 
advantage of saving space even in the source file ;-)

I'll try to tinker a bit with both approaches and see what fit best. 
Anyway, is it ok for you to merge those patches first and later I'll 
come up with a space-saver patch?

See you,
Eric

Re: [PATCH 0/2] wistron_btns: More keymaps

[Dmitry Torokhov]

On 3/14/07, Éric Piel <Eric.Piel@tremplin-utc.net> wrote:
> 03/14/2007 02:54 PM, Dmitry Torokhov wrote/a écrit:
> > Hi Eric,
> >
> :
> > I have couple of comments/requests:
> >
> > 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
> > lid, they correspond to Accpication Control Open and Close keys from
> > USB HID HUT spec:
> >
> >     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> >
> > SW_LID shoudl be used to signal lid state instead.
> The keycodes put in the keymap are simply the same as in acerhk, just
> because I couldn't think of better. Indeed, KEY_OPEN and KEY_CLOSE seem
> to badly fit if they might be interpreted by userland as opening or
> closing a document! That would be better to generate a SW_LID event, but
> I'm not sure how to do that, is it just about using
> input_report_switch(x, SW_LID, 0 or 1) instead of using
> input_report_key()?

Yes.

> Probably I need to update input_dev->swbit as well.

Yes.

> Do I have to anything else to generate switch events?

No, that should be it. Oh, you need to set SW_BIT in dev->evbit.

>
> Sincerely, I don't think anyone is using this info (especially because
> probably the info is also passed though ACPI) so that would be fine with
> me to just not generate any event :-P Tell me if you think it worths it.
>

I think it shoudl be OK to send this event even if ACPI also sends it.
Recently I changed ACPI button driver to send SW_LID events and since
siwiches have state (on/off, open/closed) applications shoudl not get
confised by getting 2 events in a row (they shoudl not interpret it as
toggle).

> > 2. I also have a concern about using KEY_SCREEN to signal toggling
> > display on and off. I am CCing Vojtech - he must know what the
> > original intent of this key code was. BTW, when user presses
> > corresponding button - does the display actually goes off? Maybe we
> > need another switch.
> Only few laptops generate an event for this key (most of the laptop
> simply switch the screen). I don't have access to any of those, so I've
> no idea if it's the userland which has to control the display or if it's
> just information for the userland. Maybe Olaf knows? I don't think it's
> possible to convert it to a switch event because it doesn't report the
> information about if screen is on or off.
>
> On the same topic, there are some "KEY_MEDIA" generated when key to
> change display output is pressed. Is it fine for you or do have a more
> suiting keycode in mind?
>

I wonder what KEY_SWITCHVIDEOMODE does on Macs... Any Mac users out there?

>
> > 3. The number of keymap tables grew considerably ;) Do you think it
> > woudl make sense to allocate memory for keymap at device creation time
> > and copy selected keymap and them mark all original keymaps as
> > __initdata so they are discarded one module completed initialization?
> In the patch, I've reduced the keymap structure to only take 32bits per
> key. So, in the absolute, it's not that terrible with each keymap taking
> about 40 bytes. Still, it wouldn't hurt to save space knowing that it's
> likely that the list keeps growing up. It shouldn't be hard to do as you
> propose with the __initdata.
>
> I had thought about a different way: as the generic keymap should fit
> most of the laptop, we could save only the difference of a given laptop
> to this keymap (then behaving more like a "quirk"). This would have the
> advantage of saving space even in the source file ;-)
>
> I'll try to tinker a bit with both approaches and see what fit best.
> Anyway, is it ok for you to merge those patches first and later I'll
> come up with a space-saver patch?
>

Yes, I will merge the fisrt 2 patches once we work out the proper
keycodes/other events.

-- 
Dmitry

Re: [PATCH 0/2] wistron_btns: More keymaps

[Vojtech Pavlik]

On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote:
> Hi Eric,
> 
> On 3/13/07, Eric Piel <Eric.Piel@tremplin-utc.net> wrote:
> >Hello,
> >
> >As a sequel to my patch "Wistron button support for TravelMate 610" of
> >last week, here is a bigger addition of keymaps for the wistron_btns.
> >
> >Patch 1 adds all the database of acerhk which fits this driver (about 25
> >more laptops).
> >Patch 2 adds a generic map that should fit most users but has the
> >disadvantage of not being automatic.
> >
> >Dmitry, I've tried to make them against your tree. Still, if they don't
> >apply cleanly, just tell me and I'll try harder!
> >
> 
> I have couple of comments/requests:
> 
> 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
> lid, they correspond to Accpication Control Open and Close keys from
> USB HID HUT spec:
> 
>     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> 
> SW_LID shoudl be used to signal lid state instead.
> 
> 2. I also have a concern about using KEY_SCREEN to signal toggling
> display on and off. I am CCing Vojtech - he must know what the
> original intent of this key code was. BTW, when user presses
> corresponding button - does the display actually goes off? Maybe we
> need another switch.

Sorry, Dmitry, I probably should have documented it back then, I don't
have the slightest idea anymore.

> 3. The number of keymap tables grew considerably ;) Do you think it
> woudl make sense to allocate memory for keymap at device creation time
> and copy selected keymap and them mark all original keymaps as
> __initdata so they are discarded one module completed initialization?
> 
> Thank you.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [PATCH 0/2] wistron_btns: More keymaps

[Dmitry Torokhov]

On 3/14/07, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote:
> > Hi Eric,
> >
> > On 3/13/07, Eric Piel <Eric.Piel@tremplin-utc.net> wrote:
> > >Hello,
> > >
> > >As a sequel to my patch "Wistron button support for TravelMate 610" of
> > >last week, here is a bigger addition of keymaps for the wistron_btns.
> > >
> > >Patch 1 adds all the database of acerhk which fits this driver (about 25
> > >more laptops).
> > >Patch 2 adds a generic map that should fit most users but has the
> > >disadvantage of not being automatic.
> > >
> > >Dmitry, I've tried to make them against your tree. Still, if they don't
> > >apply cleanly, just tell me and I'll try harder!
> > >
> >
> > I have couple of comments/requests:
> >
> > 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
> > lid, they correspond to Accpication Control Open and Close keys from
> > USB HID HUT spec:
> >
> >     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> >
> > SW_LID shoudl be used to signal lid state instead.
> >
> > 2. I also have a concern about using KEY_SCREEN to signal toggling
> > display on and off. I am CCing Vojtech - he must know what the
> > original intent of this key code was. BTW, when user presses
> > corresponding button - does the display actually goes off? Maybe we
> > need another switch.
>
> Sorry, Dmitry, I probably should have documented it back then, I don't
> have the slightest idea anymore.
>

That's what I was afraid of ;) Well, maybe we should just use it to
indicate display switch and add a comment to that effect to input.h...

-- 
Dmitry

Re: [PATCH 0/2] wistron_btns: More keymaps

[Dmitry Torokhov]

On 3/14/07, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On 3/14/07, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote:
> > > Hi Eric,
> > >
> > > On 3/13/07, Eric Piel <Eric.Piel@tremplin-utc.net> wrote:
> > > >Hello,
> > > >
> > > >As a sequel to my patch "Wistron button support for TravelMate 610" of
> > > >last week, here is a bigger addition of keymaps for the wistron_btns.
> > > >
> > > >Patch 1 adds all the database of acerhk which fits this driver (about 25
> > > >more laptops).
> > > >Patch 2 adds a generic map that should fit most users but has the
> > > >disadvantage of not being automatic.
> > > >
> > > >Dmitry, I've tried to make them against your tree. Still, if they don't
> > > >apply cleanly, just tell me and I'll try harder!
> > > >
> > >
> > > I have couple of comments/requests:
> > >
> > > 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
> > > lid, they correspond to Accpication Control Open and Close keys from
> > > USB HID HUT spec:
> > >
> > >     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> > >
> > > SW_LID shoudl be used to signal lid state instead.
> > >
> > > 2. I also have a concern about using KEY_SCREEN to signal toggling
> > > display on and off. I am CCing Vojtech - he must know what the
> > > original intent of this key code was. BTW, when user presses
> > > corresponding button - does the display actually goes off? Maybe we
> > > need another switch.
> >
> > Sorry, Dmitry, I probably should have documented it back then, I don't
> > have the slightest idea anymore.
> >
>
> That's what I was afraid of ;) Well, maybe we should just use it to
> indicate display switch and add a comment to that effect to input.h...
>

Oh, wait, DVB uses this code to request switchin full screen mode, we
better not touch it.

-- 
Dmitry

Re: [PATCH 0/2] wistron_btns: More keymaps

[Éric Piel]

03/14/2007 08:02 PM, Dmitry Torokhov wrote/a écrit:
> On 3/14/07, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>> On 3/14/07, Vojtech Pavlik <vojtech@suse.cz> wrote:
>> > On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote:
>> > > Hi Eric,
>> > >
>> > > 2. I also have a concern about using KEY_SCREEN to signal toggling
>> > > display on and off. I am CCing Vojtech - he must know what the
>> > > original intent of this key code was. BTW, when user presses
>> > > corresponding button - does the display actually goes off? Maybe we
>> > > need another switch.
>> >
>> > Sorry, Dmitry, I probably should have documented it back then, I don't
>> > have the slightest idea anymore.
>> >
>>
>> That's what I was afraid of ;) Well, maybe we should just use it to
>> indicate display switch and add a comment to that effect to input.h...
>>
> 
> Oh, wait, DVB uses this code to request switchin full screen mode, we
> better not touch it.
> 
Isn't that what is supposed to do KEY_SWITCHVIDEOMODE? Humm... I've got 
a feeling that it's not clear where the documentation is or that 
documentation is missing ;-)

IIRC, about a month ago someone already asked for precision on the 
meaning of some KEY_* . It would probably worth documenting more each 
key. More specifically, it could be interesting to decide if the keycode 
has to be associated to the physical symbol displayed on the key or 
associated to the function that the user (developer) expects when 
pressing this key.

Eric

Re: [PATCH 0/2] wistron_btns: More keymaps

[Vojtech Pavlik]

On Wed, Mar 14, 2007 at 02:58:49PM -0400, Dmitry Torokhov wrote:

> >> I have couple of comments/requests:
> >>
> >> 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the
> >> lid, they correspond to Accpication Control Open and Close keys from
> >> USB HID HUT spec:
> >>
> >>     http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> >>
> >> SW_LID shoudl be used to signal lid state instead.
> >>
> >> 2. I also have a concern about using KEY_SCREEN to signal toggling
> >> display on and off. I am CCing Vojtech - he must know what the
> >> original intent of this key code was. BTW, when user presses
> >> corresponding button - does the display actually goes off? Maybe we
> >> need another switch.
> >
> >Sorry, Dmitry, I probably should have documented it back then, I don't
> >have the slightest idea anymore.
> >
> 
> That's what I was afraid of ;) Well, maybe we should just use it to
> indicate display switch and add a comment to that effect to input.h...

Digging somewhat deeper into my memory, I think it just so happened that
there was a keyboard with a key with a pictogram of a computer screen on
it with no really defined purpose. Since at that time there was only a
limited number of different extended keyboard types, it was added.

I think it'd make sense to use it eg. for the key that switches between
internal and external output on laptops, if the laptop generates a
keycode for the key at all. But maybe that function is already taken by
KEY_SWITCHVIDEOMODE ...

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [PATCH 0/2] wistron_btns: More keymaps

[Éric Piel]

03/14/2007 08:02 PM, Vojtech Pavlik wrote/a écrit:
> On Wed, Mar 14, 2007 at 02:58:49PM -0400, Dmitry Torokhov wrote:
> 
>>>> 2. I also have a concern about using KEY_SCREEN to signal toggling
>>>> display on and off. I am CCing Vojtech - he must know what the
>>>> original intent of this key code was. BTW, when user presses
>>>> corresponding button - does the display actually goes off? Maybe we
>>>> need another switch.
>>> Sorry, Dmitry, I probably should have documented it back then, I don't
>>> have the slightest idea anymore.
>>>
>> That's what I was afraid of ;) Well, maybe we should just use it to
>> indicate display switch and add a comment to that effect to input.h...
> 
> Digging somewhat deeper into my memory, I think it just so happened that
> there was a keyboard with a key with a pictogram of a computer screen on
> it with no really defined purpose. Since at that time there was only a
> limited number of different extended keyboard types, it was added.
> 
> I think it'd make sense to use it eg. for the key that switches between
> internal and external output on laptops, if the laptop generates a
> keycode for the key at all. But maybe that function is already taken by
> KEY_SWITCHVIDEOMODE ...

Ok, so let me summarize:

There are two kinds of keys on those laptops (for which we are not sure 
about the keycode that it should generate):
* Laptop screen on/off
* Display output selection (for instance: laptop/external/both)

The possible keycodes that we could assign to them:
KEY_SCREEN
KEY_MEDIA
KEY_MODE
KEY_VIDEO
KEY_SWITCHVIDEOMODE
KEY_COMPUTER
KEY_PC

 From the discussion, I had the feeling this association would be the 
less incorrect:
Screen on/off : KEY_SCREEN
Display selection : KEY_SWITCHVIDEOMODE

Is that ok with everyone? If not, please suggest something better ;-)

See you,
Eric

PS: So far, I believe that for all laptops, those keys are just normal 
keys (as opposed to a key which would also do by itself its intended 
action).  At least on a 3020, pressing "screen on/off" doesn't 
automatically switch on/off the screen.

[PATCH 0/3] wistron_btns: More keymaps, take 2

[Éric Piel]

Hello,

This is a new version of my patch to add support for more laptops to the 
wistron_btns driver. Modifications from the previous version:
* sends lid close/open event as a switch event (not a key event)
* Display on/off is KEY_SCREEN and Display selection is 
KEY_SWITCHVIDEOMODE, from the discussion they seemed the "less bad" 
keycodes.
* keymaps are now declared initdata in order to save some memory


Patch 1 adds all the database of acerhk which fits this driver (about 25 
more laptops).
Patch 2 adds a generic map that should fit most users but has the 
disadvantage of not being automatic.
Patch 3 declares all the keymaps as initdata and copy the right one in 
memory.

Dmitry, I've tried to make them against your tree (tm610 already 
applied). Still, if they don't apply cleanly, just tell me and I'll try 
harder!

See you,
Eric

Re: [PATCH 0/3] wistron_btns: More keymaps, take 2

[Dmitry Torokhov]

On Sunday 18 March 2007 17:10, Éric Piel wrote:
> Hello,
> 
> This is a new version of my patch to add support for more laptops to the 
> wistron_btns driver. Modifications from the previous version:
> * sends lid close/open event as a switch event (not a key event)
> * Display on/off is KEY_SCREEN and Display selection is 
> KEY_SWITCHVIDEOMODE, from the discussion they seemed the "less bad" 
> keycodes.
> * keymaps are now declared initdata in order to save some memory
>

Everyting applied to the input tree. Used new KEY_DISPLAYTOGGLE instead
of KEY_SCREEN.
 
Thank you Eric.

-- 
Dmitry

[PATCH 1/3] wriston_btns: Add acerhk laptop database

[Éric Piel]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

This patch adds all the "tm_new" laptops information that is in acerhk 
to wistron_btns. That's about 25 more laptops. Obviously, I couldn't try 
them all. I've just tried the Aspire 3020. For this reason, I've also 
added a printk which ask the users of those laptops to confirm me it 
works (or not). Surprisingly, the dmi information could be found on 
google for a majority of the laptops, so it might not work so badly.

The information about which laptop has which led is also imported, 
however for now it doesn't do anything. It's just in case someone adds 
led support later, in order to avoid hunting information in the acerhk 
for a second time.

Eric

[-- Attachment #2: wistron_btns-add-acerhk-database-2.6.21-b.patch --]
[-- Type: text/x-patch, Size: 21280 bytes --]

From: Eric Piel <eric.piel@tremplin-utc.net>

wriston_btns: Add acerhk laptop database

acerhk supports already a lot of laptops. Lets import its database so that
everyone can benefit of the work of Olaf Tauber. Only the "tm_new" laptops were
imported. "tm_old" laptops could be possible but requires more testing and
probably only few laptops are still alive. "dritek" laptops should 
probably be imported into a different driver. Also compress the keymaps by
fitting each entry on an int. Most of the dmi matching was written based on
google searches, so it's rather prone to errors. That's why I'm asking people
to confirm it works.

Support to generate switch input events was added as some laptops indicate lid
open/close through this interface.

This adds the following hardware:
Acer TravelMate 370
Acer TravelMate 380
Acer TravelMate C300
Acer TravelMate C100
Acer TravelMate C110
Acer TravelMate 250
Acer TravelMate 350
Acer TravelMate 620
Acer TravelMate 630
Acer TravelMate 220
Acer TravelMate 230
Acer TravelMate 260
Acer TravelMate 280
Acer TravelMate 360
Acer TravelMate 2100
Acer TravelMate 2410
Acer Aspire 1500
Acer Aspire 1600
Acer Aspire 3020
Acer Aspire 5020
Medion MD 2900
Medion MD 40100
Medion MD 95400
Medion MD 96500
Fujitsu Siemens Amilo 7820

Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>

--- linux-2.6.21/drivers/input/misc/wistron_btns.c~tm610	2007-03-10 01:41:23.000000000 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c	2007-03-17 10:09:11.000000000 +0100
@@ -233,10 +233,20 @@ static void bios_set_state(u8 subsys, in
 struct key_entry {
 	char type;		/* See KE_* below */
 	u8 code;
-	unsigned keycode;	/* For KE_KEY */
+	union {
+		u16 keycode;		/* For KE_KEY */
+		struct {		/* For KE_SW */
+			u8 code;
+			u8 value;
+		} sw;
+	};
 };
 
-enum { KE_END, KE_KEY, KE_WIFI, KE_BLUETOOTH };
+enum { KE_END, KE_KEY, KE_SW, KE_WIFI, KE_BLUETOOTH };
+
+#define FE_MAIL_LED 0x01
+#define FE_WIFI_LED 0x02
+#define FE_UNTESTED 0x80
 
 static const struct key_entry *keymap; /* = NULL; Current key map */
 static int have_wifi;
@@ -261,104 +271,301 @@ static struct key_entry keymap_empty[] =
 };
 
 static struct key_entry keymap_fs_amilo_pro_v2000[] = {
-	{ KE_KEY,  0x01, KEY_HELP },
-	{ KE_KEY,  0x11, KEY_PROG1 },
-	{ KE_KEY,  0x12, KEY_PROG2 },
-	{ KE_WIFI, 0x30, 0 },
-	{ KE_KEY,  0x31, KEY_MAIL },
-	{ KE_KEY,  0x36, KEY_WWW },
+	{ KE_KEY,  0x01, {KEY_HELP} },
+	{ KE_KEY,  0x11, {KEY_PROG1} },
+	{ KE_KEY,  0x12, {KEY_PROG2} },
+	{ KE_WIFI, 0x30 },
+	{ KE_KEY,  0x31, {KEY_MAIL} },
+	{ KE_KEY,  0x36, {KEY_WWW} },
 	{ KE_END,  0 }
 };
 
 static struct key_entry keymap_fujitsu_n3510[] = {
-	{ KE_KEY, 0x11, KEY_PROG1 },
-	{ KE_KEY, 0x12, KEY_PROG2 },
-	{ KE_KEY, 0x36, KEY_WWW },
-	{ KE_KEY, 0x31, KEY_MAIL },
-	{ KE_KEY, 0x71, KEY_STOPCD },
-	{ KE_KEY, 0x72, KEY_PLAYPAUSE },
-	{ KE_KEY, 0x74, KEY_REWIND },
-	{ KE_KEY, 0x78, KEY_FORWARD },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x71, {KEY_STOPCD} },
+	{ KE_KEY, 0x72, {KEY_PLAYPAUSE} },
+	{ KE_KEY, 0x74, {KEY_REWIND} },
+	{ KE_KEY, 0x78, {KEY_FORWARD} },
 	{ KE_END, 0 }
 };
 
 static struct key_entry keymap_wistron_ms2111[] = {
-	{ KE_KEY,  0x11, KEY_PROG1 },
-	{ KE_KEY,  0x12, KEY_PROG2 },
-	{ KE_KEY,  0x13, KEY_PROG3 },
-	{ KE_KEY,  0x31, KEY_MAIL },
-	{ KE_KEY,  0x36, KEY_WWW },
-	{ KE_END,  0 }
+	{ KE_KEY,  0x11, {KEY_PROG1} },
+	{ KE_KEY,  0x12, {KEY_PROG2} },
+	{ KE_KEY,  0x13, {KEY_PROG3} },
+	{ KE_KEY,  0x31, {KEY_MAIL} },
+	{ KE_KEY,  0x36, {KEY_WWW} },
+	{ KE_END, FE_MAIL_LED }
+};
+
+static struct key_entry keymap_wistron_md40100[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x37, {KEY_SCREEN} }, /* Display on/off */
+	{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
 };
 
 static struct key_entry keymap_wistron_ms2141[] = {
-	{ KE_KEY,  0x11, KEY_PROG1 },
-	{ KE_KEY,  0x12, KEY_PROG2 },
-	{ KE_WIFI, 0x30, 0 },
-	{ KE_KEY,  0x22, KEY_REWIND },
-	{ KE_KEY,  0x23, KEY_FORWARD },
-	{ KE_KEY,  0x24, KEY_PLAYPAUSE },
-	{ KE_KEY,  0x25, KEY_STOPCD },
-	{ KE_KEY,  0x31, KEY_MAIL },
-	{ KE_KEY,  0x36, KEY_WWW },
+	{ KE_KEY,  0x11, {KEY_PROG1} },
+	{ KE_KEY,  0x12, {KEY_PROG2} },
+	{ KE_WIFI, 0x30 },
+	{ KE_KEY,  0x22, {KEY_REWIND} },
+	{ KE_KEY,  0x23, {KEY_FORWARD} },
+	{ KE_KEY,  0x24, {KEY_PLAYPAUSE} },
+	{ KE_KEY,  0x25, {KEY_STOPCD} },
+	{ KE_KEY,  0x31, {KEY_MAIL} },
+	{ KE_KEY,  0x36, {KEY_WWW} },
 	{ KE_END,  0 }
 };
 
 static struct key_entry keymap_acer_aspire_1500[] = {
-	{ KE_KEY, 0x11, KEY_PROG1 },
-	{ KE_KEY, 0x12, KEY_PROG2 },
-	{ KE_WIFI, 0x30, 0 },
-	{ KE_KEY, 0x31, KEY_MAIL },
-	{ KE_KEY, 0x36, KEY_WWW },
-	{ KE_BLUETOOTH, 0x44, 0 },
-	{ KE_END, 0 }
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_WIFI, 0x30 },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x49, {KEY_CONFIG} },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_aspire_1600[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_PROG3} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x49, {KEY_CONFIG} },
+	{ KE_WIFI, 0x30 },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+/* 3020 has been tested */
+static struct key_entry keymap_acer_aspire_5020[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x6a, {KEY_CONFIG} },
+	{ KE_WIFI, 0x30 },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_2410[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x6d, {KEY_POWER} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x6a, {KEY_CONFIG} },
+	{ KE_WIFI, 0x30 },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_110[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x20, {KEY_VOLUMEUP} },
+	{ KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_SW, 0x4a, {.sw = {SW_LID, 1}} }, /* lid close */
+	{ KE_SW, 0x4b, {.sw = {SW_LID, 0}} }, /* lid open */
+	{ KE_WIFI, 0x30 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_300[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x20, {KEY_VOLUMEUP} },
+	{ KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_WIFI, 0x30 },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_380[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x03, {KEY_POWER} }, /* not 370 */
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_PROG3} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_WIFI, 0x30 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+/* unusual map */
+static struct key_entry keymap_acer_travelmate_220[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x11, {KEY_MAIL} },
+	{ KE_KEY, 0x12, {KEY_WWW} },
+	{ KE_KEY, 0x13, {KEY_PROG2} },
+	{ KE_KEY, 0x31, {KEY_PROG1} },
+	{ KE_END, FE_WIFI_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_230[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_END, FE_WIFI_LED | FE_UNTESTED }
 };
 
 static struct key_entry keymap_acer_travelmate_240[] = {
-	{ KE_KEY, 0x31, KEY_MAIL },
-	{ KE_KEY, 0x36, KEY_WWW },
-	{ KE_KEY, 0x11, KEY_PROG1 },
-	{ KE_KEY, 0x12, KEY_PROG2 },
-	{ KE_BLUETOOTH, 0x44, 0 },
-	{ KE_WIFI, 0x30, 0 },
-	{ KE_END, 0 }
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_WIFI, 0x30 },
+	{ KE_END, FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_350[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_MAIL} },
+	{ KE_KEY, 0x14, {KEY_PROG3} },
+	{ KE_KEY, 0x15, {KEY_WWW} },
+	{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_acer_travelmate_360[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_MAIL} },
+	{ KE_KEY, 0x14, {KEY_PROG3} },
+	{ KE_KEY, 0x15, {KEY_WWW} },
+	{ KE_KEY, 0x40, {KEY_WLAN} },
+	{ KE_END, FE_WIFI_LED | FE_UNTESTED } /* no mail led */
 };
 
 /* Wifi subsystem only activate the led. Therefore we need to pass
  * wifi event as a normal key, then userspace can really change the wifi state.
  * TODO we need to export led state to userspace (wifi and mail) */
 static struct key_entry keymap_acer_travelmate_610[] = {
-	{ KE_KEY, 0x01, KEY_HELP },
-	{ KE_KEY, 0x02, KEY_CONFIG },
-	{ KE_KEY, 0x11, KEY_PROG1 },
-	{ KE_KEY, 0x12, KEY_PROG2 },
-	{ KE_KEY, 0x13, KEY_PROG3 },
-	{ KE_KEY, 0x14, KEY_MAIL },
-	{ KE_KEY, 0x15, KEY_WWW },
-	{ KE_KEY, 0x40, KEY_WLAN }, /* Wifi */
-	{ KE_END, 0 }
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG3} },
+	{ KE_KEY, 0x13, {KEY_PROG3} },
+	{ KE_KEY, 0x14, {KEY_MAIL} },
+	{ KE_KEY, 0x15, {KEY_WWW} },
+	{ KE_KEY, 0x40, {KEY_WLAN} },
+	{ KE_END, FE_MAIL_LED | FE_WIFI_LED }
+};
+
+static struct key_entry keymap_acer_travelmate_630[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x08, {KEY_MUTE} }, /* not 620 */
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_PROG3} },
+	{ KE_KEY, 0x20, {KEY_VOLUMEUP} },
+	{ KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_WIFI, 0x30 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
 static struct key_entry keymap_aopen_1559as[] = {
-	{ KE_KEY,  0x01, KEY_HELP },
-	{ KE_KEY,  0x06, KEY_PROG3 },
-	{ KE_KEY,  0x11, KEY_PROG1 },
-	{ KE_KEY,  0x12, KEY_PROG2 },
-	{ KE_WIFI, 0x30, 0 },
-	{ KE_KEY,  0x31, KEY_MAIL },
-	{ KE_KEY,  0x36, KEY_WWW },
+	{ KE_KEY,  0x01, {KEY_HELP} },
+	{ KE_KEY,  0x06, {KEY_PROG3} },
+	{ KE_KEY,  0x11, {KEY_PROG1} },
+	{ KE_KEY,  0x12, {KEY_PROG2} },
+	{ KE_WIFI, 0x30 },
+	{ KE_KEY,  0x31, {KEY_MAIL} },
+	{ KE_KEY,  0x36, {KEY_WWW} },
 	{ KE_END,  0 },
 };
 
 static struct key_entry keymap_fs_amilo_d88x0[] = {
-	{ KE_KEY, 0x01, KEY_HELP },
-	{ KE_KEY, 0x08, KEY_MUTE },
-	{ KE_KEY, 0x31, KEY_MAIL },
-	{ KE_KEY, 0x36, KEY_WWW },
-	{ KE_KEY, 0x11, KEY_PROG1 },
-	{ KE_KEY, 0x12, KEY_PROG2 },
-	{ KE_KEY, 0x13, KEY_PROG3 },
-	{ KE_END, 0 }
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_PROG3} },
+	{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_wistron_md2900[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_WIFI, 0x30 },
+	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
+};
+
+static struct key_entry keymap_wistron_md96500[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
+	{ KE_KEY, 0x06, {KEY_SCREEN} }, /* Display on/off */
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x20, {KEY_VOLUMEUP} },
+	{ KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+	{ KE_KEY, 0x22, {KEY_REWIND} },
+	{ KE_KEY, 0x23, {KEY_FORWARD} },
+	{ KE_KEY, 0x24, {KEY_PLAYPAUSE} },
+	{ KE_KEY, 0x25, {KEY_STOPCD} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_WIFI, 0x30 },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, FE_UNTESTED }
 };
 
 /*
@@ -405,6 +612,133 @@ static struct dmi_system_id dmi_ids[] __
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "Acer Aspire 1600",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 1600"),
+		},
+		.driver_data = keymap_acer_aspire_1600
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer Aspire 3020",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 3020"),
+		},
+		.driver_data = keymap_acer_aspire_5020
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer Aspire 5020",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5020"),
+		},
+		.driver_data = keymap_acer_aspire_5020
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 2100",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 2100"),
+		},
+		.driver_data = keymap_acer_aspire_5020
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 2410",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 2410"),
+		},
+		.driver_data = keymap_acer_travelmate_2410
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate C300",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate C300"),
+		},
+		.driver_data = keymap_acer_travelmate_300
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate C100",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate C100"),
+		},
+		.driver_data = keymap_acer_travelmate_300
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate C110",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate C110"),
+		},
+		.driver_data = keymap_acer_travelmate_110
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 380",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 380"),
+		},
+		.driver_data = keymap_acer_travelmate_380
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 370",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 370"),
+		},
+		.driver_data = keymap_acer_travelmate_380 /* keyboard minus 1 key */
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 220",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 220"),
+		},
+		.driver_data = keymap_acer_travelmate_220
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 260",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 260"),
+		},
+		.driver_data = keymap_acer_travelmate_220
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 230",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 230"),
+			/* acerhk looks for "TravelMate F4..." ?! */
+		},
+		.driver_data = keymap_acer_travelmate_230
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 280",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 280"),
+		},
+		.driver_data = keymap_acer_travelmate_230
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "Acer TravelMate 240",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
@@ -414,6 +748,15 @@ static struct dmi_system_id dmi_ids[] __
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "Acer TravelMate 250",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 250"),
+		},
+		.driver_data = keymap_acer_travelmate_240
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "Acer TravelMate 2424NWXCi",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
@@ -423,6 +766,24 @@ static struct dmi_system_id dmi_ids[] __
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "Acer TravelMate 350",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 350"),
+		},
+		.driver_data = keymap_acer_travelmate_350
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 360",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
+		},
+		.driver_data = keymap_acer_travelmate_360
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "Acer TravelMate 610",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ACER"),
@@ -432,6 +793,24 @@ static struct dmi_system_id dmi_ids[] __
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "Acer TravelMate 620",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 620"),
+		},
+		.driver_data = keymap_acer_travelmate_630
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Acer TravelMate 630",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 630"),
+		},
+		.driver_data = keymap_acer_travelmate_630
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "AOpen 1559AS",
 		.matches = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "E2U"),
@@ -450,6 +829,51 @@ static struct dmi_system_id dmi_ids[] __
 	},
 	{
 		.callback = dmi_matched,
+		.ident = "Medion MD 40100",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "MEDIONNB"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "WID2000"),
+		},
+		.driver_data = keymap_wistron_md40100
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Medion MD 2900",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "MEDIONNB"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "WIM 2000"),
+		},
+		.driver_data = keymap_wistron_md2900
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Medion MD 96500",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "MEDIONPC"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "WIM 2040"),
+		},
+		.driver_data = keymap_wistron_md96500
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Medion MD 95400",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "MEDIONPC"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "WIM 2050"),
+		},
+		.driver_data = keymap_wistron_md96500
+	},
+	{
+		.callback = dmi_matched,
+		.ident = "Fujitsu Siemens Amilo D7820",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"), /* not sure */
+			DMI_MATCH(DMI_PRODUCT_NAME, "Amilo D"),
+		},
+		.driver_data = keymap_fs_amilo_d88x0
+	},
+	{
+		.callback = dmi_matched,
 		.ident = "Fujitsu Siemens Amilo D88x0",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU SIEMENS"),
@@ -500,12 +924,28 @@ static int __devinit setup_input_dev(voi
 	input_dev->cdev.dev = &wistron_device->dev;
 
 	for (key = keymap; key->type != KE_END; key++) {
-		if (key->type == KE_KEY) {
-			input_dev->evbit[LONG(EV_KEY)] = BIT(EV_KEY);
-			set_bit(key->keycode, input_dev->keybit);
+		switch (key->type) {
+			case KE_KEY:
+				set_bit(EV_KEY, input_dev->evbit);
+				set_bit(key->keycode, input_dev->keybit);
+				break;
+
+			case KE_SW:
+				set_bit(EV_SW, input_dev->evbit);
+				set_bit(key->sw.code, input_dev->swbit);
+				break;
+
+			default:
+				;
 		}
 	}
 
+	/* reads information flags on KE_END */
+	if (key->code & FE_UNTESTED)
+		printk(KERN_WARNING "Untested laptop multimedia keys, "
+			"please report success or failure to eric.piel"
+			"@tremplin-utc.net\n");
+
 	error = input_register_device(input_dev);
 	if (error) {
 		input_free_device(input_dev);
@@ -523,6 +963,12 @@ static void report_key(unsigned keycode)
 	input_sync(input_dev);
 }
 
+static void report_switch(unsigned code, int value)
+{
+	input_report_switch(input_dev, code, value);
+	input_sync(input_dev);
+}
+
  /* Driver core */
 
 static int wifi_enabled;
@@ -543,6 +989,10 @@ static void handle_key(u8 code)
 				report_key(key->keycode);
 				break;
 
+			case KE_SW:
+				report_switch(key->sw.code, key->sw.value);
+				break;
+
 			case KE_WIFI:
 				if (have_wifi) {
 					wifi_enabled = !wifi_enabled;
@@ -558,6 +1008,7 @@ static void handle_key(u8 code)
 				break;
 
 			case KE_END:
+				break;
 			default:
 				BUG();
 			}

[PATCH 2/3] wistron_btns: Generic keymap

[Éric Piel]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

This patch adds a generic map. That is, a keymap that should output the 
correct keycodes for most laptops. This is simply based on the 
observation of all those keymaps already gathered, as most of the 
wistron codes are always mapped to the same keycode.

Hopefully, this way users which have a non-supported laptop will have a 
quick and dirty way to use the multimedia keys.

Eric

[-- Attachment #2: wistron_btns-generic-map-2.6.21-b.patch --]
[-- Type: text/x-patch, Size: 3098 bytes --]

From: Eric Piel <eric.piel@tremplin-utc.net>

wistron_btns: Generic keymap

It turns out that the mapping of the wistron code is always the same, the
main difference being some keys which may not exist and leds which might not be
present. Therefore it's possible to write a generic keymap which would allow
the use of an unknown keyboard with little drawbacks. The user can select it
specifying the parameter "keymap=generic".

Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>

--- linux-2.6.21/drivers/input/misc/wistron_btns.c	2007-03-17 10:09:11.000000000 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c~full	2007-03-17 10:09:14.000000000 +0100
@@ -58,7 +58,7 @@ MODULE_PARM_DESC(force, "Load even if co
 
 static char *keymap_name; /* = NULL; */
 module_param_named(keymap, keymap_name, charp, 0);
-MODULE_PARM_DESC(keymap, "Keymap name, if it can't be autodetected");
+MODULE_PARM_DESC(keymap, "Keymap name, if it can't be autodetected [generic, 1557/MS2141]");
 
 static struct platform_device *wistron_device;
 
@@ -568,6 +568,42 @@ static struct key_entry keymap_wistron_m
 	{ KE_END, FE_UNTESTED }
 };
 
+static struct key_entry keymap_wistron_generic[] = {
+	{ KE_KEY, 0x01, {KEY_HELP} },
+	{ KE_KEY, 0x02, {KEY_CONFIG} },
+	{ KE_KEY, 0x03, {KEY_POWER} },
+	{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
+	{ KE_KEY, 0x06, {KEY_SCREEN} }, /* Display on/off */
+	{ KE_KEY, 0x08, {KEY_MUTE} },
+	{ KE_KEY, 0x11, {KEY_PROG1} },
+	{ KE_KEY, 0x12, {KEY_PROG2} },
+	{ KE_KEY, 0x13, {KEY_PROG3} },
+	{ KE_KEY, 0x14, {KEY_MAIL} },
+	{ KE_KEY, 0x15, {KEY_WWW} },
+	{ KE_KEY, 0x20, {KEY_VOLUMEUP} },
+	{ KE_KEY, 0x21, {KEY_VOLUMEDOWN} },
+	{ KE_KEY, 0x22, {KEY_REWIND} },
+	{ KE_KEY, 0x23, {KEY_FORWARD} },
+	{ KE_KEY, 0x24, {KEY_PLAYPAUSE} },
+	{ KE_KEY, 0x25, {KEY_STOPCD} },
+	{ KE_KEY, 0x31, {KEY_MAIL} },
+	{ KE_KEY, 0x36, {KEY_WWW} },
+	{ KE_KEY, 0x37, {KEY_SCREEN} }, /* Display on/off */
+	{ KE_KEY, 0x40, {KEY_WLAN} },
+	{ KE_KEY, 0x49, {KEY_CONFIG} },
+	{ KE_SW, 0x4a, {.sw = {SW_LID, 1}} }, /* lid close */
+	{ KE_SW, 0x4b, {.sw = {SW_LID, 0}} }, /* lid open */
+	{ KE_KEY, 0x6a, {KEY_CONFIG} },
+	{ KE_KEY, 0x6d, {KEY_POWER} },
+	{ KE_KEY, 0x71, {KEY_STOPCD} },
+	{ KE_KEY, 0x72, {KEY_PLAYPAUSE} },
+	{ KE_KEY, 0x74, {KEY_REWIND} },
+	{ KE_KEY, 0x78, {KEY_FORWARD} },
+	{ KE_WIFI, 0x30 },
+	{ KE_BLUETOOTH, 0x44 },
+	{ KE_END, 0 }
+};
+
 /*
  * If your machine is not here (which is currently rather likely), please send
  * a list of buttons and their key codes (reported when loading this module
@@ -886,15 +922,17 @@ static struct dmi_system_id dmi_ids[] __
 
 static int __init select_keymap(void)
 {
+	dmi_check_system(dmi_ids);
 	if (keymap_name != NULL) {
 		if (strcmp (keymap_name, "1557/MS2141") == 0)
 			keymap = keymap_wistron_ms2141;
+		else if (strcmp (keymap_name, "generic") == 0)
+			keymap = keymap_wistron_generic;
 		else {
 			printk(KERN_ERR "wistron_btns: Keymap unknown\n");
 			return -EINVAL;
 		}
 	}
-	dmi_check_system(dmi_ids);
 	if (keymap == NULL) {
 		if (!force) {
 			printk(KERN_ERR "wistron_btns: System unknown\n");

[PATCH 3/3] wistron_btns: Declare keymaps as initdata

[Éric Piel]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

This patch declares keymaps as initdata, so they are discarded at 
runtime, saving about 1kb (10% of the module size). This idea to save 
memory comes from Dmitry Torokhov.

Eric

[-- Attachment #2: wistron_btns-keymap-initdata-2.6.21-b.patch --]
[-- Type: text/x-patch, Size: 9982 bytes --]

From: Eric Piel <eric.piel@tremplin-utc.net>

wriston_btns: Declare keymaps as initdata

As the number of keymaps increases and is very unlikely to reduce, this patch
helps to reduce the memory consumption. Declare all the keymaps as __initdata,
and copy during the detection the right keymap. On my x86, this make the module
size at runtime going from 10616 to 9428: a bit more than 1kb saved.

Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>

--- linux-2.6.21/drivers/input/misc/wistron_btns.c~full	2007-03-17 10:09:14.000000000 +0100
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c	2007-03-18 19:15:57.000000000 +0100
@@ -50,7 +50,7 @@
 MODULE_AUTHOR("Miloslav Trmac <mitr@volny.cz>");
 MODULE_DESCRIPTION("Wistron laptop button driver");
 MODULE_LICENSE("GPL v2");
-MODULE_VERSION("0.1");
+MODULE_VERSION("0.2");
 
 static int force; /* = 0; */
 module_param(force, bool, 0);
@@ -266,11 +266,11 @@ static int __init dmi_matched(struct dmi
 	return 1;
 }
 
-static struct key_entry keymap_empty[] = {
+static struct key_entry keymap_empty[] __initdata = {
 	{ KE_END, 0 }
 };
 
-static struct key_entry keymap_fs_amilo_pro_v2000[] = {
+static struct key_entry keymap_fs_amilo_pro_v2000[] __initdata = {
 	{ KE_KEY,  0x01, {KEY_HELP} },
 	{ KE_KEY,  0x11, {KEY_PROG1} },
 	{ KE_KEY,  0x12, {KEY_PROG2} },
@@ -280,7 +280,7 @@ static struct key_entry keymap_fs_amilo_
 	{ KE_END,  0 }
 };
 
-static struct key_entry keymap_fujitsu_n3510[] = {
+static struct key_entry keymap_fujitsu_n3510[] __initdata = {
 	{ KE_KEY, 0x11, {KEY_PROG1} },
 	{ KE_KEY, 0x12, {KEY_PROG2} },
 	{ KE_KEY, 0x36, {KEY_WWW} },
@@ -292,7 +292,7 @@ static struct key_entry keymap_fujitsu_n
 	{ KE_END, 0 }
 };
 
-static struct key_entry keymap_wistron_ms2111[] = {
+static struct key_entry keymap_wistron_ms2111[] __initdata = {
 	{ KE_KEY,  0x11, {KEY_PROG1} },
 	{ KE_KEY,  0x12, {KEY_PROG2} },
 	{ KE_KEY,  0x13, {KEY_PROG3} },
@@ -301,7 +301,7 @@ static struct key_entry keymap_wistron_m
 	{ KE_END, FE_MAIL_LED }
 };
 
-static struct key_entry keymap_wistron_md40100[] = {
+static struct key_entry keymap_wistron_md40100[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x31, {KEY_MAIL} },
@@ -310,7 +310,7 @@ static struct key_entry keymap_wistron_m
 	{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_wistron_ms2141[] = {
+static struct key_entry keymap_wistron_ms2141[] __initdata = {
 	{ KE_KEY,  0x11, {KEY_PROG1} },
 	{ KE_KEY,  0x12, {KEY_PROG2} },
 	{ KE_WIFI, 0x30 },
@@ -323,7 +323,7 @@ static struct key_entry keymap_wistron_m
 	{ KE_END,  0 }
 };
 
-static struct key_entry keymap_acer_aspire_1500[] = {
+static struct key_entry keymap_acer_aspire_1500[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -336,7 +336,7 @@ static struct key_entry keymap_acer_aspi
 	{ KE_END, FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_aspire_1600[] = {
+static struct key_entry keymap_acer_aspire_1600[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
 	{ KE_KEY, 0x08, {KEY_MUTE} },
@@ -352,7 +352,7 @@ static struct key_entry keymap_acer_aspi
 };
 
 /* 3020 has been tested */
-static struct key_entry keymap_acer_aspire_5020[] = {
+static struct key_entry keymap_acer_aspire_5020[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
 	{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
@@ -366,7 +366,7 @@ static struct key_entry keymap_acer_aspi
 	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_2410[] = {
+static struct key_entry keymap_acer_travelmate_2410[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x6d, {KEY_POWER} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -379,7 +379,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_110[] = {
+static struct key_entry keymap_acer_travelmate_110[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
@@ -396,7 +396,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_300[] = {
+static struct key_entry keymap_acer_travelmate_300[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
@@ -412,7 +412,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_380[] = {
+static struct key_entry keymap_acer_travelmate_380[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x03, {KEY_POWER} }, /* not 370 */
@@ -426,7 +426,7 @@ static struct key_entry keymap_acer_trav
 };
 
 /* unusual map */
-static struct key_entry keymap_acer_travelmate_220[] = {
+static struct key_entry keymap_acer_travelmate_220[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x11, {KEY_MAIL} },
@@ -436,7 +436,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_WIFI_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_230[] = {
+static struct key_entry keymap_acer_travelmate_230[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -446,7 +446,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_WIFI_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_240[] = {
+static struct key_entry keymap_acer_travelmate_240[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
@@ -460,7 +460,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_350[] = {
+static struct key_entry keymap_acer_travelmate_350[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -471,7 +471,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_acer_travelmate_360[] = {
+static struct key_entry keymap_acer_travelmate_360[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -486,7 +486,7 @@ static struct key_entry keymap_acer_trav
 /* Wifi subsystem only activate the led. Therefore we need to pass
  * wifi event as a normal key, then userspace can really change the wifi state.
  * TODO we need to export led state to userspace (wifi and mail) */
-static struct key_entry keymap_acer_travelmate_610[] = {
+static struct key_entry keymap_acer_travelmate_610[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -498,7 +498,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_MAIL_LED | FE_WIFI_LED }
 };
 
-static struct key_entry keymap_acer_travelmate_630[] = {
+static struct key_entry keymap_acer_travelmate_630[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
@@ -514,7 +514,7 @@ static struct key_entry keymap_acer_trav
 	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_aopen_1559as[] = {
+static struct key_entry keymap_aopen_1559as[] __initdata = {
 	{ KE_KEY,  0x01, {KEY_HELP} },
 	{ KE_KEY,  0x06, {KEY_PROG3} },
 	{ KE_KEY,  0x11, {KEY_PROG1} },
@@ -525,7 +525,7 @@ static struct key_entry keymap_aopen_155
 	{ KE_END,  0 },
 };
 
-static struct key_entry keymap_fs_amilo_d88x0[] = {
+static struct key_entry keymap_fs_amilo_d88x0[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x08, {KEY_MUTE} },
 	{ KE_KEY, 0x31, {KEY_MAIL} },
@@ -536,7 +536,7 @@ static struct key_entry keymap_fs_amilo_
 	{ KE_END, FE_MAIL_LED | FE_WIFI_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_wistron_md2900[] = {
+static struct key_entry keymap_wistron_md2900[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x11, {KEY_PROG1} },
@@ -547,7 +547,7 @@ static struct key_entry keymap_wistron_m
 	{ KE_END, FE_MAIL_LED | FE_UNTESTED }
 };
 
-static struct key_entry keymap_wistron_md96500[] = {
+static struct key_entry keymap_wistron_md96500[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x05, {KEY_SWITCHVIDEOMODE} }, /* Display selection */
@@ -568,7 +568,7 @@ static struct key_entry keymap_wistron_m
 	{ KE_END, FE_UNTESTED }
 };
 
-static struct key_entry keymap_wistron_generic[] = {
+static struct key_entry keymap_wistron_generic[] __initdata = {
 	{ KE_KEY, 0x01, {KEY_HELP} },
 	{ KE_KEY, 0x02, {KEY_CONFIG} },
 	{ KE_KEY, 0x03, {KEY_POWER} },
@@ -920,6 +920,26 @@ static struct dmi_system_id dmi_ids[] __
 	{ NULL, }
 };
 
+/* Copy the good keymap, as the original ones are free'd */
+static int __init copy_keymap(void)
+{
+	const struct key_entry *key;
+	struct key_entry *new_keymap;
+	unsigned int length = 1;
+
+	for (key = keymap; key->type != KE_END; key++)
+		length++;
+
+	new_keymap = kmalloc(length * sizeof(struct key_entry), GFP_KERNEL);
+	if (!new_keymap)
+		return -ENOMEM;
+
+	memcpy(new_keymap, keymap, length * sizeof(struct key_entry));
+	keymap = new_keymap;
+
+	return 0;
+}
+
 static int __init select_keymap(void)
 {
 	dmi_check_system(dmi_ids);
@@ -940,7 +960,8 @@ static int __init select_keymap(void)
 		}
 		keymap = keymap_empty;
 	}
-	return 0;
+
+	return copy_keymap();
 }
 
  /* Input layer interface */
@@ -1203,6 +1224,7 @@ static void __exit wb_module_exit(void)
 	platform_device_unregister(wistron_device);
 	platform_driver_unregister(&wistron_driver);
 	unmap_bios();
+	kfree(keymap);
 }
 
 module_init(wb_module_init);

Re: [PATCH 0/2] wistron_btns: More keymaps

[Dmitry Torokhov]

On 3/15/07, Éric Piel <Eric.Piel@tremplin-utc.net> wrote:
> 03/14/2007 08:02 PM, Vojtech Pavlik wrote/a écrit:
> > On Wed, Mar 14, 2007 at 02:58:49PM -0400, Dmitry Torokhov wrote:
> >
> >>>> 2. I also have a concern about using KEY_SCREEN to signal toggling
> >>>> display on and off. I am CCing Vojtech - he must know what the
> >>>> original intent of this key code was. BTW, when user presses
> >>>> corresponding button - does the display actually goes off? Maybe we
> >>>> need another switch.
> >>> Sorry, Dmitry, I probably should have documented it back then, I don't
> >>> have the slightest idea anymore.
> >>>
> >> That's what I was afraid of ;) Well, maybe we should just use it to
> >> indicate display switch and add a comment to that effect to input.h...
> >
> > Digging somewhat deeper into my memory, I think it just so happened that
> > there was a keyboard with a key with a pictogram of a computer screen on
> > it with no really defined purpose. Since at that time there was only a
> > limited number of different extended keyboard types, it was added.
> >
> > I think it'd make sense to use it eg. for the key that switches between
> > internal and external output on laptops, if the laptop generates a
> > keycode for the key at all. But maybe that function is already taken by
> > KEY_SWITCHVIDEOMODE ...
>
> Ok, so let me summarize:
>
> There are two kinds of keys on those laptops (for which we are not sure
> about the keycode that it should generate):
> * Laptop screen on/off
> * Display output selection (for instance: laptop/external/both)
>
> The possible keycodes that we could assign to them:
> KEY_SCREEN
> KEY_MEDIA
> KEY_MODE
> KEY_VIDEO
> KEY_SWITCHVIDEOMODE
> KEY_COMPUTER
> KEY_PC
>
>  From the discussion, I had the feeling this association would be the
> less incorrect:
> Screen on/off : KEY_SCREEN

It looks like DVB folks chose to ise KEY_SCREEN and KEY_WINDOW to
switch applications between full screen and windowed modes so we'll
have to invent our own keycode. KEY_DISPLAYTOGGLE anyone?

> Display selection : KEY_SWITCHVIDEOMODE
>

I agree here.

-- 
Dmitry

Re: [PATCH 0/2] wistron_btns: More keymaps

[Éric Piel]

19.03.2007 22:28, Dmitry Torokhov wrote/a écrit:
> On 3/15/07, Éric Piel <Eric.Piel@tremplin-utc.net> wrote:
>>
>> Ok, so let me summarize:
>>
>> There are two kinds of keys on those laptops (for which we are not sure
>> about the keycode that it should generate):
>> * Laptop screen on/off
>> * Display output selection (for instance: laptop/external/both)
>>
>> The possible keycodes that we could assign to them:
>> KEY_SCREEN
>> KEY_MEDIA
>> KEY_MODE
>> KEY_VIDEO
>> KEY_SWITCHVIDEOMODE
>> KEY_COMPUTER
>> KEY_PC
>>
>>  From the discussion, I had the feeling this association would be the
>> less incorrect:
>> Screen on/off : KEY_SCREEN
> 
> It looks like DVB folks chose to ise KEY_SCREEN and KEY_WINDOW to
> switch applications between full screen and windowed modes
Just for info, I couldn't find any reference to KEY_WINDOW. Anyway, 
indeed, KEY_SCREEN is already used for "full screen" (although sometimes 
it's KEY_ZOOM :-/) so better not using it if something else is possible.

> so we'll
> have to invent our own keycode. KEY_DISPLAYTOGGLE anyone?
What about KEY_DISPLAYONOFF ? :-)
What should be its value? Would 239 be fine?

>> Display selection : KEY_SWITCHVIDEOMODE
> I agree here. 

BTW, I'm thinking of implementing led support. However, there are two 
mechanisms for leds in the kernel: the "input layer" leds and the "full 
feature" leds. The laptops may have up to three leds: mail, wifi, 
bluetooth. The input layer has LED_MAIL but no wifi nor bluetooth. The 
led subsystem has the advantage of the very extensible "trigger" 
mechanism. Which of the subsystems would you recommend me to use?

See you,
Eric