[PATCH 1/2] eeepc-wmi: add additional hotkeys

[PATCH 1/2] eeepc-wmi: add additional hotkeys

[chris]

From: Chris Bagwell <chris@cnpbagwell.com>

Added 4 hotkeys using same keymap values as eeepc-latop.
These are mousepad toggle, resolution change, screen off,
and task manager.  These were tested on 1005PE and are the
Fn-F3, F4, F7, and F9, respectively.

Also, added a new hot key for power toggles (Fn-Space on 1005PE)
and is meant to drive cpufv interface from userspace.

Finally, added several keys to be ignored that are being emitted
but do not mapped to any useful or documented hotkeys.  This is
purely cosmetic to prevent uknown key reports on console/log files.
These keys are reported on 1005PE's.

Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
---
 drivers/platform/x86/eeepc-wmi.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 9dc50fb..441b000 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -60,6 +60,10 @@ MODULE_ALIAS("wmi:"EEEPC_WMI_MGMT_GUID);
 
 #define EEEPC_WMI_DEVID_BACKLIGHT	0x00050012
 
+/* Keys marked with KE_IGNORE and KEY_RESERVE are keys known to
+ * not be useful to userspace and prevents printing to console
+ * about unknown key received.
+ */
 static const struct key_entry eeepc_wmi_keymap[] = {
 	/* Sleep already handled via generic ACPI code */
 	{ KE_KEY, 0x5d, { KEY_WLAN } },
@@ -69,6 +73,17 @@ static const struct key_entry eeepc_wmi_keymap[] = {
 	{ KE_IGNORE, NOTIFY_BRNDOWN_MIN, { KEY_BRIGHTNESSDOWN } },
 	{ KE_IGNORE, NOTIFY_BRNUP_MIN, { KEY_BRIGHTNESSUP } },
 	{ KE_KEY, 0xcc, { KEY_SWITCHVIDEOMODE } },
+	{ KE_KEY, 0x6b, { KEY_F13 } }, /* Disable Touchpad */
+	{ KE_KEY, 0xe1, { KEY_F14 } },
+	{ KE_KEY, 0xe9, { KEY_DISPLAY_OFF } },
+	{ KE_KEY, 0xe0, { KEY_PROG1 } },
+	{ KE_KEY, 0x5c, { KEY_F15 } },
+	{ KE_IGNORE, 0x83, { KEY_RESERVED } },
+	{ KE_IGNORE, 0xeb, { KEY_RESERVED } },
+	{ KE_IGNORE, 0xec, { KEY_RESERVED } },
+	{ KE_IGNORE, 0xed, { KEY_RESERVED } },
+	{ KE_IGNORE, 0xee, { KEY_RESERVED } },
+	{ KE_IGNORE, 0xef, { KEY_RESERVED } },
 	{ KE_END, 0},
 };
 
-- 
1.7.3.1

[PATCH 2/2] eeepc-wmi: Add cpufv sysfs interface

[chris]

From: Chris Bagwell <chris@cnpbagwell.com>

eeepc-laptop provides a sysfs interface to read and control what it
calls cpufv.  When WMI is enabled, the ACPI interface changes slightly
and becames a write-only control with only 3 valid values.

Write-only is OK because same DSDT's will ignore duplicate values
and even invalid values will be treated same as "0" value.

Expose cpufv again to allow for user space utils that can extended battery
life noticably and come a little closer to parity with eeepc-laptop.

This was tested with EEE PC 1005PE by monitoring powertop output while
writing values of "0", "1", and "2" and by reviewing the decompiled DSDT of
an 1201NL and comparing it to 1005PE's DSDT.

Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
---
 drivers/platform/x86/eeepc-wmi.c |   51 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index 441b000..988b16c 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -57,6 +57,7 @@ MODULE_ALIAS("wmi:"EEEPC_WMI_MGMT_GUID);
 
 #define EEEPC_WMI_METHODID_DEVS	0x53564544
 #define EEEPC_WMI_METHODID_DSTS	0x53544344
+#define EEEPC_WMI_METHODID_CFVS	0x53564643
 
 #define EEEPC_WMI_DEVID_BACKLIGHT	0x00050012
 
@@ -307,6 +308,49 @@ static void eeepc_wmi_notify(u32 value, void *context)
 	kfree(obj);
 }
 
