RE: [PATCH 2/2] CHROMIUM: elants_i2c.c: Disable idle mode before firmware upgrade procedure.
Dear Dmitry:
We need to correct the value of sending fastboot or IAP command is 100msec
not 40 msec.
The firmware of all of volume-productions are used 100msec instead of
40msec.
And I will correct the comment.
James
-Original Message-
From: linux-input-ow...@vger.kernel.org
[mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov
Sent: Friday, July 24, 2015 6:17 AM
To: james.chen
Cc: Herman Lin; linux-input@vger.kernel.org; charliemoo...@chromium.org
Subject: Re: [PATCH 2/2] CHROMIUM: elants_i2c.c: Disable idle mode before
firmware upgrade procedure.
Hi James,
On Tue, Jul 21, 2015 at 10:10:25AM +0800, james.chen wrote:
From: james.chen james.c...@emc.com.tw
This patch is disable idle mode before firmware upgrade procedure.
BUG=chrome-os-partner:39373
TEST= Test Elan touchscreen on cyan project(kernel 3.18) without problems.
Signed-off-by: james.chen james.c...@emc.com.tw
---
drivers/input/touchscreen/elants_i2c.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index 0efd766..6d3570e 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -605,6 +605,7 @@ static int elants_i2c_do_update_firmware(struct
i2c_client *client,
const u8 enter_iap[] = { 0x45, 0x49, 0x41, 0x50 };
const u8 enter_iap2[] = { 0x54, 0x00, 0x12, 0x34 };
const u8 iap_ack[] = { 0x55, 0xaa, 0x33, 0xcc };
+ const u8 close_idle[] = {0x54, 0x2c, 0x01, 0x01};
u8 buf[HEADER_SIZE];
u16 send_id;
int page, n_fw_pages;
@@ -617,8 +618,13 @@ static int elants_i2c_do_update_firmware(struct
i2c_client *client,
} else {
/* Start IAP Procedure */
dev_dbg(client-dev, Normal IAP procedure\n);
+ /* Close idle mode */
+ error = elants_i2c_send(client, close_idle,
sizeof(close_idle));
+ if (error)
+ dev_err(client-dev, Failed close idle: %d\n,
error);
+ msleep(60);
elants_i2c_sw_reset(client);
-
+ msleep(20);
Are you sure that this delay is also needed? We have the following in
elants_i2c_sw_reset():
/*
* We should wait at least 10 msec (but no more than 40) before
* sending fastboot or IAP command to the device.
*/
msleep(30);
so additional 20 msec will push us out of the 40 msec window...
error = elants_i2c_send(client, enter_iap,
sizeof(enter_iap));
}
--
1.8.3.2
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] CHROMIUM: elants_i2c.c: Disable idle mode before firmware upgrade procedure.
Dear all:
Sorry for mistyped.
Please abandon this patch.
And review next patch as shown in below.
[PATCH 2/2] CHROMIUM: elants_i2c.c: Disable idle mode before firmware
upgrade procedure.
-Original Message-
From: linux-input-ow...@vger.kernel.org
[mailto:linux-input-ow...@vger.kernel.org] On Behalf Of james.chen
Sent: Tuesday, July 21, 2015 10:10 AM
To: Dmitry Torokhov; Herman Lin; linux-input@vger.kernel.org;
charliemoo...@chromium.org
Cc: james.chen
Subject: [PATCH] CHROMIUM: elants_i2c.c: Disable idle mode before firmware
upgrade procedure.
From: james.chen james.c...@emc.com.tw
This patch is disable idle mode before firmware upgrade procedure.
BUG=chrome-os-partner:39373
TEST= Test Elan touchscreen on cyan project(kernel 3.18) without problems.
---
drivers/input/touchscreen/elants_i2c.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index 0efd766..6d3570e 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -605,6 +605,7 @@ static int elants_i2c_do_update_firmware(struct
i2c_client *client,
const u8 enter_iap[] = { 0x45, 0x49, 0x41, 0x50 };
const u8 enter_iap2[] = { 0x54, 0x00, 0x12, 0x34 };
const u8 iap_ack[] = { 0x55, 0xaa, 0x33, 0xcc };
+ const u8 close_idle[] = {0x54, 0x2c, 0x01, 0x01};
u8 buf[HEADER_SIZE];
u16 send_id;
int page, n_fw_pages;
@@ -617,8 +618,13 @@ static int elants_i2c_do_update_firmware(struct
i2c_client *client,
} else {
/* Start IAP Procedure */
dev_dbg(client-dev, Normal IAP procedure\n);
+ /* Close idle mode */
+ error = elants_i2c_send(client, close_idle,
sizeof(close_idle));
+ if (error)
+ dev_err(client-dev, Failed close idle: %d\n,
error);
+ msleep(60);
elants_i2c_sw_reset(client);
-
+ msleep(20);
error = elants_i2c_send(client, enter_iap,
sizeof(enter_iap));
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] HID: hid-input: Simplify expression and suppress gcc warning
On Wed, May 27, 2015 at 07:17:17PM -0500, James C Boyd wrote: HID: hid-input: Add parenthesis to suppress gcc warning I suppose I should also mention that gcc-5.1 was reporting this dumb warning. I'll resend the patch set with that detail mentioned if you'd like. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] HID: hid-input: Simplify expression and suppress gcc warning
This patch set simplifies and formats an expression as well as suppress a gcc warning. James C Boyd (3): HID: hid-input: Add parenthesis to suppress gcc warning HID: hid-input: Simplified conditional expression HID: hid-input: Fix coding style issue drivers/hid/hid-input.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] HID: hid-input: Fix coding style issue
This line is too long; split it up. Signed-off-by: James C Boyd jcboyd@gmail.com --- drivers/hid/hid-input.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index abf4fc6..3511bbab 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1157,7 +1157,8 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct return; /* report the usage code as scancode if the key status has changed */ - if (usage-type == EV_KEY (!test_bit(usage-code, input-key)) == value) + if (usage-type == EV_KEY + (!test_bit(usage-code, input-key)) == value) input_event(input, EV_MSC, MSC_SCAN, usage-hid); input_event(input, usage-type, usage-code, value); -- -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] HID: hid-input: Simplify conditional expression
There are too many bangs in this conditional; therefore remove them while still maintaining the same logic. Signed-off-by: James C Boyd jcboyd@gmail.com --- drivers/hid/hid-input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c index 714b758..abf4fc6 100644 --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1157,7 +1157,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct return; /* report the usage code as scancode if the key status has changed */ - if (usage-type == EV_KEY (!!test_bit(usage-code, input-key)) != value) + if (usage-type == EV_KEY (!test_bit(usage-code, input-key)) == value) input_event(input, EV_MSC, MSC_SCAN, usage-hid); input_event(input, usage-type, usage-code, value); -- -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hid-lenovo-tpkbd unknown key/button events
My Lenovo ThinkPad Keyboard with TrackPoint reports two keys/buttons events which have no names in input.h. Event 282 (0x11A) is generated on the pointer devices via Fn-F9: Event: time 1402899841.080255, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90018 Event: time 1402899841.080255, type 1 (EV_KEY), code 282 (?), value 1 Event: time 1402899841.080255, -- SYN_REPORT Event: time 1402899841.176247, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90018 Event: time 1402899841.176247, type 1 (EV_KEY), code 282 (?), value 0 Event: time 1402899841.176247, -- SYN_REPORT I have not found how to generate event 286 (0x11E). Lenovo documents Fn-F9 on: http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-42883 as ThinkPad EasyEject Utility. Are there any other devices known to generate codes in the 0x118-0x11F range? Woulditbe beneficial to come up with names for them? -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [appleir] BUG: unable to handle kernel NULL pointer dereference
On Tue, Nov 19, 2013 at 10:33 PM, Jiri Kosina jkos...@suse.cz wrote: On Thu, 7 Nov 2013, Benjamin Tissoires wrote: [ adding some more CCs ] Okay, so apparently we didn't register with input, but only hiddev / hidraw. appleir 0003:05AC:8240.0005: hiddev0,hidraw4: USB HID v1.11 Device [Apple Computer, Inc. IR Receiver] on usb-:00:1d.3-2/input0 Therefore -input_configured() callback has never been called, and thus we oops due to appleir-input_dev being NULL when the first raw event is reported. Could you please provide report descriptor of the device? The driver apparently relies on it being registered with hid-input, but for some reason that doesn't happen. Here is the relevant lsusb output that I think contains what you're asking for (I had to unbind usbhid for it to include the descriptor): Bus 005 Device 003: ID 05ac:8240 Apple, Inc. Built-in IR Receiver Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 ... Ok, thanks for the report. Could you please test the following patch which should solve your problem (hopefully)? James, any reults from testing Benjamin's patch, please? Sorry for the delays in testing out the patch. I have tried a kernel with the patch applied, and can no longer reproduce the oops. The hid-appleir driver appears to be working correctly, generating key press events in response to the remote, and LIRC functions correctly via hiddev. Thanks for the everyone's help with this. James. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [appleir] BUG: unable to handle kernel NULL pointer dereference
On Wed, Nov 6, 2013 at 11:38 PM, Jiri Kosina jkos...@suse.cz wrote: On Tue, 29 Oct 2013, Luis Henriques wrote: James has reported a NULL pointer dereference[1] on the appleir driver. From the bug report[2] it looks like it is 100% reproducible using a 3.12-rc6 kernel simply by pressing any button on the IR remote. From the stack trace, it looks like input_event is invoked with the input_dev parameter set to NULL, which seems to indicate that appleir_input_configured is never invoked. Any ideas? [1] https://launchpadlibrarian.net/154942024/macmini-oops.jpg [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244505 [ adding some more CCs ] Okay, so apparently we didn't register with input, but only hiddev / hidraw. appleir 0003:05AC:8240.0005: hiddev0,hidraw4: USB HID v1.11 Device [Apple Computer, Inc. IR Receiver] on usb-:00:1d.3-2/input0 Therefore -input_configured() callback has never been called, and thus we oops due to appleir-input_dev being NULL when the first raw event is reported. Could you please provide report descriptor of the device? The driver apparently relies on it being registered with hid-input, but for some reason that doesn't happen. Here is the relevant lsusb output that I think contains what you're asking for (I had to unbind usbhid for it to include the descriptor): Bus 005 Device 003: ID 05ac:8240 Apple, Inc. Built-in IR Receiver Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x05ac Apple, Inc. idProduct 0x8240 Built-in IR Receiver bcdDevice1.10 iManufacturer 1 Apple Computer, Inc. iProduct2 IR Receiver iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 41 Report Descriptor: (length is 41) Item(Global): Usage Page, data= [ 0x00 0xff ] 65280 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x04 ] 4 Item(Global): Report ID, data= [ 0x24 ] 36 Item(Local ): Usage, data= [ 0x00 ] 0 (null) Item(Main ): Input, data= [ 0x22 ] 34 Data Variable Absolute No_Wrap Linear No_Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x04 ] 4 Item(Global): Report ID, data= [ 0x25 ] 37 Item(Local ): Usage, data= [ 0x00 ] 0 (null) Item(Main ): Input, data= [ 0x22 ] 34 Data Variable Absolute No_Wrap Linear No_Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x04 ] 4 Item(Global): Report ID, data= [ 0x26 ] 38 Item(Local ): Usage, data= [ 0x00 ] 0 (null) Item(Main ): Input, data= [ 0x22 ] 34 Data Variable Absolute No_Wrap Linear No_Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize
Re: Possible regression 3.8.7 - 3.9 with Dell touchpad
On 05/10/2013 03:39 PM, Tibor Billes wrote: From: Dmitry Torokhov Sent: 05/10/13 12:54 AM On Thu, May 09, 2013 at 10:59:58PM +0200, Tibor Billes wrote: Hi, I found that after upgrading my kernel from 3.8.7 to 3.9 my touchpad only works partly. By that I mean I can use the touchpad to move the cursor around, but I cannot click with it by tapping. Is the touchpad recognized as ALPS or PS/2 mouse in 3.8.7? Also, can you check that touchpad tapping is enabled in your desktop environment? In 3.8.7 it is recognized as PS/2 mouse and the desktop environment doesn't even offer any touchpad settings. In 3.9.1 the touchpad is recognized as 'AlpsPS/2 ALPS DualPoint TouchPad' and yes, the touchpad settings appeared, and yes, clicking was disabled. Enabled it, works like a charm :) So what happened is that the 3.8.7 kernel did not recognize my touchpad, so it fell back to PS/2 which worked well for me. The 3.9 kernel recongizes my touchpad correctly because Kevin updated the driver, and my system started using a different configuration as it knew it was a touchpad and not some PS/2 device. Am I right? I recall looking for touchpad settings in one of the 3.8.x kernels and I didn't find any so I didn't bother looking for it again in 3.9... In this case I'm sorry for the false report, and thank you guys for the driver update :) This sounds about right. I expect that if you enable tap to click in your settings (should be under Mouse and Touchpad if you're using gnome-control-center) you should be good. Thanks. My machine is a Dell Latitude E5530. Since it is 100% reproducible on my machine, I bisected it, and found this commit: commit 1302bac33d9e88cd43e482191a806998f3ed43cc Author: Kevin Cernekee cerne...@gmail.com Date: Wed Feb 13 22:27:08 2013 -0800 Input: ALPS - add support for Rushmore touchpads Rushmore touchpads are found on Dell E6230/E6430/E6530. They use the V3 protocol with slightly tweaked init sequences and report formats. The E7 report is 73 03 0a, and the EC report is 88 08 1d Credits: Emmanuel Thome reported the MT bitmap changes. Signed-off-by: Kevin Cernekee cerne...@gmail.com Tested-by: Dave Turvene dturv...@dahetral.com Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com I did the bisection between 3.8.7 and 3.9, but also tried 3.9.1, it is bad too. I also tried reverting that commit to make sure that it really is what made my touchpad not working. The revert did fix my problem. That's all I gathered so far, but I'd be happy to help further in any way I can, just let me know. Thanks, Tibor -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1][RESUBMIT] input: fix weird issue of synaptics psmouse sync lost
I meant to send this to linux-input On 04/09/2013 08:30 PM, James M Leddy wrote: We have been using this patch in Ubuntu kernels for 5 months now without issue. Since patch author Eric Miao no longer works for us, I'm sending to the list so that other distros can take advantage of this. Last we left off, the suggestion was to make this generic across the entire range of protocols, not just synaptics. I'm against this for two reasons. The first is that I don't want to have to ask for additional testing (I don't have access to the machine). The second and far more important reason is that I am afraid that this will break other non-synaptics touchpads, and even though we have a wide range of hardware, it is impossible to guarantee that it'll work on everything out there. I will do it however if it's the way we need to go with this. Please let me know what you think, or if you need any additional information or testing. James M Leddy (1): input: fix weird issue of synaptics psmouse sync lost after resume drivers/input/mouse/synaptics.c |2 ++ 1 file changed, 2 insertions(+) -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1][RESUBMIT] input: fix weird issue of synaptics psmouse sync lost after resume
From: Eric Miao eric.m...@canonical.com
In summary, the symptom is intermittent key events lost after resume
on some machines with synaptics touchpad (seems this is synaptics _only_),
and key events loss is due to serio port reconnect after psmouse sync lost.
Removing psmouse and inserting it back during the suspend/resume process
is able to work around the issue, so the difference between
psmouse_connect()
and psmouse_reconnect() is the key to the root cause of this problem.
After comparing the two different paths, synaptics driver has its own
implementation of synaptics_reconnect(), and the missing psmouse_probe()
seems significant, the patch below added psmouse_probe() to the reconnect
process, and has been verified many times that the issue could not be
reliably
reproduced.
There are two PS/2 commands in psmouse_probe():
1. PSMOUSE_CMD_GETID
2. PSMOUSE_CMD_RESET_DIS
Only the PSMOUSE_CMD_GETID seems to be significant. The
PSMOUSE_CMD_RESET_DIS is irrelevant to this issue after trying
several times. So we have only implemented this patch to issue
the PSMOUSE_CMD_GETID so far.
Tested-by: Daniel Manrique daniel.manri...@canonical.com
Signed-off-by: James M Leddy james.le...@canonical.com
---
drivers/input/mouse/synaptics.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c
b/drivers/input/mouse/synaptics.c
index 12d12ca..3438a9d 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1355,6 +1355,7 @@ static int synaptics_reconnect(struct psmouse
*psmouse)
{
struct synaptics_data *priv = psmouse-private;
struct synaptics_data old_priv = *priv;
+ unsigned char param[2];
int retry = 0;
int error;
@@ -1370,6 +1371,7 @@ static int synaptics_reconnect(struct psmouse
*psmouse)
*/
ssleep(1);
}
+ ps2_command(psmouse-ps2dev, param, PSMOUSE_CMD_GETID);
error = synaptics_detect(psmouse, 0);
} while (error ++retry 3);
-- 1.7.9.5
Re: [PATCH] Remap micmute to F20
On 08/28/2012 07:36 PM, Bastien Nocera wrote: Em Tue, 2012-08-28 às 19:32 -0400, James M Leddy escreveu: Because of a limitation of the X11 protocol, we can't use micmute in it's current mapping. I've chosen to map this to F20, since we do similar things with the touchpad buttons for the same reason. Whatever we use, we will have to agree with xkeyboard-config. http://lists.freedesktop.org/archives/xorg-devel/2012-August/033442.html Feel free to implement this once you're done :) https://bugzilla.gnome.org/show_bug.cgi?id=651051 Already ahead of you :) Just have to make sure the patch applies cleanly upstream. Thanks for the bug number. https://bazaar.launchpad.net/~jm-leddy/ubuntu/quantal/gnome-settings-daemon/micmute/view/head:/debian/patches/micmute.patch Cheers -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remap micmute to F20
On 08/29/2012 11:43 AM, James M Leddy wrote: On 08/28/2012 07:36 PM, Bastien Nocera wrote: Em Tue, 2012-08-28 às 19:32 -0400, James M Leddy escreveu: Because of a limitation of the X11 protocol, we can't use micmute in it's current mapping. I've chosen to map this to F20, since we do similar things with the touchpad buttons for the same reason. Whatever we use, we will have to agree with xkeyboard-config. http://lists.freedesktop.org/archives/xorg-devel/2012-August/033442.html Feel free to implement this once you're done :) https://bugzilla.gnome.org/show_bug.cgi?id=651051 Already ahead of you :) Just have to make sure the patch applies cleanly upstream. Thanks for the bug number. https://bazaar.launchpad.net/~jm-leddy/ubuntu/quantal/gnome-settings-daemon/micmute/view/head:/debian/patches/micmute.patch Just realized this is unity specific, I'll work on a gnome-shell version this week or next. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remap micmute to F20
Because of a limitation of the X11 protocol, we can't use micmute in it's current mapping. I've chosen to map this to F20, since we do similar things with the touchpad buttons for the same reason. Whatever we use, we will have to agree with xkeyboard-config. http://lists.freedesktop.org/archives/xorg-devel/2012-August/033442.html Signed-off-by: James M. Leddy james.le...@canonical.com --- keymaps/module-lenovo |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/keymaps/module-lenovo b/keymaps/module-lenovo index 8e38883..f94678d 100644 --- a/keymaps/module-lenovo +++ b/keymaps/module-lenovo @@ -14,4 +14,4 @@ 0x15 volumedown 0x16 mute 0x17 prog1 # ThinkPad/ThinkVantage button (high keycode: vendor) -0x1A micmute # Microphone mute +0x1A f20 # Microphone mute -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New Alps protocol in the wild?
I just got a Dell E6230 with the same E7 report: 73 03 0a
As noted above using the qemu serio logging doesn't work.
The driver only enables multitouch if it sees the right
name for the device in the DSDT.
The following patch (against the seabios in qemu-0.14.1)
enables the windows 7 driver (7.1211.101.114 from
http://www.dell.com/support/drivers/us/en/04/DriverDetails/DriverFileFormats/Product/latitude-e6230?DriverId=CKNFNFileId=2988050063urlProductCode=False
) to bind successfully and alows one to get data from the serio
logging patch
Are there any standard tools for reverse engineering the
protocol - I saw mention of an alps-reg-dump but was
unable to find it?
thanks,
James.
--- ./qemu-0.14.1/roms/seabios/src/acpi-dsdt.dsl2011-05-06
20:02:01.0 +0100
+++ ./qemu-0.14.1.jmm/roms/seabios/src/acpi-dsdt.dsl2012-08-14
11:09:22.0 +0100
@@ -253,7 +253,7 @@
}
/* Keyboard seems to be important for WinXP install */
-Device (KBD)
+Device (PS2K)
{
Name (_HID, EisaId (PNP0303))
Method (_STA, 0, NotSerialized)
@@ -261,10 +261,8 @@
Return (0x0f)
}
-Method (_CRS, 0, NotSerialized)
+ Name (_CRS, ResourceTemplate ()
{
- Name (TMP, ResourceTemplate ()
- {
IO (Decode16,
0x0060, // Address Range Minimum
0x0060, // Address Range Maximum
@@ -277,30 +275,52 @@
0x01, // Address Alignment
0x01, // Address Length
)
+IRQ (Edge, ActiveHigh, Exclusive, )
+{1}
+
+})
+
+
+
+
+Name (_PRS, ResourceTemplate ()
+{
+StartDependentFn (0x00, 0x00)
+{
+FixedIO (
+0x0060, // Address
+0x01, // Length
+)
+FixedIO (
+0x0064, // Address
+0x01, // Length
+)
IRQNoFlags ()
{1}
-})
-Return (TMP)
}
-}
+EndDependentFn ()
+})
+ }
/* PS/2 mouse */
-Device (MOU)
+Device (PS2M)
{
-Name (_HID, EisaId (PNP0F13))
-Method (_STA, 0, NotSerialized)
-{
-Return (0x0f)
-}
-
-Method (_CRS, 0, NotSerialized)
+Name (_CID, EisaId (PNP0F13))
+ Name (_HID, EisaId (DLL0532))
+Name (_CRS, ResourceTemplate ()
+{
+IRQ (Edge, ActiveHigh, Exclusive, )
+{12}
+})
+Name (_PRS, ResourceTemplate ()
+{
+StartDependentFn (0x00, 0x00)
{
-Name (TMP, ResourceTemplate ()
-{
- IRQNoFlags () {12}
-})
-Return (TMP)
+IRQNoFlags ()
+{12}
}
+EndDependentFn ()
+})
}
/* PS/2 floppy controller */
