Re: [PATCH] input: cros_ec_keyb_clear_keyboard() depends on CONFIG_PM_SLEEP
On Wed, May 08, 2013 at 09:25:56PM -0600, Simon Glass wrote: > On Wed, May 8, 2013 at 3:45 PM, Geert Uytterhoeven > wrote: > > If CONFIG_PM_SLEEP is not set: > > > > drivers/input/keyboard/cros_ec_keyb.c:211: warning: > > ‘cros_ec_keyb_clear_keyboard’ defined but not used > > > > Move the definition of cros_ec_keyb_clear_keyboard() inside the section > > protected by #ifdef CONFIG_PM_SLEEP to fix this. > > > > Signed-off-by: Geert Uytterhoeven > > Acked-by: Simon Glass Acked-by: Dmitry Torokhov Could you please forward this to Linus as I do not have this driver in my branch yet. 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
Re: [PATCH V2 0/5] input: pxa27x-keypad: enhancement and device tree support
Hi Chao, On Mon, May 13, 2013 at 04:02:07PM +0800, Chao Xie wrote: > hi, dmitry > What is your idea about these patches? > Do i need add someone else to review them? > No, they look good, give me a couple more days but I should apply them. I am going to fold the first 4 into one patch though. > On Mon, May 6, 2013 at 11:04 AM, Chao Xie wrote: > > The patches include 2 parts > > 1. use matrix_keypad for matrix keyes support > > 2. add device tree support for pxa27x-keypad > > > > V2->V1: > > Do not copy the members from pdata. For device tree support, > > directly allocate the pdata structure. > > > > Chao Xie (5): > > input: pxa27x-keypad: use matrix_keymap for matrix keyes > > arm: mmp: use matrix_keymap for aspenite > > arm: mmp: use matrix_keymap for teton_bga > > input: pxa27x-keypad: remove the unused members at platform data > > input: pxa27x-keypad: add device tree support > > > > .../devicetree/bindings/input/pxa27x-keypad.txt| 60 + > > arch/arm/mach-mmp/aspenite.c | 10 +- > > arch/arm/mach-mmp/teton_bga.c |8 +- > > drivers/input/keyboard/Kconfig |1 + > > drivers/input/keyboard/pxa27x_keypad.c | 266 > > ++-- > > include/linux/platform_data/keypad-pxa27x.h|3 +- > > 6 files changed, 325 insertions(+), 23 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/input/pxa27x-keypad.txt > > > > -- > > 1.7.4.1 > > -- 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
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 >>> 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 >>>Tested-by: Dave Turvene >>>Signed-off-by: Dmitry Torokhov >>> >>> 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
Support of Genius mouse with huge max_usage
Hi Jiri, I have a bug from an owner of a Gila mouse from Genius which I'm not sure how to handle it: https://bugzilla.redhat.com/show_bug.cgi?id=959721 The user gave me the hid-replay traces and within the first trace (the one from hidraw0), I can extract the culprit collection: 0x05, 0x0c,// Usage Page (Consumer Devices) 104 0x09, 0x01,// Usage (Consumer Control)106 0xa1, 0x01,// Collection (Application)108 0x85, 0x03,// Report ID (3) 110 0x19, 0x00,// Usage Minimum (0) 112 0x2a, 0xff, 0x7f, // Usage Maximum (32767) 114 0x15, 0x00,// Logical Minimum (0) 117 0x26, 0xff, 0x7f, // Logical Maximum (32767) 119 0x75, 0x10,// Report Size (16) 122 0x95, 0x03,// Report Count (3) 124 0x81, 0x00,// Input (Data,Arr,Abs) 126 0x75, 0x08,// Report Size (8) 128 0x95, 0x01,// Report Count (1) 130 0x81, 0x01,// Input (Cnst,Arr,Abs) 132 0xc0, // End Collection 134 This hid device declares an array of 32767 usages, but HID_MAX_USAGES is set to 12288 as mentioned in the bug. One solution (given in the bug) consists in setting HID_MAX_USAGES to 32767, but I'm not very comfortable with this large value which will impact all the existing hid devices. So what approach do you prefer: - setting HID_MAX_USAGES to 32767 - writing a specific driver which fixes this unused collection through a report fixup? - a generic fix (to be written) within hid-core which detects and prevents these huge max usage. Cheers, Benjamin -- 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