+static int store_cpufv(struct device *dev, struct device_attribute *attr,
+		       const char *buf, size_t count)
+{
+	int value;
+	struct acpi_buffer input = { (acpi_size)sizeof(value), &value };
+	acpi_status status;
+
+	if (!count || sscanf(buf, "%i", &value) != 1)
+		return -EINVAL;
+	if (value < 0 || value > 2)
+		return -EINVAL;
+
+	status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
+				     1, EEEPC_WMI_METHODID_CFVS, &input, NULL);
+
+	if (ACPI_FAILURE(status))
+		return -EIO;
+	else
+		return count;
+}
+
+static DEVICE_ATTR(cpufv, S_IRUGO | S_IWUSR, NULL, store_cpufv);
+
+static void eeepc_wmi_sysfs_exit(struct platform_device *device)
+{
+	device_remove_file(&device->dev, &dev_attr_cpufv);
+}
+
+static int eeepc_wmi_sysfs_init(struct platform_device *device)
+{
+	int retval = -ENOMEM;
+
+	retval = device_create_file(&device->dev, &dev_attr_cpufv);
+	if (retval)
+		goto error_sysfs;
+
+	return 0;
+
+error_sysfs:
+	eeepc_wmi_sysfs_exit(platform_device);
+	return retval;
+}
+
 static int __devinit eeepc_wmi_platform_probe(struct platform_device *device)
 {
 	struct eeepc_wmi *eeepc;
@@ -402,8 +446,14 @@ static int __init eeepc_wmi_init(void)
 		goto del_dev;
 	}
 
+	err = eeepc_wmi_sysfs_init(platform_device);
+	if (err)
+		goto del_sysfs;
+
 	return 0;
 
+del_sysfs:
+	eeepc_wmi_sysfs_exit(platform_device);
 del_dev:
 	platform_device_del(platform_device);
 put_dev:
@@ -418,6 +468,7 @@ static void __exit eeepc_wmi_exit(void)
 {
 	struct eeepc_wmi *eeepc;
 
+	eeepc_wmi_sysfs_exit(platform_device);
 	eeepc = platform_get_drvdata(platform_device);
 	platform_driver_unregister(&platform_driver);
 	platform_device_unregister(platform_device);
-- 
1.7.3.1

Re: [PATCH 2/2] eeepc-wmi: Add cpufv sysfs interface

[Corentin Chary]

On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
> From: Chris Bagwell <chris@cnpbagwell.com>
>
> eeepc-laptop provides a sysfs interface to read and control what it
> calls cpufv.  When WMI is enabled, the ACPI interface changes slightly
> and becames a write-only control with only 3 valid values.
>
> Write-only is OK because same DSDT's will ignore duplicate values
> and even invalid values will be treated same as "0" value.
>
> Expose cpufv again to allow for user space utils that can extended battery
> life noticably and come a little closer to parity with eeepc-laptop.
>
> This was tested with EEE PC 1005PE by monitoring powertop output while
> writing values of "0", "1", and "2" and by reviewing the decompiled DSDT of
> an 1201NL and comparing it to 1005PE's DSDT.
>
> Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
> ---
>  drivers/platform/x86/eeepc-wmi.c |   51 ++++++++++++++++++++++++++++++++++++++
>  1 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
> index 441b000..988b16c 100644
> --- a/drivers/platform/x86/eeepc-wmi.c
> +++ b/drivers/platform/x86/eeepc-wmi.c
> @@ -57,6 +57,7 @@ MODULE_ALIAS("wmi:"EEEPC_WMI_MGMT_GUID);
>
>  #define EEEPC_WMI_METHODID_DEVS        0x53564544
>  #define EEEPC_WMI_METHODID_DSTS        0x53544344
> +#define EEEPC_WMI_METHODID_CFVS        0x53564643
>
>  #define EEEPC_WMI_DEVID_BACKLIGHT      0x00050012
>
> @@ -307,6 +308,49 @@ static void eeepc_wmi_notify(u32 value, void *context)
>        kfree(obj);
>  }
>
> +static int store_cpufv(struct device *dev, struct device_attribute *attr,
> +                      const char *buf, size_t count)
> +{
> +       int value;
> +       struct acpi_buffer input = { (acpi_size)sizeof(value), &value };
> +       acpi_status status;
> +
> +       if (!count || sscanf(buf, "%i", &value) != 1)
> +               return -EINVAL;
> +       if (value < 0 || value > 2)
> +               return -EINVAL;
> +
> +       status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
> +                                    1, EEEPC_WMI_METHODID_CFVS, &input, NULL);
> +
> +       if (ACPI_FAILURE(status))
> +               return -EIO;
> +       else
> +               return count;
> +}
> +
> +static DEVICE_ATTR(cpufv, S_IRUGO | S_IWUSR, NULL, store_cpufv);
> +
> +static void eeepc_wmi_sysfs_exit(struct platform_device *device)
> +{
> +       device_remove_file(&device->dev, &dev_attr_cpufv);
> +}
> +
> +static int eeepc_wmi_sysfs_init(struct platform_device *device)
> +{
> +       int retval = -ENOMEM;
> +
> +       retval = device_create_file(&device->dev, &dev_attr_cpufv);
> +       if (retval)
> +               goto error_sysfs;
> +
> +       return 0;
> +
> +error_sysfs:
> +       eeepc_wmi_sysfs_exit(platform_device);
> +       return retval;
> +}
> +
>  static int __devinit eeepc_wmi_platform_probe(struct platform_device *device)
>  {
>        struct eeepc_wmi *eeepc;
> @@ -402,8 +446,14 @@ static int __init eeepc_wmi_init(void)
>                goto del_dev;
>        }
>
> +       err = eeepc_wmi_sysfs_init(platform_device);
> +       if (err)
> +               goto del_sysfs;
> +
>        return 0;
>
> +del_sysfs:
> +       eeepc_wmi_sysfs_exit(platform_device);
>  del_dev:
>        platform_device_del(platform_device);
>  put_dev:
> @@ -418,6 +468,7 @@ static void __exit eeepc_wmi_exit(void)
>  {
>        struct eeepc_wmi *eeepc;
>
> +       eeepc_wmi_sysfs_exit(platform_device);
>        eeepc = platform_get_drvdata(platform_device);
>        platform_driver_unregister(&platform_driver);
>        platform_device_unregister(platform_device);
> --
> 1.7.3.1
>

Seems ok, too bad they don't provide a way to guess the current
configuration and the number of available settings. Especially when
all they do is calling the old device.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 2/2] eeepc-wmi: Add cpufv sysfs interface

