http://blog.gmane.org/gmane.linux.kernel.input hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.kernel.input/25332 <pre>On Thu, May 24, 2012 at 3:01 PM, Greg Kroah-Hartman &lt;gregkh&lt; at &gt;linuxfoundation.org&gt; wrote: A full sysfs path really looks pretty ugly, partly because we'd have to really change all our naming (look at PCI devices now: they end up looking like pci0000:00/0000:00:1a.0 where that "0000:00" is duplicated because we wanted to make dev_name() look nice). I think Dmitry's idea to stop when we hit the actual "physical" device might just work in practice. So we'd show the dev_name() of the actual piece of hardware, and then perhaps one or two "layering" details on top of it. And it wouldn't change anything for the current common case where people tend to pass in the physical device as-is. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T22:05:09 http://permalink.gmane.org/gmane.linux.kernel.input/25331 <pre> I'm open to ideas on what to change it to. A full sysfs path? Something more "unique"? I don't know what works for everything here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Greg Kroah-Hartman 2012-05-24T22:01:05 http://permalink.gmane.org/gmane.linux.kernel.input/25330 <pre>On Thu, May 24, 2012 at 2:56 PM, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: That really sounds quite nice. It would make sense to show both the actual device information, and the "software layer" on top of it. Except maybe it then would be absolutely disgusting for some other case. Hmm. I really can't think of any bad situation off-hand, though. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T21:59:21 http://permalink.gmane.org/gmane.linux.kernel.input/25327 <pre>On Thu, May 24, 2012 at 2:07 PM, Linus Torvalds &lt;torvalds&lt; at &gt;linux-foundation.org&gt; wrote: Ok, so I wonder if we could solve the issue at least partly by separating the "print name for kernel messages" from the "name used for /sysfs etc". Because you're right: the sysfs uniqueness rules does make it very hard to do a good job on descriptive names. Also, in sysfs, you by definition see the parent (hey, it's part of the path), so in sysfs, duplicating parent data would be useless and just ugly. But for dev_dbg(), those sysfs rules actually act against us: the name of a device is often tied to the parent bus location. So I wonder if we could teach dev_printk() to use something more interesting than "dev_name()" when appropriate? Greg? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T21:44:31 http://permalink.gmane.org/gmane.linux.kernel.input/25326 <pre> I can see the desire for logging, it is just hard to come with good automatic way of doing this without burdening drivers, given that errors happen rarely in input core layer and in driver code we already have perfect device object to report against. Maybe dev_XXX() should report full sysfs path do the dveice? Still does not help with the fact that "driver" shown for class devices is not so interesting as it will always be the class name. </pre> Dmitry Torokhov 2012-05-24T21:38:13 http://permalink.gmane.org/gmane.linux.kernel.input/25324 <pre>On Thu, May 24, 2012 at 1:59 PM, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: Ok, that's certainly a valid concern. It's still - I think - really sad/wrong that the device name is then so useless than the drivers end up basically not using it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T21:07:29 http://permalink.gmane.org/gmane.linux.kernel.input/25323 <pre> I was concerned about the _next_ device (the one that will be created the moment I plug in the tablet back into the same port) having exact same name as the one that is half dead and clashing in sysfs and elsewhere. We used to have issues with this. and it guarantees to make the name unique, that is all we need. </pre> Dmitry Torokhov 2012-05-24T20:59:52 http://permalink.gmane.org/gmane.linux.kernel.input/25322 <pre>On Thu, May 24, 2012 at 1:36 PM, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: No, that wasn't the silly part of your statement. The silly part is that dev_set_name(&amp;dev-&gt;dev, "input-%s", dev_name(dev-&gt;dev.parent)); works perfectly fine if the parent goes away, for a damn simple reason: it generates the string *once*, and doesn't care one *whit* about the parent pointer ever again afterwards. For exactly the same that your current dev_set_name(&amp;dev-&gt;dev, "input%d", atomic_inc_return(&amp;input_no) - 1); doesn't care *at*all* about that "input_no" variable afterwards - dev_set_name() will have turned it into a string, and "input_no" can change as much as it wants, and that won't change the name of the device. See? So no "refcounting parents" or "zombie devices" or any crap like that. The name is just a string. Anyway, I can't be bothered to argue. If you think "input1" is such a great name, and then that results in nobody actually ever *using* it because everybody agrees it useless and will use something else, whatever. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T20:48:57 http://permalink.gmane.org/gmane.linux.kernel.input/25321 <pre> Hmm, I guess we are better now with cleaning and turning devices into zombies waiting to be reaped. Still have to handle parent have several input devices (HID devices quite often do it). And I still do not see the point why we want to bother, the proper layer to report driver errors is driver and object it is bound to. </pre> Dmitry Torokhov 2012-05-24T20:36:47 http://permalink.gmane.org/gmane.linux.kernel.input/25320 <pre>On Thu, May 24, 2012 at 12:58 PM, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: I'll let you think about just how stupid that comment was for a moment. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T20:11:14 http://permalink.gmane.org/gmane.linux.kernel.input/25318 <pre>On Thu, May 24, 2012 at 11:01 AM, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: *NEITHER* of your points actually address my issue. If the "inputX" name is useless (and dammit, I agree), then why do you continue to use it then? IOW, why the hell do you set a name that is so useful that no sane person would ever want to use it? Basically, my complaint is that the input layer drivers end up doing stupid things ("dev_dbg(input-&gt;dev.parent..") because the input layer has done stupid things (dev_set_name(&amp;dev-&gt;dev, "input%ld"). So let me be more blunt and direct: which part of "that's f*cking stupid" do you disagree with? So instead of making drivers do stupid things because you've made the input layer names so damn useless, why don't you make the input layer use better naming? Doesn't that seem to be the *smart* thing to do? Wouldn't everybody be much happier if they saw useful names in the device tree? And then the drivers could actually *use* those useful names, instead of clearly saying "our names are so shitty that we have to look up the parent name just to get a useful printout"? Do people really *want* to see names like "input2" when working with a keyboard? Do we have some stupid userlevel interface that requires these useless and nondescriptive names that are so useless that even the input layer itself doesn't want to use them? Wouldn't it be *much* nicer if the input layer would, for example, do something like dev_set_name(&amp;dev-&gt;dev, "input-%s", dev_name(dev-&gt;dev.parent)); or whatever? Better yet, make it easy for the driver to say what it is, so that it really can just say "wacom %s" or whatever. Because the basic reason you seem to want to use "dev.parent" instead of just "dev" *all* seem to boil down to a very simple reason: - other subsystems name their devices better, so you want to use those better names Fix the underlying *reason*, instead of the symptoms. That's what I'm saying. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Torvalds 2012-05-24T18:21:20 http://permalink.gmane.org/gmane.linux.kernel.input/25317 <pre> A couple of points: 1. A driver should try to use the same device for all its messages and input devices are not created yet at the time we try to bind USB interface to a driver. Most (all?) USB probe() methods use interface's device with dev_xxx() which shows exactly which interface we are dealing with. 2. Input devices are essentially driver-less (they are class devices) and therefore do not provide useful information if used in messages as the format of the message would be: input inputX: some message which does not identify neitehr the driver nor hardware device. By using input-&gt;dev.parent we get to the USB interface thus getting more meaningful messages: wacom 2-1.2:1.0: some error happened We had a discussion with Greg about this and he was going to change his patchset to use USB interfaces in the messages... Thanks. </pre> Dmitry Torokhov 2012-05-24T18:01:54 http://permalink.gmane.org/gmane.linux.kernel.input/25315 <pre>I think it should be independent of USB and should be part of hid-core.c. There is a possibility that HID over I2C, proprietary specs used by Win8 can be a standard in future. Thanks, Srinivas -----Original Message----- From: linux-input-owner&lt; at &gt;vger.kernel.org [mailto:linux-input-owner&lt; at &gt;vger.kernel.org] On Behalf Of loody Sent: Thursday, May 24, 2012 6:39 AM To: linux-input&lt; at &gt;vger.kernel.org; linux-usb&lt; at &gt;vger.kernel.org Subject: about input/hid hi all: I have some questions about input/hid devices. 1. it seems only usb hid has reports_desc, why don't we put hid parse in usbhid/hid-core.c instead of hid/hid-core.c? 2. at the end of mail is the report from mouse hid. i. where is the "USAGE_PAGE (Button) " defined, I cannot find Button id in usage table. ii. REPORT_SIZE (1) always mean the unit is bit? 3. Spec seems only describe the value of the item mean, where I can find the rules of the layout of the descriptor? char ReportDescriptor[50] = { 02 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 03 0x09, 0x02, // USAGE (Mouse) 04 0xa1, 0x01, // COLLECTION (Application) 05 0x09, 0x01, // USAGE (Pointer) 06 0xa1, 0x00, // COLLECTION (Physical) 07 0x05, 0x09, // USAGE_PAGE (Button) 08 0x19, 0x01, // USAGE_MINIMUM (Button 1) 09 0x29, 0x03, // USAGE_MAXIMUM (Button 3) 10 0x15, 0x00, // LOGICAL_MINIMUM (0) 11 0x25, 0x01, // LOGICAL_MAXIMUM (1) 12 0x95, 0x03, // REPORT_COUNT (3) 13 0x75, 0x01, // REPORT_SIZE (1) 14 0x81, 0x02, // INPUT (Data,Var,Abs) 15 0x95, 0x01, // REPORT_COUNT (1) 16 0x75, 0x05, // REPORT_SIZE (5) 17 0x81, 0x03, // INPUT (Cnst,Var,Abs) 18 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 19 0x09, 0x30, // USAGE (X) 20 0x09, 0x31, // USAGE (Y) 21 0x15, 0x81, // LOGICAL_MINIMUM (-127) 22 0x25, 0x7f, // LOGICAL_MAXIMUM (127) 23 0x75, 0x08, // REPORT_SIZE (8) 24 0x95, 0x02, // REPORT_COUNT (2) 25 0x81, 0x06, // INPUT (Data,Var,Rel) 26 0xc0, // END_COLLECTION 27 0xc0 // END_COLLECTION 28 }; Thanks for your help in advance, -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;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 majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Pandruvada, Srinivas 2012-05-24T15:16:37 http://permalink.gmane.org/gmane.linux.kernel.input/25314 <pre>hi all: I have some questions about input/hid devices. 1. it seems only usb hid has reports_desc, why don't we put hid parse in usbhid/hid-core.c instead of hid/hid-core.c? 2. at the end of mail is the report from mouse hid. i. where is the "USAGE_PAGE (Button) " defined, I cannot find Button id in usage table. ii. REPORT_SIZE (1) always mean the unit is bit? 3. Spec seems only describe the value of the item mean, where I can find the rules of the layout of the descriptor? char ReportDescriptor[50] = { 02 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 03 0x09, 0x02, // USAGE (Mouse) 04 0xa1, 0x01, // COLLECTION (Application) 05 0x09, 0x01, // USAGE (Pointer) 06 0xa1, 0x00, // COLLECTION (Physical) 07 0x05, 0x09, // USAGE_PAGE (Button) 08 0x19, 0x01, // USAGE_MINIMUM (Button 1) 09 0x29, 0x03, // USAGE_MAXIMUM (Button 3) 10 0x15, 0x00, // LOGICAL_MINIMUM (0) 11 0x25, 0x01, // LOGICAL_MAXIMUM (1) 12 0x95, 0x03, // REPORT_COUNT (3) 13 0x75, 0x01, // REPORT_SIZE (1) 14 0x81, 0x02, // INPUT (Data,Var,Abs) 15 0x95, 0x01, // REPORT_COUNT (1) 16 0x75, 0x05, // REPORT_SIZE (5) 17 0x81, 0x03, // INPUT (Cnst,Var,Abs) 18 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 19 0x09, 0x30, // USAGE (X) 20 0x09, 0x31, // USAGE (Y) 21 0x15, 0x81, // LOGICAL_MINIMUM (-127) 22 0x25, 0x7f, // LOGICAL_MAXIMUM (127) 23 0x75, 0x08, // REPORT_SIZE (8) 24 0x95, 0x02, // REPORT_COUNT (2) 25 0x81, 0x06, // INPUT (Data,Var,Rel) 26 0xc0, // END_COLLECTION 27 0xc0 // END_COLLECTION 28 }; Thanks for your help in advance, -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> loody 2012-05-24T13:38:51 http://permalink.gmane.org/gmane.linux.kernel.input/25313 <pre> Yes, you are right. The platform data was getting freed after the binding. It now works fine. Thanks for your help. </pre> Sachin Kamat 2012-05-24T10:05:52 http://permalink.gmane.org/gmane.linux.kernel.input/25312 <pre>On Wed, May 16, 2012 at 8:33 PM, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: I'll try to hunt down the reason for this, could you apply patches 1 thru 4 in the meantime, and we put 5-7 on hold? They are not dependent in any way. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Linus Walleij 2012-05-24T09:50:36 http://permalink.gmane.org/gmane.linux.kernel.input/25311 <pre>Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - a bunch of new drivers (DA9052/53 touchscreenn controller, Synaptics Navpoint, LM8333 keypads, Wacom I2C touhscreen); - updates to existing touchpad drivers (ALPS, Sntelic); - Wacom driver now supports Intuos5; - device-tree bindings in numerous drivers; - other cleanups and fixes. You will get a conflict in wacom_wac.c; please resolve taking "my" chunks or let me know and I'll merge on my side. Thanks! Changelog: --------- Ashish Jangam (1): Input: add support for DA9052/53 touch screen controller Axel Lin (5): Input: serio - add helper macro for serio_driver boilerplate Input: serio - use module_serio_driver Input: gameport - add helper macro for gameport_driver boilerplate Input: gameport - use module_gameport_driver Input: use module_pci_driver Daniel Kurtz (5): Input: atmel_mxt_ts - use CONFIG_PM_SLEEP Input: atmel_mxt_ts - only allow root to update firmware Input: atmel_mxt_ts - verify object size in mxt_write_object Input: atmel_mxt_ts - do not read extra (checksum) byte Input: atmel_mxt_ts - dump each message on just 1 line Dmitry Torokhov (21): Input: xilinx_ps2 - allocate serio port separately Input: st1232 - switch to using SIMPLE_DEV_PM_OPS Input: wacom_i2c - do not use irq_to_gpio Input: ep93xx_keypad - switch to using dev_pm_ops Input: matrix-keypad - fix 'duplicate const' sparse warning Input: matrix-keypad - allocate keycodes with keypad structure Input: matrix-keypad - undo GPIO setup if input_register_device fails Input: cma3000-d0x - remove unneeded checks Input: tc3589x-keypad - remove unnecessary checks Input: serio_raw - ensure we don't block in non-blocking read Input: wacom - fix sparse warning Input: wacom - return proper error if usb_get_extra_descriptor() fails Input: wacom - use dev_xxx() instead of naked printk()s and dbg()s Input: serio_raw - signal EFAULT even if read/write partially succeeds Input: evdev - properly access RCU-protected 'grab' data Input: evdev - properly handle read/write with count 0 Input: ALPS - switch to using input_mt_report_finger_count MAINTAINERS: adjust input-related patterns Input: matrix-keymap - uninline and prepare for device tree support Input: matrix-keymap - wire up device tree support Input: matrix-keymap - fix building keymaps George Pantalos (1): Input: ALPS - add semi-MT support for v4 protocol JJ Ding (1): Input: synaptics - fix compile warning Jason Gerecke (4): Input: wacom - add basic Intuos5 support Input: wacom - add Intuos5 Touch Ring/ExpressKey support Input: wacom - add Intuos5 Touch Ring LED support Input: wacom - add Intuos5 multitouch sensor support Jean-François Dagenais (1): Input: adp5588 - add support for gpio names Jesper Juhl (1): Input: atkbd - fix language in a printed message Julia Lawall (1): Input: aiptek - adjust error-handling code label Magnus Damm (1): Input: st1232 - add device tree support Paul Parsons (1): Input: Add Synaptics NavPoint (PXA27x SSP/SPI) driver Peter Ujfalusi (1): Input: tl6040-vibra - Device Tree support Ping Cheng (2): Input: wacom - retrieve maximum number of touch points Input: wacom - add 0xE5 (MT device) support Poddar, Sourav (1): Input: omap-keypad - dynamically handle register offsets Roland Stigge (2): Input: lpc32xx_ts - add device tree support Input: lpc32xx_ts - fix device tree compatible string Shawn Landden (2): Input: usbtouchscreen - fix typo Input: usbtouchscreen - only expose e2i configure option in expert mode Stephen Warren (1): Input: mpu3050 - set IRQF_ONESHOT when requesting the interrupt Tai-hwa Liang (1): Input: sentelic - report device's production serial number Tatsunosuke Tobita (1): Input: add support for Wacom Stylus device with I2C interface Viresh Kumar (2): Input: spear-keyboard - add device tree bindings Input: spear-keyboard - document DT bindings Wolfram Sang (1): Input: add support for LM8333 keypads Diffstat: -------- Documentation/ABI/testing/sysfs-driver-wacom | 15 +- .../devicetree/bindings/input/spear-keyboard.txt | 20 + .../bindings/input/touchscreen/lpc32xx-tsc.txt | 16 + .../devicetree/bindings/input/twl6040-vibra.txt | 37 ++ MAINTAINERS | 2 + drivers/input/Kconfig | 17 +- drivers/input/Makefile | 2 +- drivers/input/evdev.c | 69 +++-- drivers/input/gameport/emu10k1-gp.c | 13 +- drivers/input/gameport/fm801-gp.c | 16 +- drivers/input/joystick/a3d.c | 13 +- drivers/input/joystick/adi.c | 17 +- drivers/input/joystick/cobra.c | 13 +- drivers/input/joystick/gf2k.c | 13 +- drivers/input/joystick/grip.c | 13 +- drivers/input/joystick/grip_mp.c | 13 +- drivers/input/joystick/guillemot.c | 13 +- drivers/input/joystick/interact.c | 13 +- drivers/input/joystick/joydump.c | 13 +- drivers/input/joystick/magellan.c | 17 +- drivers/input/joystick/sidewinder.c | 13 +- drivers/input/joystick/spaceball.c | 17 +- drivers/input/joystick/spaceorb.c | 17 +- drivers/input/joystick/stinger.c | 17 +- drivers/input/joystick/tmdc.c | 13 +- drivers/input/joystick/twidjoy.c | 17 +- drivers/input/joystick/warrior.c | 17 +- drivers/input/joystick/zhenhua.c | 17 +- drivers/input/keyboard/Kconfig | 32 ++- drivers/input/keyboard/Makefile | 1 + drivers/input/keyboard/adp5588-keys.c | 1 + drivers/input/keyboard/atkbd.c | 2 +- drivers/input/keyboard/ep93xx_keypad.c | 44 +-- drivers/input/keyboard/hil_kbd.c | 13 +- drivers/input/keyboard/imx_keypad.c | 17 +- drivers/input/keyboard/lkkbd.c | 17 +- drivers/input/keyboard/lm8333.c | 235 +++++++++++++ drivers/input/keyboard/matrix_keypad.c | 99 +++--- drivers/input/keyboard/newtonkbd.c | 13 +- drivers/input/keyboard/nomadik-ske-keypad.c | 20 +- drivers/input/keyboard/omap-keypad.c | 20 +- drivers/input/keyboard/omap4-keypad.c | 133 ++++++-- drivers/input/keyboard/pmic8xxx-keypad.c | 20 +- drivers/input/keyboard/samsung-keypad.c | 20 +- drivers/input/keyboard/spear-keyboard.c | 92 ++++-- drivers/input/keyboard/stmpe-keypad.c | 16 +- drivers/input/keyboard/stowaway.c | 13 +- drivers/input/keyboard/sunkbd.c | 17 +- drivers/input/keyboard/tc3589x-keypad.c | 41 +-- drivers/input/keyboard/tca8418_keypad.c | 15 +- drivers/input/keyboard/tegra-kbc.c | 68 +++-- drivers/input/keyboard/tnetv107x-keypad.c | 21 +- drivers/input/keyboard/twl4030_keypad.c | 25 +- drivers/input/keyboard/w90p910_keypad.c | 27 +- drivers/input/keyboard/xtkbd.c | 13 +- drivers/input/matrix-keymap.c | 163 +++++++++ drivers/input/misc/cma3000_d0x.c | 2 +- drivers/input/misc/mpu3050.c | 2 +- drivers/input/misc/twl6040-vibra.c | 46 ++- drivers/input/mouse/Kconfig | 12 + drivers/input/mouse/Makefile | 1 + drivers/input/mouse/alps.c | 81 ++++- drivers/input/mouse/alps.h | 2 + drivers/input/mouse/navpoint.c | 369 +++++++++++++++++++ drivers/input/mouse/sentelic.c | 34 ++- drivers/input/mouse/sentelic.h | 8 + drivers/input/mouse/sermouse.c | 13 +- drivers/input/mouse/synaptics.c | 20 +- drivers/input/mouse/vsxxxaa.c | 14 +- drivers/input/of_keymap.c | 87 ----- drivers/input/serio/pcips2.c | 15 +- drivers/input/serio/ps2mult.c | 13 +- drivers/input/serio/serio_raw.c | 65 ++-- drivers/input/serio/xilinx_ps2.c | 35 +- drivers/input/tablet/aiptek.c | 2 +- drivers/input/tablet/wacom.h | 4 +- drivers/input/tablet/wacom_sys.c | 244 ++++++++++---- drivers/input/tablet/wacom_wac.c | 298 ++++++++++++++-- drivers/input/tablet/wacom_wac.h | 13 + drivers/input/touchscreen/Kconfig | 34 ++- drivers/input/touchscreen/Makefile | 2 + drivers/input/touchscreen/atmel_mxt_ts.c | 33 +-- drivers/input/touchscreen/da9052_tsi.c | 370 ++++++++++++++++++++ drivers/input/touchscreen/dynapro.c | 17 +- drivers/input/touchscreen/elo.c | 17 +- drivers/input/touchscreen/fujitsu_ts.c | 13 +- drivers/input/touchscreen/gunze.c | 17 +- drivers/input/touchscreen/h3600_ts_input.c | 17 +- drivers/input/touchscreen/hampshire.c | 17 +- drivers/input/touchscreen/inexio.c | 17 +- drivers/input/touchscreen/lpc32xx_ts.c | 10 + drivers/input/touchscreen/mtouch.c | 17 +- drivers/input/touchscreen/penmount.c | 17 +- drivers/input/touchscreen/st1232.c | 20 +- drivers/input/touchscreen/touchit213.c | 17 +- drivers/input/touchscreen/touchright.c | 17 +- drivers/input/touchscreen/touchwin.c | 17 +- drivers/input/touchscreen/tsc40.c | 12 +- drivers/input/touchscreen/wacom_i2c.c | 282 +++++++++++++++ drivers/input/touchscreen/wacom_w8001.c | 13 +- include/linux/gameport.h | 13 + include/linux/i2c/adp5588.h | 1 + include/linux/input/lm8333.h | 24 ++ include/linux/input/matrix_keypad.h | 54 +--- include/linux/input/navpoint.h | 12 + include/linux/serio.h | 13 + 106 files changed, 2845 insertions(+), 1299 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/spear-keyboard.txt create mode 100644 Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt create mode 100644 Documentation/devicetree/bindings/input/twl6040-vibra.txt create mode 100644 drivers/input/keyboard/lm8333.c create mode 100644 drivers/input/matrix-keymap.c create mode 100644 drivers/input/mouse/navpoint.c delete mode 100644 drivers/input/of_keymap.c create mode 100644 drivers/input/touchscreen/da9052_tsi.c create mode 100644 drivers/input/touchscreen/wacom_i2c.c create mode 100644 include/linux/input/lm8333.h create mode 100644 include/linux/input/navpoint.h </pre> Dmitry Torokhov 2012-05-24T08:32:16 http://permalink.gmane.org/gmane.linux.kernel.input/25310 <pre> Hmm, this is wierd... are you sure you do not discard platform data after binding to the touchscreen? </pre> Dmitry Torokhov 2012-05-24T08:22:02 http://permalink.gmane.org/gmane.linux.kernel.input/25309 <pre>Hi Dmitry, Thank you for your reply. On 24/05/2012, Dmitry Torokhov &lt;dmitry.torokhov&lt; at &gt;gmail.com&gt; wrote: Yes, i did provide the implementation for it. In fact even a simplest implementation where I return a positive integer (for testing) results in the above crash. </pre> Sachin Kamat 2012-05-24T08:11:27 http://permalink.gmane.org/gmane.linux.kernel.input/25308 <pre>Hi Joonyoung, On Thu, May 24, 2012 at 03:37:47PM +0900, Joonyoung Shim wrote: This seems too complicated. You already take input_dev-&gt;mutex in suspend/resume and open/close are called with this mutex held so you do not need yet another mutex here. Same goes for data-&gt;enabled - you can go by the fact that number of users != 0. It also looks like you want to bring enabling/disabling IRQ into start/stop and probably cfg_pin as well. Thanks. </pre> Dmitry Torokhov 2012-05-24T07:53:52 http://permalink.gmane.org/gmane.linux.kernel.input/25307 <pre>Hi Sachin, On Thu, May 24, 2012 at 11:20:01AM +0530, Sachin Kamat wrote: It actually crashes earlier, in pixcir_ts_isr() itself. The message is coming from do_exit() when ISR thread dies. Did you porvide attb_read_val implementation? I believe it is supposed to indicate if touch is detected so we can keep polling. Thanks. </pre> Dmitry Torokhov 2012-05-24T07:47:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.input