Re: On the fly input_set_abs_params changes

Hi, Jian-Jhong Le 16/07/2012 07:17, Jian-Jhong Ding a écrit : >> I'm wondering if it's ok to change min/max parameters after registration, >> and how >> it should be handled by xorg's evdev. > > I am really intrigued why you have to do this. Some specific feature of > your device? Can you elabor

Re: On the fly input_set_abs_params changes

Hi Yann, Yann Cantin writes: > Hi, > > I'm working on a kernel input driver for eBeam devices (see > http://www.e-beam.com). > > This hardware is very special, and his handling don't fit in any existing > category > (or i've not found it yet). > > I'm wondering if it's ok to change min/max para

Re: [PATCH 04/23 v6] Input: atmel_mxt_ts - warn if sysfs could not be created

On Fri, Jul 6, 2012 at 3:15 AM, Henrik Rydberg wrote: > On Thu, Jul 05, 2012 at 10:22:30AM -0700, Dmitry Torokhov wrote: >> Hi Daniel, Henrik, >> >> On Thu, Jun 28, 2012 at 09:08:05PM +0800, Daniel Kurtz wrote: >> > If sysfs entry creation fails, the driver is still usable, so don't >> > just abor

On the fly input_set_abs_params changes

Hi, I'm working on a kernel input driver for eBeam devices (see http://www.e-beam.com). This hardware is very special, and his handling don't fit in any existing category (or i've not found it yet). I'm wondering if it's ok to change min/max parameters after registration, and how it should be

Re: [PATCH] Input: eeti_ts: Mark as CONFIG_BROKEN

On 13.07.2012 09:01, Dmitry Torokhov wrote: > On Wed, May 02, 2012 at 09:36:51PM -0700, Dmitry Torokhov wrote: >> Hi Sven, >> >> On Sat, Apr 07, 2012 at 08:38:33PM +0200, Sven Neumann wrote: >>> Hi, >>> >>> On 07.04.12 09:02, Dmitry Torokhov wrote: On Fri, Apr 06, 2012 at 10:40:07PM -0700, Olo

[PATCH 3/3] HID: wiimote: explicitly claim hid devices with HID_CLAIMED_OTHER

We allow hidraw to be loaded on wiimote devices but if a kernel is compiled without hidraw, calling hid_hw_start() will always fail as no driver claims the device. Therefore, we now explicitly set HID_CLAIMED_OTHER so the hid-core will allow loading the device even if no generic driver claimed it.

[PATCH 2/3] HID: picolcd: explicitly claim hid devices with HID_CLAIMED_OTHER

Instead of using an ugly workaround to make hid_hw_start() correctly initialize the device, we now explicitely set HID_CLAIMED_OTHER before initializing the hid device. This tells the hid-core to accept the device even if no generic hid driver gets loaded. Signed-off-by: David Herrmann --- drive

[PATCH 1/3] HID: Add HID_CLAIMED_OTHER for non-generic drivers

All normal devices that correctly conform to the HID specs are handled by the hid-input driver. However, for non-standard drivers we often don't want hid-input to handle them but rather use specific hid drivers. But hid_connect() requires at least one generic driver to claim the devices. As hid_hw_

[PATCH 0/3] HID: Add HID_CLAIMED_OTHER device flag

Hi Drivers like picolcd and wiimote work without the generic hid drivers (hidinput, hidraw, hiddev). Therefore, we need to make sure that the hid-core does not drop the device when no driver claimed it. This introduces the HID_CLAIMED_OTHER flag which can be set by said drivers to tell hid-core t