[Chris Bagwell]

On Mon, Oct 11, 2010 at 1:44 AM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
>> From: Chris Bagwell <chris@cnpbagwell.com>
>>
>> eeepc-laptop provides a sysfs interface to read and control what it
>> calls cpufv.  When WMI is enabled, the ACPI interface changes slightly
>> and becames a write-only control with only 3 valid values.
>>
>> Write-only is OK because same DSDT's will ignore duplicate values
>> and even invalid values will be treated same as "0" value.
>>
>> Expose cpufv again to allow for user space utils that can extended battery
>> life noticably and come a little closer to parity with eeepc-laptop.
>>
>> This was tested with EEE PC 1005PE by monitoring powertop output while
>> writing values of "0", "1", and "2" and by reviewing the decompiled DSDT of
>> an 1201NL and comparing it to 1005PE's DSDT.
>>
>> Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
>> ---
>>  drivers/platform/x86/eeepc-wmi.c |   51 ++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 51 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
>> index 441b000..988b16c 100644
>> --- a/drivers/platform/x86/eeepc-wmi.c
>> +++ b/drivers/platform/x86/eeepc-wmi.c
>> @@ -57,6 +57,7 @@ MODULE_ALIAS("wmi:"EEEPC_WMI_MGMT_GUID);
>>
>>  #define EEEPC_WMI_METHODID_DEVS        0x53564544
>>  #define EEEPC_WMI_METHODID_DSTS        0x53544344
>> +#define EEEPC_WMI_METHODID_CFVS        0x53564643
>>
>>  #define EEEPC_WMI_DEVID_BACKLIGHT      0x00050012
>>
>> @@ -307,6 +308,49 @@ static void eeepc_wmi_notify(u32 value, void *context)
>>        kfree(obj);
>>  }
>>
>> +static int store_cpufv(struct device *dev, struct device_attribute *attr,
>> +                      const char *buf, size_t count)
>> +{
>> +       int value;
>> +       struct acpi_buffer input = { (acpi_size)sizeof(value), &value };
>> +       acpi_status status;
>> +
>> +       if (!count || sscanf(buf, "%i", &value) != 1)
>> +               return -EINVAL;
>> +       if (value < 0 || value > 2)
>> +               return -EINVAL;
>> +
>> +       status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
>> +                                    1, EEEPC_WMI_METHODID_CFVS, &input, NULL);
>> +
>> +       if (ACPI_FAILURE(status))
>> +               return -EIO;
>> +       else
>> +               return count;
>> +}
>> +
>> +static DEVICE_ATTR(cpufv, S_IRUGO | S_IWUSR, NULL, store_cpufv);
>> +
>> +static void eeepc_wmi_sysfs_exit(struct platform_device *device)
>> +{
>> +       device_remove_file(&device->dev, &dev_attr_cpufv);
>> +}
>> +
>> +static int eeepc_wmi_sysfs_init(struct platform_device *device)
>> +{
>> +       int retval = -ENOMEM;
>> +
>> +       retval = device_create_file(&device->dev, &dev_attr_cpufv);
>> +       if (retval)
>> +               goto error_sysfs;
>> +
>> +       return 0;
>> +
>> +error_sysfs:
>> +       eeepc_wmi_sysfs_exit(platform_device);
>> +       return retval;
>> +}
>> +
>>  static int __devinit eeepc_wmi_platform_probe(struct platform_device *device)
>>  {
>>        struct eeepc_wmi *eeepc;
>> @@ -402,8 +446,14 @@ static int __init eeepc_wmi_init(void)
>>                goto del_dev;
>>        }
>>
>> +       err = eeepc_wmi_sysfs_init(platform_device);
>> +       if (err)
>> +               goto del_sysfs;
>> +
>>        return 0;
>>
>> +del_sysfs:
>> +       eeepc_wmi_sysfs_exit(platform_device);
>>  del_dev:
>>        platform_device_del(platform_device);
>>  put_dev:
>> @@ -418,6 +468,7 @@ static void __exit eeepc_wmi_exit(void)
>>  {
>>        struct eeepc_wmi *eeepc;
>>
>> +       eeepc_wmi_sysfs_exit(platform_device);
>>        eeepc = platform_get_drvdata(platform_device);
>>        platform_driver_unregister(&platform_driver);
>>        platform_device_unregister(platform_device);
>> --
>> 1.7.3.1
>>
>
> Seems ok, too bad they don't provide a way to guess the current
> configuration and the number of available settings. Especially when
> all they do is calling the old device.
>

Agree.  But its probably not to bad in real life.  I have some scripts
that monitor dbus and update cpufv based on switching between
batter/ac and powerup.  With eeepc-laptop interface, it does read
previous state to prevent unneeded write but other then that it didn't
seem to useful to read it.  Since acpi is doing same compare logic,
always writing at important transition seems simplest approach for
userland anyways.

Chris

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Corentin Chary]

On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
> From: Chris Bagwell <chris@cnpbagwell.com>
>
> Added 4 hotkeys using same keymap values as eeepc-latop.
> These are mousepad toggle, resolution change, screen off,
> and task manager.  These were tested on 1005PE and are the
> Fn-F3, F4, F7, and F9, respectively.
>
> Also, added a new hot key for power toggles (Fn-Space on 1005PE)
> and is meant to drive cpufv interface from userspace.
>
> Finally, added several keys to be ignored that are being emitted
> but do not mapped to any useful or documented hotkeys.  This is
> purely cosmetic to prevent uknown key reports on console/log files.
> These keys are reported on 1005PE's.

What are exactly these keys ? Since they are probably some obscure Fn+ combo,
and they are probably used on another model, I'm not sure we should hide them.

I'm still not happy with F13 for "disable touchpad" but I did the same
for other laptops,
and we don't have a key for that ATM.

Otherwise, looks good.

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Chris Bagwell]

On Mon, Oct 11, 2010 at 1:26 AM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
>> From: Chris Bagwell <chris@cnpbagwell.com>
>>
>> Added 4 hotkeys using same keymap values as eeepc-latop.
>> These are mousepad toggle, resolution change, screen off,
>> and task manager.  These were tested on 1005PE and are the
>> Fn-F3, F4, F7, and F9, respectively.
>>
>> Also, added a new hot key for power toggles (Fn-Space on 1005PE)
>> and is meant to drive cpufv interface from userspace.
>>
>> Finally, added several keys to be ignored that are being emitted
>> but do not mapped to any useful or documented hotkeys.  This is
>> purely cosmetic to prevent uknown key reports on console/log files.
>> These keys are reported on 1005PE's.
>
> What are exactly these keys ? Since they are probably some obscure Fn+ combo,
> and they are probably used on another model, I'm not sure we should hide them.

They are Fn-1, 2, s, d, f, and e.  I can't really guess what 1 and 2
are for but I assume sdfe are arrow keys or something similar on
larger models?

I debated on if to add ignores since surely some model uses them but I
settled on someone else can modify current file instead of adding new
lines once they are driven to add their laptop specific keys.

>
> I'm still not happy with F13 for "disable touchpad" but I did the same
> for other laptops,
> and we don't have a key for that ATM.

And user land doesn't seem very supported of this concept at the
moment as well.  I've tried some xinput stuff on touchpad tied to F13
but no luck so far.  It does have a property to disable touchpad but
I've not had time to fully debug yet.  I'm trying to stay away fo
synclient since thats end-of-lifed.

>
> Otherwise, looks good.

Thanks.  BTW, please let me know specifically if you'd like the ignore
keys removed and I'll re-send a patch.  I don't have enough info to be
able to map them though.

Chris

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Corentin Chary]

On Mon, Oct 11, 2010 at 3:25 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> On Mon, Oct 11, 2010 at 1:26 AM, Corentin Chary
> <corentin.chary@gmail.com> wrote:
>> On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
>>> From: Chris Bagwell <chris@cnpbagwell.com>
>>>
>>> Added 4 hotkeys using same keymap values as eeepc-latop.
>>> These are mousepad toggle, resolution change, screen off,
>>> and task manager.  These were tested on 1005PE and are the
>>> Fn-F3, F4, F7, and F9, respectively.
>>>
>>> Also, added a new hot key for power toggles (Fn-Space on 1005PE)
>>> and is meant to drive cpufv interface from userspace.
>>>
>>> Finally, added several keys to be ignored that are being emitted
>>> but do not mapped to any useful or documented hotkeys.  This is
>>> purely cosmetic to prevent uknown key reports on console/log files.
>>> These keys are reported on 1005PE's.
>>
>> What are exactly these keys ? Since they are probably some obscure Fn+ combo,
>> and they are probably used on another model, I'm not sure we should hide them.
>
> They are Fn-1, 2, s, d, f, and e.  I can't really guess what 1 and 2
> are for but I assume sdfe are arrow keys or something similar on
> larger models?
>
> I debated on if to add ignores since surely some model uses them but I
> settled on someone else can modify current file instead of adding new
> lines once they are driven to add their laptop specific keys.
>
>>
>> I'm still not happy with F13 for "disable touchpad" but I did the same
>> for other laptops,
>> and we don't have a key for that ATM.
>
> And user land doesn't seem very supported of this concept at the
> moment as well.  I've tried some xinput stuff on touchpad tied to F13
> but no luck so far.  It does have a property to disable touchpad but
> I've not had time to fully debug yet.  I'm trying to stay away fo
> synclient since thats end-of-lifed.
>
>>
>> Otherwise, looks good.
>
> Thanks.  BTW, please let me know specifically if you'd like the ignore
> keys removed and I'll re-send a patch.  I don't have enough info to be
> able to map them though.

I'd remove them, and wait for someone to complain that he has garbage
in dmesg or unmapped keys.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Dmitry Torokhov]

On Sunday, October 10, 2010 11:26:22 pm Corentin Chary wrote:
> On Mon, Oct 11, 2010 at 3:48 AM,  <chris-ZCD0YumhXB+iMFqZbmIluw@public.gmane.org> wrote:
> > From: Chris Bagwell <chris-ZCD0YumhXB+iMFqZbmIluw@public.gmane.org>
> > 
> > Added 4 hotkeys using same keymap values as eeepc-latop.
> > These are mousepad toggle, resolution change, screen off,
> > and task manager.  These were tested on 1005PE and are the
> > Fn-F3, F4, F7, and F9, respectively.
> > 
> > Also, added a new hot key for power toggles (Fn-Space on 1005PE)
> > and is meant to drive cpufv interface from userspace.
> > 
> > Finally, added several keys to be ignored that are being emitted
> > but do not mapped to any useful or documented hotkeys.  This is
> > purely cosmetic to prevent uknown key reports on console/log files.
> > These keys are reported on 1005PE's.
> 
> What are exactly these keys ? Since they are probably some obscure Fn+
> combo, and they are probably used on another model, I'm not sure we should
> hide them.
> 
> I'm still not happy with F13 for "disable touchpad" but I did the same
> for other laptops,
> and we don't have a key for that ATM.

The most sensible way would be to add one then. We just need to decide if
it should be a key or a switch.

-- 
Dmitry

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Chris Bagwell]

On Mon, Oct 11, 2010 at 12:10 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sunday, October 10, 2010 11:26:22 pm Corentin Chary wrote:
>> On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
>> > From: Chris Bagwell <chris@cnpbagwell.com>
>> >
>> > Added 4 hotkeys using same keymap values as eeepc-latop.
>> > These are mousepad toggle, resolution change, screen off,
>> > and task manager.  These were tested on 1005PE and are the
>> > Fn-F3, F4, F7, and F9, respectively.
>> >
>> > Also, added a new hot key for power toggles (Fn-Space on 1005PE)
>> > and is meant to drive cpufv interface from userspace.
>> >
>> > Finally, added several keys to be ignored that are being emitted
>> > but do not mapped to any useful or documented hotkeys.  This is
>> > purely cosmetic to prevent uknown key reports on console/log files.
>> > These keys are reported on 1005PE's.
>>
>> What are exactly these keys ? Since they are probably some obscure Fn+
>> combo, and they are probably used on another model, I'm not sure we should
>> hide them.
>>
>> I'm still not happy with F13 for "disable touchpad" but I did the same
>> for other laptops,
>> and we don't have a key for that ATM.
>
> The most sensible way would be to add one then. We just need to decide if
> it should be a key or a switch.
>

Motivated by thread on linux-input "Touchpad toggle mess", I changed
Fn-F3(toggle touchpad) from KEY_F13 to KEY_F22  With Gnome 2.32
(Fedora 14), now magically my touchpad toggle works automagically.

So I'd like to submit a patch to change both eeepc-laptop and
eeepc-wmi to use KEY_F22 for toggle touchpad to get some immediate
benifit.  Any issues with this?  Is F13 doing anything useful by
default?

I know in this thread and in other thread Dmitry mentioned we should
make a KEY_TOUCHPAD_TOGGLE (or whatever name).  I'm probably just
smart enough to do that if preferred but don't think I'd be able to
take it to the next level and get it translated to
XF86XK_TouchpadToggle.  Help appreciate in that area.

Chris

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Corentin Chary]

On Sat, Nov 6, 2010 at 4:02 AM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> On Mon, Oct 11, 2010 at 12:10 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> On Sunday, October 10, 2010 11:26:22 pm Corentin Chary wrote:
>>> On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
>>> > From: Chris Bagwell <chris@cnpbagwell.com>
>>> >
>>> > Added 4 hotkeys using same keymap values as eeepc-latop.
>>> > These are mousepad toggle, resolution change, screen off,
>>> > and task manager.  These were tested on 1005PE and are the
>>> > Fn-F3, F4, F7, and F9, respectively.
>>> >
>>> > Also, added a new hot key for power toggles (Fn-Space on 1005PE)
>>> > and is meant to drive cpufv interface from userspace.
>>> >
>>> > Finally, added several keys to be ignored that are being emitted
>>> > but do not mapped to any useful or documented hotkeys.  This is
>>> > purely cosmetic to prevent uknown key reports on console/log files.
>>> > These keys are reported on 1005PE's.
>>>
>>> What are exactly these keys ? Since they are probably some obscure Fn+
>>> combo, and they are probably used on another model, I'm not sure we should
>>> hide them.
>>>
>>> I'm still not happy with F13 for "disable touchpad" but I did the same
>>> for other laptops,
>>> and we don't have a key for that ATM.
>>
>> The most sensible way would be to add one then. We just need to decide if
>> it should be a key or a switch.
>>
>
> Motivated by thread on linux-input "Touchpad toggle mess", I changed
> Fn-F3(toggle touchpad) from KEY_F13 to KEY_F22  With Gnome 2.32
> (Fedora 14), now magically my touchpad toggle works automagically.
>
> So I'd like to submit a patch to change both eeepc-laptop and
> eeepc-wmi to use KEY_F22 for toggle touchpad to get some immediate
> benifit.  Any issues with this?  Is F13 doing anything useful by
> default?
>
> I know in this thread and in other thread Dmitry mentioned we should
> make a KEY_TOUCHPAD_TOGGLE (or whatever name).  I'm probably just
> smart enough to do that if preferred but don't think I'd be able to
> take it to the next level and get it translated to
> XF86XK_TouchpadToggle.  Help appreciate in that area.
>
> Chris
>

Hi Chris,
Since 2.6.38 merge window should be in a long time, I think we have
the time to ad new keys.

Dimitry, what do you think of :

KEY_TOUCHPAD_TOGGLE 248
KEY_TOUCHPAD_ON            249
KEY_TOUCHPAD_OFF           250

Maybe we should keep these lower keycodes for other stuff, and use
some higher ones ?

Thanks,

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 1/2] eeepc-wmi: add additional hotkeys

[Dmitry Torokhov]

On Sat, Nov 06, 2010 at 08:42:52AM +0100, Corentin Chary wrote:
> On Sat, Nov 6, 2010 at 4:02 AM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> > On Mon, Oct 11, 2010 at 12:10 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> >> On Sunday, October 10, 2010 11:26:22 pm Corentin Chary wrote:
> >>> On Mon, Oct 11, 2010 at 3:48 AM,  <chris@cnpbagwell.com> wrote:
> >>> > From: Chris Bagwell <chris@cnpbagwell.com>
> >>> >
> >>> > Added 4 hotkeys using same keymap values as eeepc-latop.
> >>> > These are mousepad toggle, resolution change, screen off,
> >>> > and task manager.  These were tested on 1005PE and are the
> >>> > Fn-F3, F4, F7, and F9, respectively.
> >>> >
> >>> > Also, added a new hot key for power toggles (Fn-Space on 1005PE)
> >>> > and is meant to drive cpufv interface from userspace.
> >>> >
> >>> > Finally, added several keys to be ignored that are being emitted
> >>> > but do not mapped to any useful or documented hotkeys.  This is
> >>> > purely cosmetic to prevent uknown key reports on console/log files.
> >>> > These keys are reported on 1005PE's.
> >>>
> >>> What are exactly these keys ? Since they are probably some obscure Fn+
> >>> combo, and they are probably used on another model, I'm not sure we should
> >>> hide them.
> >>>
> >>> I'm still not happy with F13 for "disable touchpad" but I did the same
> >>> for other laptops,
> >>> and we don't have a key for that ATM.
> >>
> >> The most sensible way would be to add one then. We just need to decide if
> >> it should be a key or a switch.
> >>
> >
> > Motivated by thread on linux-input "Touchpad toggle mess", I changed
> > Fn-F3(toggle touchpad) from KEY_F13 to KEY_F22  With Gnome 2.32
> > (Fedora 14), now magically my touchpad toggle works automagically.
> >
> > So I'd like to submit a patch to change both eeepc-laptop and
> > eeepc-wmi to use KEY_F22 for toggle touchpad to get some immediate
> > benifit.  Any issues with this?  Is F13 doing anything useful by
> > default?
> >
> > I know in this thread and in other thread Dmitry mentioned we should
> > make a KEY_TOUCHPAD_TOGGLE (or whatever name).  I'm probably just
> > smart enough to do that if preferred but don't think I'd be able to
> > take it to the next level and get it translated to
> > XF86XK_TouchpadToggle.  Help appreciate in that area.
> >
> > Chris
> >
> 
> Hi Chris,
> Since 2.6.38 merge window should be in a long time, I think we have
> the time to ad new keys.
> 
> Dimitry, what do you think of :
> 
> KEY_TOUCHPAD_TOGGLE 248
> KEY_TOUCHPAD_ON            249
> KEY_TOUCHPAD_OFF           250
> 
> Maybe we should keep these lower keycodes for other stuff, and use
> some higher ones ?
> 

I think we should move them up. Bastien mentioned that X already
standardized on F21, 22 and 23 so they will need to remap anyways, thus
we'll be "wasting" valuable lower scancode estate if we do it this way.

The only thing that is left is to feed udev guys with keymaps till X is
able to take the full scancode trange.

Thanks.

-- 
Dmitry