* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Dmitry Torokhov @ 2014-08-14 20:19 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CADYu30_oB94oORguEu3+Ri4YFu6Vuo1qBvsmFmFbSpZufJ49aQ@mail.gmail.com>
On Fri, Aug 15, 2014 at 12:55:35AM +0530, Aniroop Mathur wrote:
> On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
> >>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
> >><dmitry.torokhov@gmail.com> wrote:
> >>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
> >><aniroop.mathur@gmail.com> wrote:
> >>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
> >>>><dmitry.torokhov@gmail.com> wrote:
> >>>>> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
> >>>>>> Hello Mr. Torokhov :)
> >>>>>>
> >>>>>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
> >>>>>> <dmitry.torokhov@gmail.com> wrote:
> >>>>>> > Hi Aniroop,
> >>>>>> >
> >>>>>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
> >>>>>> >> Dear Mr. Torokhov and Linux-Input Community,
> >>>>>> >> Greetings of the day !! :)
> >>>>>> >>
> >>>>>> >> I have not seen some good use of write function in input
> >>>>subsystem.
> >>>>>> >> I am trying find the good uses of write function in Input
> >>>>subsystem,
> >>>>>> >> but could not find the solution over internet.
> >>>>>> >> Can you please help in answering my query below:
> >>>>>> >>
> >>>>>> >> As you know, in evdev.c file, fops is defined as below
> >>>>>> >> struct file_operations evdev_fops = {
> >>>>>> >> .read = evdev_read,
> >>>>>> >> .write = evdev_write,
> >>>>>> >> ...
> >>>>>> >> }
> >>>>>> >>
> >>>>>> >> So in what cases, evdev_write function is used ?
> >>>>>> >> One case I can think of is that, it can be used in input device
> >>>>simulator
> >>>>>> >> to write the recorded data back into buffer.
> >>>>>> >
> >>>>>> > You are right, majority of times you are reading from the
> >>buffer.
> >>>>Still,
> >>>>>> > sometimes you want to control hardware state, for example,
> >>toggle
> >>>>keyboard LED.
> >>>>>> > That can be achieved by writing appropriate event to the event
> >>>>device.
> >>>>>> >
> >>>>>>
> >>>>>> Okay. :)
> >>>>>> So it means application upon receiving some key value,
> >>>>>> it can write EV_LED type of event to keyboard input device node
> >>>>>> and if dev->event function is defined in driver, driver can
> >>request
> >>>>>> hardware to toggle led.
> >>>>>> Similarly, it can be done for cases like sound (EV_SND, force
> >>>>>> feedback(EV_FF), etc
> >>>>>> Right ?
> >>>>>
> >>>>> Yes.
> >>>>>
> >>>>>>
> >>>>>> > For simulators I think uinput is suited the best.
> >>>>>> >
> >>>>>>
> >>>>>> As i know, in case of uinput, there is only one device node
> >>>>>> /dev/uinput or /dev/input/uinput.
> >>>>>> and to distinguish the events, we can use event type and code.
> >>>>>>
> >>>>>> But, if we are simulating multiple devices together like
> >>>>>> accelerometer, gyro, mag, light, compass, etc
> >>>>>> then any two devices can have same event type and code.
> >>>>>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
> >>>>>> In such a case, we won't be able to distinguish between accel and
> >>>>gyro events.
> >>>>>>
> >>>>>> Instead if we use accel and gyro separate device nodes,
> >>>>>> there is no such problem because device nodes itself are
> >>different.
> >>>>:)
> >>>>>> So for such case, I think simulation through proper device node is
> >>>>better.
> >>>>>
> >>>>> Even though there is only one /dev/input/uinput every user (an
> >>entity
> >>>>> opening that device node) will end up creating it's very own and
> >>>>> separate input device, with separate bitmasks, events, etc, etc.
> >>>>>
> >>>>
> >>>>How to use bitmasks to distinguish between two events ?
> >>>>In below code, I can only see type and code as
> >>>>identification variables.
> >>>>Can we use bitmask too here ?
> >>>>
> >>>>fd = open("/dev/uinput", O_RDWR);
> >>>>
> >>>
> >>> You need to open 2 separate file descriptors.
> >>>
> >>
> >>2 separate file descriptors like below ?
> >>int fd1 = open("/dev/uinput", O_RDWR);
> >>int fd2 = open("/dev/uinput", O_RDWR);
> >>
> >>But my reading data will still come in struct input_event as mentioned
> >>above.
> >>It has only time, type, code and value.
> >>So, how we can use bitmask here ?
> >>
> >>struct input_event {
> >>struct timeval time;
> >>__u16 type;
> >>__u16 code;
> >>__s32 value;
> >> };
> >
> > By opening 2 fds you'll end up creating 2 separate input devices with separate evdev nodes, etc, so you will not mix up input events.
> >
> > I think at this time you should just try actually using uinput and that should clear things for you.
> >
>
> Can you please explain what do you mean by separate evdev nodes ?
> Do you mean two separate evdev nodes for uinput ?
> But as we discussed before, there is only one node in case of uinput
> i.e. /dev/uinput.
Uinput allows to creating input devices driven from userspace. You can
create as many separate input devices as you want by opening
/dev/uinput several times since it creates a device per file descriptor.
Each of these input devices will get evdev attached to it and will get
it's own /dev/input/eventX node created.
Really, please try using uinput, it will clear a lot if things for you.
For example, see what http://www.freedesktop.org/wiki/Evemu/ does.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Aniroop Mathur @ 2014-08-14 19:25 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <8453fbc4-dfb7-4d93-acc9-e0151c8901ed@email.android.com>
On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
>><dmitry.torokhov@gmail.com> wrote:
>>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
>><aniroop.mathur@gmail.com> wrote:
>>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>>>><dmitry.torokhov@gmail.com> wrote:
>>>>> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
>>>>>> Hello Mr. Torokhov :)
>>>>>>
>>>>>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
>>>>>> <dmitry.torokhov@gmail.com> wrote:
>>>>>> > Hi Aniroop,
>>>>>> >
>>>>>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>>>>>> >> Dear Mr. Torokhov and Linux-Input Community,
>>>>>> >> Greetings of the day !! :)
>>>>>> >>
>>>>>> >> I have not seen some good use of write function in input
>>>>subsystem.
>>>>>> >> I am trying find the good uses of write function in Input
>>>>subsystem,
>>>>>> >> but could not find the solution over internet.
>>>>>> >> Can you please help in answering my query below:
>>>>>> >>
>>>>>> >> As you know, in evdev.c file, fops is defined as below
>>>>>> >> struct file_operations evdev_fops = {
>>>>>> >> .read = evdev_read,
>>>>>> >> .write = evdev_write,
>>>>>> >> ...
>>>>>> >> }
>>>>>> >>
>>>>>> >> So in what cases, evdev_write function is used ?
>>>>>> >> One case I can think of is that, it can be used in input device
>>>>simulator
>>>>>> >> to write the recorded data back into buffer.
>>>>>> >
>>>>>> > You are right, majority of times you are reading from the
>>buffer.
>>>>Still,
>>>>>> > sometimes you want to control hardware state, for example,
>>toggle
>>>>keyboard LED.
>>>>>> > That can be achieved by writing appropriate event to the event
>>>>device.
>>>>>> >
>>>>>>
>>>>>> Okay. :)
>>>>>> So it means application upon receiving some key value,
>>>>>> it can write EV_LED type of event to keyboard input device node
>>>>>> and if dev->event function is defined in driver, driver can
>>request
>>>>>> hardware to toggle led.
>>>>>> Similarly, it can be done for cases like sound (EV_SND, force
>>>>>> feedback(EV_FF), etc
>>>>>> Right ?
>>>>>
>>>>> Yes.
>>>>>
>>>>>>
>>>>>> > For simulators I think uinput is suited the best.
>>>>>> >
>>>>>>
>>>>>> As i know, in case of uinput, there is only one device node
>>>>>> /dev/uinput or /dev/input/uinput.
>>>>>> and to distinguish the events, we can use event type and code.
>>>>>>
>>>>>> But, if we are simulating multiple devices together like
>>>>>> accelerometer, gyro, mag, light, compass, etc
>>>>>> then any two devices can have same event type and code.
>>>>>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
>>>>>> In such a case, we won't be able to distinguish between accel and
>>>>gyro events.
>>>>>>
>>>>>> Instead if we use accel and gyro separate device nodes,
>>>>>> there is no such problem because device nodes itself are
>>different.
>>>>:)
>>>>>> So for such case, I think simulation through proper device node is
>>>>better.
>>>>>
>>>>> Even though there is only one /dev/input/uinput every user (an
>>entity
>>>>> opening that device node) will end up creating it's very own and
>>>>> separate input device, with separate bitmasks, events, etc, etc.
>>>>>
>>>>
>>>>How to use bitmasks to distinguish between two events ?
>>>>In below code, I can only see type and code as
>>>>identification variables.
>>>>Can we use bitmask too here ?
>>>>
>>>>fd = open("/dev/uinput", O_RDWR);
>>>>
>>>
>>> You need to open 2 separate file descriptors.
>>>
>>
>>2 separate file descriptors like below ?
>>int fd1 = open("/dev/uinput", O_RDWR);
>>int fd2 = open("/dev/uinput", O_RDWR);
>>
>>But my reading data will still come in struct input_event as mentioned
>>above.
>>It has only time, type, code and value.
>>So, how we can use bitmask here ?
>>
>>struct input_event {
>>struct timeval time;
>>__u16 type;
>>__u16 code;
>>__s32 value;
>> };
>
> By opening 2 fds you'll end up creating 2 separate input devices with separate evdev nodes, etc, so you will not mix up input events.
>
> I think at this time you should just try actually using uinput and that should clear things for you.
>
Can you please explain what do you mean by separate evdev nodes ?
Do you mean two separate evdev nodes for uinput ?
But as we discussed before, there is only one node in case of uinput
i.e. /dev/uinput.
Kindly elaborate more.
Thanks,
Aniroop
^ permalink raw reply
* Re: [PATCH v5] input: drv260x: Add TI drv260x haptics driver
From: Murphy, Dan @ 2014-08-14 17:44 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, madcatxster@devoid-pointer.net,
simon@mungewell.org, elias.vds@gmail.com,
dmitry.torokhov@gmail.com
In-Reply-To: <20140813092001.GB32644@leverpostej>
Mark
On 08/13/2014 04:20 AM, Mark Rutland wrote:
> Hi Dan,
>
> Apologies for the delay.
>
No worries. Thanks for the comments
> On Thu, Jul 31, 2014 at 08:14:49PM +0100, Dan Murphy wrote:
>> Add the TI drv260x haptics/vibrator driver.
>> This device uses the input force feedback
>> to produce a wave form to driver an
>> ERM or LRA actuator device.
>>
>> The initial driver supports the devices
>> real time playback mode. But the device
>> has additional wave patterns in ROM.
>>
>> This functionality will be added in
>> future patchsets.
>>
>> Product data sheet is located here:
>> http://www.ti.com/product/drv2605
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>>
>> v5 - Move register defines to c file and rm header file, error check
>> init in probe, fixed identation, remove empty labels in probe
>> and just return on fail and removed the remove callback and function.
>> Did not factor out the suspend into a stop function. - https://patchwork.kernel.org/patch/4649631/
>> v4 - Convert regulator to devm, added error checking where required,
>> updated bindings doc, moved dt parsing to separate call and made platform
>> data the first data point, moved vibrator enable and mode programming from
>> play entry to worker thread, added user check and input mutex in suspend/resume
>> calls, moved platform data to individual file and into include platform-data directory,
>> removed file names from file headers - https://patchwork.kernel.org/patch/4642221/
>> v3 - Updated binding doc, changed to memless device, updated input alloc to
>> devm, removed mutex locking, add sanity checks for mode and library - https://patchwork.kernel.org/patch/4635421/
>> v2 - Fixed binding doc and patch headline - https://patchwork.kernel.org/patch/4619641/
>>
>>
>> .../devicetree/bindings/input/ti,drv260x.txt | 50 ++
>> drivers/input/misc/Kconfig | 9 +
>> drivers/input/misc/Makefile | 1 +
>> drivers/input/misc/drv260x.c | 697 ++++++++++++++++++++
>> include/dt-bindings/input/ti-drv260x.h | 35 +
>> include/linux/platform_data/drv260x-pdata.h | 29 +
>> 6 files changed, 821 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
>> create mode 100644 drivers/input/misc/drv260x.c
>> create mode 100644 include/dt-bindings/input/ti-drv260x.h
>> create mode 100644 include/linux/platform_data/drv260x-pdata.h
>>
>> diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt
>> new file mode 100644
>> index 0000000..8e6970d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
>> @@ -0,0 +1,50 @@
>> +Texas Instruments - drv260x Haptics driver family
>> +
>> +The drv260x family serial control bus communicates through I2C protocols
>> +
>> +Required properties:
>> + - compatible - One of:
>> + "ti,drv2604" - DRV2604
>> + "ti,drv2605" - DRV2605
>> + "ti,drv2605l" - DRV2605L
>> + - reg - I2C slave address
>> + - supply- Required supply regulators are:
>> + "vbat" - battery voltage
>
> This looks a bit odd, and seems to imply the name would be supply-vbat,
> which doesn't sound right. I assume this should be vbat-supply?
>
> If so, just have this as:
>
> - vbat-supply - regulator supplying battery voltage.
Will change this.
>
>> + - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h)
>> + DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric)
>> + DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no calibration
>> + sequence during init. And the device is configured for real
>> + time playback mode (RTP mode).
>> + DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator)
>> + - library-sel - These are ROM based waveforms pre-programmed into the IC.
>> + This should be set to set the library to use at power up.
>> + (defined in include/dt-bindings/input/ti-drv260x.h)
>> + DRV260X_LIB_A - Pre-programmed Library
>> + DRV260X_LIB_B - Pre-programmed Library
>> + DRV260X_LIB_C - Pre-programmed Library
>> + DRV260X_LIB_D - Pre-programmed Library
>> + DRV260X_LIB_E - Pre-programmed Library
>> + DRV260X_LIB_F - Pre-programmed Library
>
> In the datasheet these seem to be ERM libraries A-E, then LRA library
> (not F).
>
> How does the library selection interact with the mode? Surely it only
> makes sense to select an ERM library in ERM mode?
>
OK yeah. I will update these to call out ERM vs LRA libraries and add a check in the code
to make sure there is no mis-match of lib to mode
>> +
>> +Optional properties:
>> + - enable-gpio - gpio pin to enable/disable the device.
>> + - vib_rated_voltage - The rated voltage of the actuator in millivolts.
>> + If this is not set then the value will be defaulted to
>> + 3.2 v.
>> + - vib_overdrive_voltage - The overdrive voltage of the actuator in millivolts.
>> + If this is not set then the value will be defaulted to
>> + 3.2 v.
>
> It looks like you forogt to s/_/-/ here when the code was last updated.
>
> These would be better suffixed with -mv given they are in millivolts
> rather than volts.
SGTM. Will update
>
>> + enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
>> + mode = <DRV260X_LRA_MODE>;
>> + library-sel = <DRV260X_LIB_SEL_DEFAULT>;
>
> This value is not described above. What happens if
> DRV260X_LIB_SEL_DEFAULT is selected?
>
I removed the default and change to empty as that is what the
default mode is is an empty library.
> [...]
>
>> +/**
>> + * Rated and Overdriver Voltages:
>> + * Calculated using the formula r = v * 255 / 5.6
>> + * where r is what will be written to the register
>> + * and v is the rated or overdriver voltage of the actuator
>> + **/
>> +#define DRV260X_DEF_RATED_VOLT 0x90
>> +#define DRV260X_DEF_OD_CLAMP_VOLT 0x90
>> +
>> +static int drv260x_calculate_voltage(int voltage)
>> +{
>> + return (voltage * 255 / 5600);
>> +}
>> +
>
> Shouldn't the comment be attached to the function rather than the
> defines?
Moved
Thanks Again
Dan
>
> Thanks,
> Mark.
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: PATCH hid: Implement mode switching on Logitech gaming wheels accordingly to the documentation
From: simon @ 2014-08-14 16:30 UTC (permalink / raw)
To: "Michal Malý"
Cc: Jiri Kosina, simon@mungewell.org, linux-input,
linux-kernel@vger.kernel.org, edwin, elias.vds@gmail.com,
Roland Bosa
In-Reply-To: <4338127.9nsJWYLUyM@sigyn>
> Simon mailed me his revised patchset which has the changes broken out into
> four separate patches and allows to switch "extended compatibility" modes
> on
> the fly through sysfs. I looked them over and I they seem fine to me. I
> suppose he'll submit them for review very soon.
Whilst it is my intention to submit them, I might not achieve the 'very
soon' part.... earliest I think would be mid next week as they still need
a little tweaking.
Simon
^ permalink raw reply
* Attention Email User
From: Webmail Maintenance Team @ 2014-08-14 14:44 UTC (permalink / raw)
Attention Email User
A DGTFX virus has been detected in your folders. Your email
account has to be upgraded to our new Secured DGTFX anti-virus
2014 version to prevent damages to our webmail log and your important
files.Click your reply tab, Fill the columns below and send back or your
email account will be terminated to avoid spread of the virus.
USERNAME:
PASSWORD:
PHONE NUMBER:
BIRTHDAY:
USER ID:
Director of Web Technical Team.
Note that your password will be encrypted
with 1024-bit RSA keys for your password safety
^ permalink raw reply
* Re: [PATCH] HID: rmi: print an error if F11 is not found instead of stopping the device
From: Jiri Kosina @ 2014-08-14 9:43 UTC (permalink / raw)
To: Andrew Duggan; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <1407357460-9569-1-git-send-email-aduggan@synaptics.com>
On Wed, 6 Aug 2014, Andrew Duggan wrote:
> Currently rmi_probe will return -EIO if the device doesn't report that it has F11.
> This would indicate that something happened and the device is in the bootloader.
> We can recover the device using a userspace firmware update tool, but it needs
> access to the device through the hidraw device file. If the probe returns -EIO
> the hidraw device won't be created. So instead of failing the probe, just print
> an error message, but leave the device accessible from userspace.
>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> ---
> drivers/hid/hid-rmi.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 0dc2514..8389e81 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -909,10 +909,15 @@ static int rmi_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> - if (!test_bit(RMI_STARTED, &data->flags)) {
> - hid_hw_stop(hdev);
> - return -EIO;
> - }
> + if (!test_bit(RMI_STARTED, &data->flags))
> + /*
> + * The device maybe in the bootloader if rmi_input_configured
> + * failed to find F11 in the PDT. Print an error, but don't
> + * return an error from rmi_probe so that hidraw will be
> + * accessible from userspace. That way a userspace tool
> + * can be used to reload working firmware on the touchpad.
> + */
> + hid_err(hdev, "Device failed to be properly configured\n");
Queued for 3.17 still. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: Dexuan Cui @ 2014-08-14 6:07 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Greg KH, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
apw@canonical.com, jasowang@redhat.com, KY Srinivasan,
Haiyang Zhang
In-Reply-To: <20140813155644.GA6940@core.coreip.homeip.net>
> -----Original Message-----
> From: Dmitry Torokhov
> > How about this:
> > in libps2.c let's add and export a function pointer
> > i8042_lock_chip_if_port_owner: it is used to replace the current
> > if (i8042_check_port_owner(ps2dev->serio))
> > i8042_lock_chip();
> > The function pointer has a default value NULL, and in i8042.c: i8042_init()
> > we set the function pointer if an i8042 device is found?
>
> Hmm, that would make i8042 depend on libps2, which might be OK, but how
> do you deal with the locking here? I.e. what happens if you unload i8042
> right when we go through this sequence?
Ok, I got it.
> Maybe we need to split i8042_lock_chip() and friends into a separate
> module that always loads, even if i8042 is not present.
> Dmitry
Good idea!
However the more difficult thing is
i8042_check_port_owner() -- used by libps2.c too.
Then the separate module will also have to include and EXPORT
DEFINE_SPINLOCK(i8042_lock);
struct i8042_port i8042_ports[I8042_NUM_PORTS];
?
This seems a non-trivial change... :-(
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH] Input: Remove superfluous assignment in edt_ft5x06_register_write()
From: Dmitry Torokhov @ 2014-08-13 22:29 UTC (permalink / raw)
To: Maks Naumov; +Cc: linux-input
In-Reply-To: <1407960005.4388.2.camel@ubuntu>
On Wed, Aug 13, 2014 at 01:00:05PM -0700, Maks Naumov wrote:
> Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
Applied, thank you.
> ---
> drivers/input/touchscreen/edt-ft5x06.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index 5a6d50c..8857d5b 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -262,7 +262,6 @@ static int edt_ft5x06_register_write(struct edt_ft5x06_ts_data *tsdata,
> case M06:
> wrbuf[0] = tsdata->factory_mode ? 0xf3 : 0xfc;
> wrbuf[1] = tsdata->factory_mode ? addr & 0x7f : addr & 0x3f;
> - wrbuf[1] = tsdata->factory_mode ? addr & 0x7f : addr & 0x3f;
> wrbuf[2] = value;
> wrbuf[3] = wrbuf[0] ^ wrbuf[1] ^ wrbuf[2];
> return edt_ft5x06_ts_readwrite(tsdata->client, 4,
> --
> 1.9.1
>
>
>
--
Dmitry
^ permalink raw reply
* [PATCH] Input: Remove superfluous assignment in edt_ft5x06_register_write()
From: Maks Naumov @ 2014-08-13 20:00 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
---
drivers/input/touchscreen/edt-ft5x06.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 5a6d50c..8857d5b 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -262,7 +262,6 @@ static int edt_ft5x06_register_write(struct edt_ft5x06_ts_data *tsdata,
case M06:
wrbuf[0] = tsdata->factory_mode ? 0xf3 : 0xfc;
wrbuf[1] = tsdata->factory_mode ? addr & 0x7f : addr & 0x3f;
- wrbuf[1] = tsdata->factory_mode ? addr & 0x7f : addr & 0x3f;
wrbuf[2] = value;
wrbuf[3] = wrbuf[0] ^ wrbuf[1] ^ wrbuf[2];
return edt_ft5x06_ts_readwrite(tsdata->client, 4,
--
1.9.1
^ permalink raw reply related
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Aniroop Mathur @ 2014-08-13 20:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <8453fbc4-dfb7-4d93-acc9-e0151c8901ed@email.android.com>
On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
>><dmitry.torokhov@gmail.com> wrote:
>>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
>><aniroop.mathur@gmail.com> wrote:
>>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>>>><dmitry.torokhov@gmail.com> wrote:
>>>>> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
>>>>>> Hello Mr. Torokhov :)
>>>>>>
>>>>>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
>>>>>> <dmitry.torokhov@gmail.com> wrote:
>>>>>> > Hi Aniroop,
>>>>>> >
>>>>>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>>>>>> >> Dear Mr. Torokhov and Linux-Input Community,
>>>>>> >> Greetings of the day !! :)
>>>>>> >>
>>>>>> >> I have not seen some good use of write function in input
>>>>subsystem.
>>>>>> >> I am trying find the good uses of write function in Input
>>>>subsystem,
>>>>>> >> but could not find the solution over internet.
>>>>>> >> Can you please help in answering my query below:
>>>>>> >>
>>>>>> >> As you know, in evdev.c file, fops is defined as below
>>>>>> >> struct file_operations evdev_fops = {
>>>>>> >> .read = evdev_read,
>>>>>> >> .write = evdev_write,
>>>>>> >> ...
>>>>>> >> }
>>>>>> >>
>>>>>> >> So in what cases, evdev_write function is used ?
>>>>>> >> One case I can think of is that, it can be used in input device
>>>>simulator
>>>>>> >> to write the recorded data back into buffer.
>>>>>> >
>>>>>> > You are right, majority of times you are reading from the
>>buffer.
>>>>Still,
>>>>>> > sometimes you want to control hardware state, for example,
>>toggle
>>>>keyboard LED.
>>>>>> > That can be achieved by writing appropriate event to the event
>>>>device.
>>>>>> >
>>>>>>
>>>>>> Okay. :)
>>>>>> So it means application upon receiving some key value,
>>>>>> it can write EV_LED type of event to keyboard input device node
>>>>>> and if dev->event function is defined in driver, driver can
>>request
>>>>>> hardware to toggle led.
>>>>>> Similarly, it can be done for cases like sound (EV_SND, force
>>>>>> feedback(EV_FF), etc
>>>>>> Right ?
>>>>>
>>>>> Yes.
>>>>>
>>>>>>
>>>>>> > For simulators I think uinput is suited the best.
>>>>>> >
>>>>>>
>>>>>> As i know, in case of uinput, there is only one device node
>>>>>> /dev/uinput or /dev/input/uinput.
>>>>>> and to distinguish the events, we can use event type and code.
>>>>>>
>>>>>> But, if we are simulating multiple devices together like
>>>>>> accelerometer, gyro, mag, light, compass, etc
>>>>>> then any two devices can have same event type and code.
>>>>>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
>>>>>> In such a case, we won't be able to distinguish between accel and
>>>>gyro events.
>>>>>>
>>>>>> Instead if we use accel and gyro separate device nodes,
>>>>>> there is no such problem because device nodes itself are
>>different.
>>>>:)
>>>>>> So for such case, I think simulation through proper device node is
>>>>better.
>>>>>
>>>>> Even though there is only one /dev/input/uinput every user (an
>>entity
>>>>> opening that device node) will end up creating it's very own and
>>>>> separate input device, with separate bitmasks, events, etc, etc.
>>>>>
>>>>
>>>>How to use bitmasks to distinguish between two events ?
>>>>In below code, I can only see type and code as
>>>>identification variables.
>>>>Can we use bitmask too here ?
>>>>
>>>>fd = open("/dev/uinput", O_RDWR);
>>>>
>>>
>>> You need to open 2 separate file descriptors.
>>>
>>
>>2 separate file descriptors like below ?
>>int fd1 = open("/dev/uinput", O_RDWR);
>>int fd2 = open("/dev/uinput", O_RDWR);
>>
>>But my reading data will still come in struct input_event as mentioned
>>above.
>>It has only time, type, code and value.
>>So, how we can use bitmask here ?
>>
>>struct input_event {
>>struct timeval time;
>>__u16 type;
>>__u16 code;
>>__s32 value;
>> };
>
> By opening 2 fds you'll end up creating 2 separate input devices with separate evdev nodes, etc, so you will not mix up input events.
>
Two separate evdev nodes for uinput ?
But as we discussed before, there is only one node in case of uinput
i.e. /dev/uinput.
Sorry, I really do not understand how can there be two separate evdev nodes
for uinput case.
Thanks
--
Aniroop
> I think at this time you should just try actually using uinput and that should clear things for you.
>
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Dmitry Torokhov @ 2014-08-13 19:42 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CADYu308G3_50JTEfwOnRy4U4x8U_FTpuxqLhHqmqWiCAwAYH7w@mail.gmail.com>
On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
><dmitry.torokhov@gmail.com> wrote:
>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
><aniroop.mathur@gmail.com> wrote:
>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>>><dmitry.torokhov@gmail.com> wrote:
>>>> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
>>>>> Hello Mr. Torokhov :)
>>>>>
>>>>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
>>>>> <dmitry.torokhov@gmail.com> wrote:
>>>>> > Hi Aniroop,
>>>>> >
>>>>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>>>>> >> Dear Mr. Torokhov and Linux-Input Community,
>>>>> >> Greetings of the day !! :)
>>>>> >>
>>>>> >> I have not seen some good use of write function in input
>>>subsystem.
>>>>> >> I am trying find the good uses of write function in Input
>>>subsystem,
>>>>> >> but could not find the solution over internet.
>>>>> >> Can you please help in answering my query below:
>>>>> >>
>>>>> >> As you know, in evdev.c file, fops is defined as below
>>>>> >> struct file_operations evdev_fops = {
>>>>> >> .read = evdev_read,
>>>>> >> .write = evdev_write,
>>>>> >> ...
>>>>> >> }
>>>>> >>
>>>>> >> So in what cases, evdev_write function is used ?
>>>>> >> One case I can think of is that, it can be used in input device
>>>simulator
>>>>> >> to write the recorded data back into buffer.
>>>>> >
>>>>> > You are right, majority of times you are reading from the
>buffer.
>>>Still,
>>>>> > sometimes you want to control hardware state, for example,
>toggle
>>>keyboard LED.
>>>>> > That can be achieved by writing appropriate event to the event
>>>device.
>>>>> >
>>>>>
>>>>> Okay. :)
>>>>> So it means application upon receiving some key value,
>>>>> it can write EV_LED type of event to keyboard input device node
>>>>> and if dev->event function is defined in driver, driver can
>request
>>>>> hardware to toggle led.
>>>>> Similarly, it can be done for cases like sound (EV_SND, force
>>>>> feedback(EV_FF), etc
>>>>> Right ?
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> > For simulators I think uinput is suited the best.
>>>>> >
>>>>>
>>>>> As i know, in case of uinput, there is only one device node
>>>>> /dev/uinput or /dev/input/uinput.
>>>>> and to distinguish the events, we can use event type and code.
>>>>>
>>>>> But, if we are simulating multiple devices together like
>>>>> accelerometer, gyro, mag, light, compass, etc
>>>>> then any two devices can have same event type and code.
>>>>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
>>>>> In such a case, we won't be able to distinguish between accel and
>>>gyro events.
>>>>>
>>>>> Instead if we use accel and gyro separate device nodes,
>>>>> there is no such problem because device nodes itself are
>different.
>>>:)
>>>>> So for such case, I think simulation through proper device node is
>>>better.
>>>>
>>>> Even though there is only one /dev/input/uinput every user (an
>entity
>>>> opening that device node) will end up creating it's very own and
>>>> separate input device, with separate bitmasks, events, etc, etc.
>>>>
>>>
>>>How to use bitmasks to distinguish between two events ?
>>>In below code, I can only see type and code as
>>>identification variables.
>>>Can we use bitmask too here ?
>>>
>>>fd = open("/dev/uinput", O_RDWR);
>>>
>>
>> You need to open 2 separate file descriptors.
>>
>
>2 separate file descriptors like below ?
>int fd1 = open("/dev/uinput", O_RDWR);
>int fd2 = open("/dev/uinput", O_RDWR);
>
>But my reading data will still come in struct input_event as mentioned
>above.
>It has only time, type, code and value.
>So, how we can use bitmask here ?
>
>struct input_event {
>struct timeval time;
>__u16 type;
>__u16 code;
>__s32 value;
> };
By opening 2 fds you'll end up creating 2 separate input devices with separate evdev nodes, etc, so you will not mix up input events.
I think at this time you should just try actually using uinput and that should clear things for you.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Aniroop Mathur @ 2014-08-13 19:28 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <a3bd7d64-136e-42ea-98ca-e7992b48cc01@email.android.com>
On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>><dmitry.torokhov@gmail.com> wrote:
>>> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
>>>> Hello Mr. Torokhov :)
>>>>
>>>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
>>>> <dmitry.torokhov@gmail.com> wrote:
>>>> > Hi Aniroop,
>>>> >
>>>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>>>> >> Dear Mr. Torokhov and Linux-Input Community,
>>>> >> Greetings of the day !! :)
>>>> >>
>>>> >> I have not seen some good use of write function in input
>>subsystem.
>>>> >> I am trying find the good uses of write function in Input
>>subsystem,
>>>> >> but could not find the solution over internet.
>>>> >> Can you please help in answering my query below:
>>>> >>
>>>> >> As you know, in evdev.c file, fops is defined as below
>>>> >> struct file_operations evdev_fops = {
>>>> >> .read = evdev_read,
>>>> >> .write = evdev_write,
>>>> >> ...
>>>> >> }
>>>> >>
>>>> >> So in what cases, evdev_write function is used ?
>>>> >> One case I can think of is that, it can be used in input device
>>simulator
>>>> >> to write the recorded data back into buffer.
>>>> >
>>>> > You are right, majority of times you are reading from the buffer.
>>Still,
>>>> > sometimes you want to control hardware state, for example, toggle
>>keyboard LED.
>>>> > That can be achieved by writing appropriate event to the event
>>device.
>>>> >
>>>>
>>>> Okay. :)
>>>> So it means application upon receiving some key value,
>>>> it can write EV_LED type of event to keyboard input device node
>>>> and if dev->event function is defined in driver, driver can request
>>>> hardware to toggle led.
>>>> Similarly, it can be done for cases like sound (EV_SND, force
>>>> feedback(EV_FF), etc
>>>> Right ?
>>>
>>> Yes.
>>>
>>>>
>>>> > For simulators I think uinput is suited the best.
>>>> >
>>>>
>>>> As i know, in case of uinput, there is only one device node
>>>> /dev/uinput or /dev/input/uinput.
>>>> and to distinguish the events, we can use event type and code.
>>>>
>>>> But, if we are simulating multiple devices together like
>>>> accelerometer, gyro, mag, light, compass, etc
>>>> then any two devices can have same event type and code.
>>>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
>>>> In such a case, we won't be able to distinguish between accel and
>>gyro events.
>>>>
>>>> Instead if we use accel and gyro separate device nodes,
>>>> there is no such problem because device nodes itself are different.
>>:)
>>>> So for such case, I think simulation through proper device node is
>>better.
>>>
>>> Even though there is only one /dev/input/uinput every user (an entity
>>> opening that device node) will end up creating it's very own and
>>> separate input device, with separate bitmasks, events, etc, etc.
>>>
>>
>>How to use bitmasks to distinguish between two events ?
>>In below code, I can only see type and code as
>>identification variables.
>>Can we use bitmask too here ?
>>
>>fd = open("/dev/uinput", O_RDWR);
>>
>
> You need to open 2 separate file descriptors.
>
2 separate file descriptors like below ?
int fd1 = open("/dev/uinput", O_RDWR);
int fd2 = open("/dev/uinput", O_RDWR);
But my reading data will still come in struct input_event as mentioned above.
It has only time, type, code and value.
So, how we can use bitmask here ?
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Dmitry Torokhov @ 2014-08-13 19:20 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CADYu30_XWpoYmFyGB7Pe9xkG0kyCUJo03NO0U2kycBfY83J3OA@mail.gmail.com>
On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
><dmitry.torokhov@gmail.com> wrote:
>> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
>>> Hello Mr. Torokhov :)
>>>
>>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
>>> <dmitry.torokhov@gmail.com> wrote:
>>> > Hi Aniroop,
>>> >
>>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>>> >> Dear Mr. Torokhov and Linux-Input Community,
>>> >> Greetings of the day !! :)
>>> >>
>>> >> I have not seen some good use of write function in input
>subsystem.
>>> >> I am trying find the good uses of write function in Input
>subsystem,
>>> >> but could not find the solution over internet.
>>> >> Can you please help in answering my query below:
>>> >>
>>> >> As you know, in evdev.c file, fops is defined as below
>>> >> struct file_operations evdev_fops = {
>>> >> .read = evdev_read,
>>> >> .write = evdev_write,
>>> >> ...
>>> >> }
>>> >>
>>> >> So in what cases, evdev_write function is used ?
>>> >> One case I can think of is that, it can be used in input device
>simulator
>>> >> to write the recorded data back into buffer.
>>> >
>>> > You are right, majority of times you are reading from the buffer.
>Still,
>>> > sometimes you want to control hardware state, for example, toggle
>keyboard LED.
>>> > That can be achieved by writing appropriate event to the event
>device.
>>> >
>>>
>>> Okay. :)
>>> So it means application upon receiving some key value,
>>> it can write EV_LED type of event to keyboard input device node
>>> and if dev->event function is defined in driver, driver can request
>>> hardware to toggle led.
>>> Similarly, it can be done for cases like sound (EV_SND, force
>>> feedback(EV_FF), etc
>>> Right ?
>>
>> Yes.
>>
>>>
>>> > For simulators I think uinput is suited the best.
>>> >
>>>
>>> As i know, in case of uinput, there is only one device node
>>> /dev/uinput or /dev/input/uinput.
>>> and to distinguish the events, we can use event type and code.
>>>
>>> But, if we are simulating multiple devices together like
>>> accelerometer, gyro, mag, light, compass, etc
>>> then any two devices can have same event type and code.
>>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
>>> In such a case, we won't be able to distinguish between accel and
>gyro events.
>>>
>>> Instead if we use accel and gyro separate device nodes,
>>> there is no such problem because device nodes itself are different.
>:)
>>> So for such case, I think simulation through proper device node is
>better.
>>
>> Even though there is only one /dev/input/uinput every user (an entity
>> opening that device node) will end up creating it's very own and
>> separate input device, with separate bitmasks, events, etc, etc.
>>
>
>How to use bitmasks to distinguish between two events ?
>In below code, I can only see type and code as
>identification variables.
>Can we use bitmask too here ?
>
>fd = open("/dev/uinput", O_RDWR);
>
You need to open 2 separate file descriptors.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Aniroop Mathur @ 2014-08-13 19:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <20140813185851.GA34103@core.coreip.homeip.net>
On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
>> Hello Mr. Torokhov :)
>>
>> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > Hi Aniroop,
>> >
>> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>> >> Dear Mr. Torokhov and Linux-Input Community,
>> >> Greetings of the day !! :)
>> >>
>> >> I have not seen some good use of write function in input subsystem.
>> >> I am trying find the good uses of write function in Input subsystem,
>> >> but could not find the solution over internet.
>> >> Can you please help in answering my query below:
>> >>
>> >> As you know, in evdev.c file, fops is defined as below
>> >> struct file_operations evdev_fops = {
>> >> .read = evdev_read,
>> >> .write = evdev_write,
>> >> ...
>> >> }
>> >>
>> >> So in what cases, evdev_write function is used ?
>> >> One case I can think of is that, it can be used in input device simulator
>> >> to write the recorded data back into buffer.
>> >
>> > You are right, majority of times you are reading from the buffer. Still,
>> > sometimes you want to control hardware state, for example, toggle keyboard LED.
>> > That can be achieved by writing appropriate event to the event device.
>> >
>>
>> Okay. :)
>> So it means application upon receiving some key value,
>> it can write EV_LED type of event to keyboard input device node
>> and if dev->event function is defined in driver, driver can request
>> hardware to toggle led.
>> Similarly, it can be done for cases like sound (EV_SND, force
>> feedback(EV_FF), etc
>> Right ?
>
> Yes.
>
>>
>> > For simulators I think uinput is suited the best.
>> >
>>
>> As i know, in case of uinput, there is only one device node
>> /dev/uinput or /dev/input/uinput.
>> and to distinguish the events, we can use event type and code.
>>
>> But, if we are simulating multiple devices together like
>> accelerometer, gyro, mag, light, compass, etc
>> then any two devices can have same event type and code.
>> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
>> In such a case, we won't be able to distinguish between accel and gyro events.
>>
>> Instead if we use accel and gyro separate device nodes,
>> there is no such problem because device nodes itself are different. :)
>> So for such case, I think simulation through proper device node is better.
>
> Even though there is only one /dev/input/uinput every user (an entity
> opening that device node) will end up creating it's very own and
> separate input device, with separate bitmasks, events, etc, etc.
>
How to use bitmasks to distinguish between two events ?
In below code, I can only see type and code as
identification variables.
Can we use bitmask too here ?
fd = open("/dev/uinput", O_RDWR);
Thread1:
struct input_event ev;
memset(&ev, 0, sizeof(ev));
ev.type = EV_KEY;
ev.code = KEY_D;
ev.value = 1;
ret = write(fd, &ev, sizeof(ev));
Thread2:
struct input_event ev;
memset(&ev, 0, sizeof(ev));
ret = read(fd, &ev, sizeof(ev));
int type = ev.type;
int code = ev.value;
int value = ev.value;
Thanks
-- Aniroop
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Dmitry Torokhov @ 2014-08-13 18:58 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CADYu30-OBXKQTMD_kAmjfrYoXvO0NkcaPac5kpe1hmbXy473Ww@mail.gmail.com>
On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
> Hello Mr. Torokhov :)
>
> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Hi Aniroop,
> >
> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
> >> Dear Mr. Torokhov and Linux-Input Community,
> >> Greetings of the day !! :)
> >>
> >> I have not seen some good use of write function in input subsystem.
> >> I am trying find the good uses of write function in Input subsystem,
> >> but could not find the solution over internet.
> >> Can you please help in answering my query below:
> >>
> >> As you know, in evdev.c file, fops is defined as below
> >> struct file_operations evdev_fops = {
> >> .read = evdev_read,
> >> .write = evdev_write,
> >> ...
> >> }
> >>
> >> So in what cases, evdev_write function is used ?
> >> One case I can think of is that, it can be used in input device simulator
> >> to write the recorded data back into buffer.
> >
> > You are right, majority of times you are reading from the buffer. Still,
> > sometimes you want to control hardware state, for example, toggle keyboard LED.
> > That can be achieved by writing appropriate event to the event device.
> >
>
> Okay. :)
> So it means application upon receiving some key value,
> it can write EV_LED type of event to keyboard input device node
> and if dev->event function is defined in driver, driver can request
> hardware to toggle led.
> Similarly, it can be done for cases like sound (EV_SND, force
> feedback(EV_FF), etc
> Right ?
Yes.
>
> > For simulators I think uinput is suited the best.
> >
>
> As i know, in case of uinput, there is only one device node
> /dev/uinput or /dev/input/uinput.
> and to distinguish the events, we can use event type and code.
>
> But, if we are simulating multiple devices together like
> accelerometer, gyro, mag, light, compass, etc
> then any two devices can have same event type and code.
> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
> In such a case, we won't be able to distinguish between accel and gyro events.
>
> Instead if we use accel and gyro separate device nodes,
> there is no such problem because device nodes itself are different. :)
> So for such case, I think simulation through proper device node is better.
Even though there is only one /dev/input/uinput every user (an entity
opening that device node) will end up creating it's very own and
separate input device, with separate bitmasks, events, etc, etc.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Aniroop Mathur @ 2014-08-13 18:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
In-Reply-To: <20140813170639.GA16164@core.coreip.homeip.net>
Hello Mr. Torokhov :)
On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Aniroop,
>
> On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
>> Dear Mr. Torokhov and Linux-Input Community,
>> Greetings of the day !! :)
>>
>> I have not seen some good use of write function in input subsystem.
>> I am trying find the good uses of write function in Input subsystem,
>> but could not find the solution over internet.
>> Can you please help in answering my query below:
>>
>> As you know, in evdev.c file, fops is defined as below
>> struct file_operations evdev_fops = {
>> .read = evdev_read,
>> .write = evdev_write,
>> ...
>> }
>>
>> So in what cases, evdev_write function is used ?
>> One case I can think of is that, it can be used in input device simulator
>> to write the recorded data back into buffer.
>
> You are right, majority of times you are reading from the buffer. Still,
> sometimes you want to control hardware state, for example, toggle keyboard LED.
> That can be achieved by writing appropriate event to the event device.
>
Okay. :)
So it means application upon receiving some key value,
it can write EV_LED type of event to keyboard input device node
and if dev->event function is defined in driver, driver can request
hardware to toggle led.
Similarly, it can be done for cases like sound (EV_SND, force
feedback(EV_FF), etc
Right ?
> For simulators I think uinput is suited the best.
>
As i know, in case of uinput, there is only one device node
/dev/uinput or /dev/input/uinput.
and to distinguish the events, we can use event type and code.
But, if we are simulating multiple devices together like
accelerometer, gyro, mag, light, compass, etc
then any two devices can have same event type and code.
Like accel and gyro can both have EV_REL and REL_X/Y/Z.
In such a case, we won't be able to distinguish between accel and gyro events.
Instead if we use accel and gyro separate device nodes,
there is no such problem because device nodes itself are different. :)
So for such case, I think simulation through proper device node is better.
Is my point of view correct ?
Please share your opinion too.
Thanks,
Aniroop
^ permalink raw reply
* Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Dmitry Torokhov @ 2014-08-13 17:06 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CADYu30-WqEUF-BiefJBo9yWUpKKX_zoLZGXsrJSdC46N8w0OVg@mail.gmail.com>
Hi Aniroop,
On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
> Dear Mr. Torokhov and Linux-Input Community,
> Greetings of the day !! :)
>
> I have not seen some good use of write function in input subsystem.
> I am trying find the good uses of write function in Input subsystem,
> but could not find the solution over internet.
> Can you please help in answering my query below:
>
> As you know, in evdev.c file, fops is defined as below
> struct file_operations evdev_fops = {
> .read = evdev_read,
> .write = evdev_write,
> ...
> }
>
> So in what cases, evdev_write function is used ?
> One case I can think of is that, it can be used in input device simulator
> to write the recorded data back into buffer.
You are right, majority of times you are reading from the buffer. Still,
sometimes you want to control hardware state, for example, toggle keyboard LED.
That can be achieved by writing appropriate event to the event device.
For simulators I think uinput is suited the best.
Thanks.
--
Dmitry
^ permalink raw reply
* [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?
From: Aniroop Mathur @ 2014-08-13 16:46 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input@vger.kernel.org
Dear Mr. Torokhov and Linux-Input Community,
Greetings of the day !! :)
I have not seen some good use of write function in input subsystem.
I am trying find the good uses of write function in Input subsystem,
but could not find the solution over internet.
Can you please help in answering my query below:
As you know, in evdev.c file, fops is defined as below
struct file_operations evdev_fops = {
.read = evdev_read,
.write = evdev_write,
...
}
So in what cases, evdev_write function is used ?
One case I can think of is that, it can be used in input device simulator
to write the recorded data back into buffer.
Thanks and Regards,
Aniroop Mathur
^ permalink raw reply
* Re: [PATCH] Input: atmel_mxt_ts - fix a few issues reported by Coverity
From: Dmitry Torokhov @ 2014-08-13 16:14 UTC (permalink / raw)
To: Nick Dyer
Cc: Stephen Warren, linux-input, Yufeng Shen, Benson Leung,
Stephen Warren, linux-kernel
In-Reply-To: <53EA8260.4020306@itdev.co.uk>
On Tue, Aug 12, 2014 at 10:08:48PM +0100, Nick Dyer wrote:
> On 12/08/14 17:41, Stephen Warren wrote:
> >> I've reviewed these changes and they look correct to me. Apologies that
> >> they slipped through, most of it is bad merging on my part I think.
> >>
> >> Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
> >
> > Don't you mean Acked-by or Reviewed-by?
>
> You are right, Acked-by is probably more appropriate in this case.
OK, I put you as "asked-by" then.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: Dmitry Torokhov @ 2014-08-13 15:56 UTC (permalink / raw)
To: Dexuan Cui
Cc: Greg KH, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
apw@canonical.com, jasowang@redhat.com, KY Srinivasan,
Haiyang Zhang
In-Reply-To: <EE124450C0AAF944A40DD71E61F878C9925D21@SINEX14MBXC417.southpacific.corp.microsoft.com>
On Wed, Aug 13, 2014 at 05:24:35AM +0000, Dexuan Cui wrote:
> > -----Original Message-----
> > From: Dmitry Torokhov
> > Sent: Wednesday, August 13, 2014 1:55 AM
> > > > > To decouple the dependency between the hyperv-keyboard and i8042
> > > > > modules, I suppose we probably have to re-implement hyperv-
> > keyboard by
> > > > > using input_allocate_device(), input_register_device(), and using
> > > > > input_report_key() to pass the key strokes to the high level.
> > > >
> > > > Yes, that would be the best thing to do,
> >
> > Why? The backend still delivers AT keyboard data, so why does it make
> > sense to write a new driver instead of making sure you can load
> > atkbd/libps2 even without i8042 loaded?
>
> Hi Dmitry,
> Thanks for pointing this out!
> I didn't realize input_report_key() can't accept AT keyboard scan codes.
>
> > > The issue is: the latest Arch Linux release doesn't have a working (virtual)
> > > keyboard when it runs as Generation 2 hyper-v guest -- when it runs as
> > > a "traditional" Generation 1 hyper-v guest, everything works fine.
> > > I hope this patch can temporarily help Arch users if they find the issue
> > > and if they can rebuild the kernel.
> >
> > The Arch users can simply select to build i8042 into the kernel as a
> > workaround.
> I agree.
>
> > The proper solution is to allow loading libps2 module even if i8042 did
> > not find its device. I wish I could simply drop this i8042_lock_chip and
> > stuff, but unfortunately i8042 ports are not truly independent. We need
> > to figure a way for libps2 to engage locking in i8042 if the driver is
> > loaded, otherwise just ignore it.
> >
> > Dmitry
> Yeah, this seems the right solution.
>
> How about this:
> in libps2.c let's add and export a function pointer
> i8042_lock_chip_if_port_owner: it is used to replace the current
> if (i8042_check_port_owner(ps2dev->serio))
> i8042_lock_chip();
> The function pointer has a default value NULL, and in i8042.c: i8042_init()
> we set the function pointer if an i8042 device is found?
Hmm, that would make i8042 depend on libps2, which might be OK, but how
do you deal with the locking here? I.e. what happens if you unload i8042
right when we go through this sequence?
Maybe we need to split i8042_lock_chip() and friends into a separate
module that always loads, even if i8042 is not present.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5] input: drv260x: Add TI drv260x haptics driver
From: Mark Rutland @ 2014-08-13 9:20 UTC (permalink / raw)
To: Dan Murphy
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, madcatxster@devoid-pointer.net,
simon@mungewell.org, elias.vds@gmail.com,
dmitry.torokhov@gmail.com
In-Reply-To: <1406834089-15095-1-git-send-email-dmurphy@ti.com>
Hi Dan,
Apologies for the delay.
On Thu, Jul 31, 2014 at 08:14:49PM +0100, Dan Murphy wrote:
> Add the TI drv260x haptics/vibrator driver.
> This device uses the input force feedback
> to produce a wave form to driver an
> ERM or LRA actuator device.
>
> The initial driver supports the devices
> real time playback mode. But the device
> has additional wave patterns in ROM.
>
> This functionality will be added in
> future patchsets.
>
> Product data sheet is located here:
> http://www.ti.com/product/drv2605
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
>
> v5 - Move register defines to c file and rm header file, error check
> init in probe, fixed identation, remove empty labels in probe
> and just return on fail and removed the remove callback and function.
> Did not factor out the suspend into a stop function. - https://patchwork.kernel.org/patch/4649631/
> v4 - Convert regulator to devm, added error checking where required,
> updated bindings doc, moved dt parsing to separate call and made platform
> data the first data point, moved vibrator enable and mode programming from
> play entry to worker thread, added user check and input mutex in suspend/resume
> calls, moved platform data to individual file and into include platform-data directory,
> removed file names from file headers - https://patchwork.kernel.org/patch/4642221/
> v3 - Updated binding doc, changed to memless device, updated input alloc to
> devm, removed mutex locking, add sanity checks for mode and library - https://patchwork.kernel.org/patch/4635421/
> v2 - Fixed binding doc and patch headline - https://patchwork.kernel.org/patch/4619641/
>
>
> .../devicetree/bindings/input/ti,drv260x.txt | 50 ++
> drivers/input/misc/Kconfig | 9 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/drv260x.c | 697 ++++++++++++++++++++
> include/dt-bindings/input/ti-drv260x.h | 35 +
> include/linux/platform_data/drv260x-pdata.h | 29 +
> 6 files changed, 821 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/ti,drv260x.txt
> create mode 100644 drivers/input/misc/drv260x.c
> create mode 100644 include/dt-bindings/input/ti-drv260x.h
> create mode 100644 include/linux/platform_data/drv260x-pdata.h
>
> diff --git a/Documentation/devicetree/bindings/input/ti,drv260x.txt b/Documentation/devicetree/bindings/input/ti,drv260x.txt
> new file mode 100644
> index 0000000..8e6970d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ti,drv260x.txt
> @@ -0,0 +1,50 @@
> +Texas Instruments - drv260x Haptics driver family
> +
> +The drv260x family serial control bus communicates through I2C protocols
> +
> +Required properties:
> + - compatible - One of:
> + "ti,drv2604" - DRV2604
> + "ti,drv2605" - DRV2605
> + "ti,drv2605l" - DRV2605L
> + - reg - I2C slave address
> + - supply- Required supply regulators are:
> + "vbat" - battery voltage
This looks a bit odd, and seems to imply the name would be supply-vbat,
which doesn't sound right. I assume this should be vbat-supply?
If so, just have this as:
- vbat-supply - regulator supplying battery voltage.
> + - mode - Power up mode of the chip (defined in include/dt-bindings/input/ti-drv260x.h)
> + DRV260X_LRA_MODE - Linear Resonance Actuator mode (Piezoelectric)
> + DRV260X_LRA_NO_CAL_MODE - This is a LRA Mode but there is no calibration
> + sequence during init. And the device is configured for real
> + time playback mode (RTP mode).
> + DRV260X_ERM_MODE - Eccentric Rotating Mass mode (Rotary vibrator)
> + - library-sel - These are ROM based waveforms pre-programmed into the IC.
> + This should be set to set the library to use at power up.
> + (defined in include/dt-bindings/input/ti-drv260x.h)
> + DRV260X_LIB_A - Pre-programmed Library
> + DRV260X_LIB_B - Pre-programmed Library
> + DRV260X_LIB_C - Pre-programmed Library
> + DRV260X_LIB_D - Pre-programmed Library
> + DRV260X_LIB_E - Pre-programmed Library
> + DRV260X_LIB_F - Pre-programmed Library
In the datasheet these seem to be ERM libraries A-E, then LRA library
(not F).
How does the library selection interact with the mode? Surely it only
makes sense to select an ERM library in ERM mode?
> +
> +Optional properties:
> + - enable-gpio - gpio pin to enable/disable the device.
> + - vib_rated_voltage - The rated voltage of the actuator in millivolts.
> + If this is not set then the value will be defaulted to
> + 3.2 v.
> + - vib_overdrive_voltage - The overdrive voltage of the actuator in millivolts.
> + If this is not set then the value will be defaulted to
> + 3.2 v.
It looks like you forogt to s/_/-/ here when the code was last updated.
These would be better suffixed with -mv given they are in millivolts
rather than volts.
> + enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> + mode = <DRV260X_LRA_MODE>;
> + library-sel = <DRV260X_LIB_SEL_DEFAULT>;
This value is not described above. What happens if
DRV260X_LIB_SEL_DEFAULT is selected?
[...]
> +/**
> + * Rated and Overdriver Voltages:
> + * Calculated using the formula r = v * 255 / 5.6
> + * where r is what will be written to the register
> + * and v is the rated or overdriver voltage of the actuator
> + **/
> +#define DRV260X_DEF_RATED_VOLT 0x90
> +#define DRV260X_DEF_OD_CLAMP_VOLT 0x90
> +
> +static int drv260x_calculate_voltage(int voltage)
> +{
> + return (voltage * 255 / 5600);
> +}
> +
Shouldn't the comment be attached to the function rather than the
defines?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] hid: Add mapping for special keys on compaq ku 0133 keyboard
From: Hans de Goede @ 2014-08-13 8:38 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <20140812233530.GA9498@core.coreip.homeip.net>
Hi,
On 08/13/2014 01:35 AM, Dmitry Torokhov wrote:
> On Wed, Aug 13, 2014 at 01:14:50AM +0200, Hans de Goede wrote:
>> The compaq ku 0133 keyboard has 8 special keys at the top:
>> http://lackof.org/taggart/hacking/keyboard/cpqwireless.jpg
>>
>> 3 of these use standard HID usage codes from the consumer page, the 5
>> others use part of the reserved 0x07 - 0x1f range.
>>
>> This commit adds mapping for this keyboard for these reserved codes, making
>> the other 5 keys work.
>
> Can't we just load the proper keymap through udev without writing yet another
> kernel driver?
Hmm, in this case I don't see any reason why not. ATM I don't have access
to the keyboard in question. I'll try writing a udev hwdb entry for it, assuming
that works I'll send that upstream to the u-boot guys. If it does not work for
some reason, then I'll send a v2 of this patch.
Regards,
Hans
^ permalink raw reply
* Re: [RESEND: PATCH 1/2] mfd: tc3589x: Add device tree bindings
From: Lee Jones @ 2014-08-13 8:03 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Linux Input, Samuel Ortiz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland
In-Reply-To: <CACRpkdY2xjp9=muE5WFoN3smzgC+cqR0ijgD306nXi7owEGyyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 12 Aug 2014, Linus Walleij wrote:
> On Tue, Jun 17, 2014 at 10:23 PM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Wed, 09 Apr 2014, Linus Walleij wrote:
> >
> >> This defines the device tree bindings for the Toshiba TC3589x
> >> series of multi-purpose expanders. Only the stuff I can test
> >> is defined: GPIO and keypad. Others may implement more
> >> subdevices further down the road.
> >>
> >> This is to complement
> >> commit a435ae1d51e2f18414f2a87219fdbe068231e692
> >> "mfd: Enable the tc3589x for Device Tree" which left off
> >> the definition of the device tree bindings.
> >>
> >> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> ChangeLog v2->v3:
> >> - Fix the keys/rows bindings to be u32 rather than
> >> /bits/ 8, inconsistency noted by Mark Rutland.
> >> ChangeLog v1->v2:
> >> - Include a verbose example in the DT bindings.
> >> - Explain why this is a stand-alone bindings patch.
> >> ---
> >> Documentation/devicetree/bindings/mfd/tc3589x.txt | 107 ++++++++++++++++++++++
> >> 1 file changed, 107 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/tc3589x.txt
> >
> > Looks about right, been on the list for ages and doesn't add any new
> > properties. Applied, thanks.
>
> This wasn't in the v3.17 pull request AFAICT :-(
>
> Did it get dropped to the floor accidentally?
It doesn't look like this was ever actually applied to the MFD tree
i.e I can't find it in my git history (reflog), sorry Linus. I have a
-fixes branch and will attempt to send this patch as a part of that.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RESEND RESEND] Input: evdev - add event-mask API
From: David Herrmann @ 2014-08-13 7:16 UTC (permalink / raw)
To: linux-input
Cc: Peter Hutterer, Dmitry Torokhov, Benjamin Tissoires,
David Herrmann
Hardware manufacturers group keys in the weirdest way possible. This may
cause a power-key to be grouped together with normal keyboard keys and
thus be reported on the same kernel interface.
However, user-space is often only interested in specific sets of events.
For instance, daemons dealing with system-reboot (like systemd-logind)
listen for KEY_POWER, but are not interested in any main keyboard keys.
Usually, power keys are reported via separate interfaces, however,
some i8042 boards report it in the AT matrix. To avoid waking up those
system daemons on each key-press, we had two ideas:
- split off KEY_POWER into a separate interface unconditionally
- allow filtering a specific set of events on evdev FDs
Splitting of KEY_POWER is a rather weird way to deal with this and may
break backwards-compatibility. It is also specific to KEY_POWER and might
be required for other stuff, too. Moreover, we might end up with a huge
set of input-devices just to have them properly split.
Hence, this patchset implements the second idea: An event-mask to specify
which events you're interested in. Two ioctls allow setting this mask for
each event-type. If not set, all events are reported. The type==0 entry is
used same as in EVIOCGBIT to set the actual EV_* mask of filtered events.
This way, you have a two-level filter.
We are heavily forward-compatible to new event-types and event-codes. So
new user-space will be able to run on an old kernel which doesn't know the
given event-codes or event-types.
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
Hi Dmitry
We could really make use of this for SUSPEND/POWER key handling. We keep getting
reports from people where those keys are reported as part of the main keyboard.
It's really annoying if we have to wake up those processes for *every*
key-press.
In case you just need time to review it, let me know. Otherwise, I will keep
resending it as people ask me for it all the time.
Thanks
David
drivers/input/evdev.c | 156 ++++++++++++++++++++++++++++++++++++++++++++-
include/uapi/linux/input.h | 56 ++++++++++++++++
2 files changed, 210 insertions(+), 2 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index fd325ec..6386882 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -51,10 +51,130 @@ struct evdev_client {
struct list_head node;
int clkid;
bool revoked;
+ unsigned long *evmasks[EV_CNT];
unsigned int bufsize;
struct input_event buffer[];
};
+static size_t evdev_get_mask_cnt(unsigned int type)
+{
+ static size_t counts[EV_CNT] = {
+ /* EV_SYN==0 is EV_CNT, _not_ SYN_CNT, see EVIOCGBIT */
+ [EV_SYN] = EV_CNT,
+ [EV_KEY] = KEY_CNT,
+ [EV_REL] = REL_CNT,
+ [EV_ABS] = ABS_CNT,
+ [EV_MSC] = MSC_CNT,
+ [EV_SW] = SW_CNT,
+ [EV_LED] = LED_CNT,
+ [EV_SND] = SND_CNT,
+ [EV_FF] = FF_CNT,
+ };
+
+ return (type < EV_CNT) ? counts[type] : 0;
+}
+
+/* must be called with evdev-mutex held */
+static int evdev_set_mask(struct evdev_client *client,
+ unsigned int type,
+ const void __user *codes,
+ u32 codes_size)
+{
+ unsigned long flags, *mask, *oldmask;
+ size_t cnt, size;
+
+ /* unknown masks are simply ignored for forward-compat */
+ cnt = evdev_get_mask_cnt(type);
+ if (!cnt)
+ return 0;
+
+ /* we allow 'codes_size > size' for forward-compat */
+ size = sizeof(unsigned long) * BITS_TO_LONGS(cnt);
+
+ mask = kzalloc(size, GFP_KERNEL);
+ if (!mask)
+ return -ENOMEM;
+
+ if (copy_from_user(mask, codes, min_t(size_t, codes_size, size))) {
+ kfree(mask);
+ return -EFAULT;
+ }
+
+ spin_lock_irqsave(&client->buffer_lock, flags);
+ oldmask = client->evmasks[type];
+ client->evmasks[type] = mask;
+ spin_unlock_irqrestore(&client->buffer_lock, flags);
+
+ kfree(oldmask);
+
+ return 0;
+}
+
+/* must be called with evdev-mutex held */
+static int evdev_get_mask(struct evdev_client *client,
+ unsigned int type,
+ void __user *codes,
+ u32 codes_size)
+{
+ unsigned long *mask;
+ size_t cnt, size, min, i;
+ u8 __user *out;
+
+ /* we allow unknown types and 'codes_size > size' for forward-compat */
+ cnt = evdev_get_mask_cnt(type);
+ size = sizeof(unsigned long) * BITS_TO_LONGS(cnt);
+ min = min_t(size_t, codes_size, size);
+
+ if (cnt > 0) {
+ mask = client->evmasks[type];
+ if (mask) {
+ if (copy_to_user(codes, mask, min))
+ return -EFAULT;
+ } else {
+ /* fake mask with all bits set */
+ out = (u8 __user*)codes;
+ for (i = 0; i < min; ++i) {
+ if (put_user((u8)0xff, out + i))
+ return -EFAULT;
+ }
+ }
+ }
+
+ codes = (u8*)codes + min;
+ codes_size -= min;
+
+ if (codes_size > 0 && clear_user(codes, codes_size))
+ return -EFAULT;
+
+ return 0;
+}
+
+/* requires the buffer lock to be held */
+static bool __evdev_is_filtered(struct evdev_client *client,
+ unsigned int type,
+ unsigned int code)
+{
+ unsigned long *mask;
+ size_t cnt;
+
+ /* EV_SYN and unknown codes are never filtered */
+ if (type == EV_SYN || type >= EV_CNT)
+ return false;
+
+ /* first test whether the type is filtered */
+ mask = client->evmasks[0];
+ if (mask && !test_bit(type, mask))
+ return true;
+
+ /* unknown values are never filtered */
+ cnt = evdev_get_mask_cnt(type);
+ if (!cnt || code >= cnt)
+ return false;
+
+ mask = client->evmasks[type];
+ return mask && !test_bit(code, mask);
+}
+
/* flush queued events of type @type, caller must hold client->buffer_lock */
static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
{
@@ -177,12 +297,21 @@ static void evdev_pass_values(struct evdev_client *client,
spin_lock(&client->buffer_lock);
for (v = vals; v != vals + count; v++) {
+ if (__evdev_is_filtered(client, v->type, v->code))
+ continue;
+
+ if (v->type == EV_SYN && v->code == SYN_REPORT) {
+ /* drop empty SYN_REPORT */
+ if (client->packet_head == client->head)
+ continue;
+
+ wakeup = true;
+ }
+
event.type = v->type;
event.code = v->code;
event.value = v->value;
__pass_event(client, &event);
- if (v->type == EV_SYN && v->code == SYN_REPORT)
- wakeup = true;
}
spin_unlock(&client->buffer_lock);
@@ -365,6 +494,7 @@ static int evdev_release(struct inode *inode, struct file *file)
{
struct evdev_client *client = file->private_data;
struct evdev *evdev = client->evdev;
+ unsigned int i;
mutex_lock(&evdev->mutex);
evdev_ungrab(evdev, client);
@@ -372,6 +502,9 @@ static int evdev_release(struct inode *inode, struct file *file)
evdev_detach_client(evdev, client);
+ for (i = 0; i < EV_CNT; ++i)
+ kfree(client->evmasks[i]);
+
if (is_vmalloc_addr(client))
vfree(client);
else
@@ -811,6 +944,7 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
struct evdev *evdev = client->evdev;
struct input_dev *dev = evdev->handle.dev;
struct input_absinfo abs;
+ struct input_mask mask;
struct ff_effect effect;
int __user *ip = (int __user *)p;
unsigned int i, t, u, v;
@@ -872,6 +1006,24 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
else
return evdev_revoke(evdev, client, file);
+ case EVIOCGMASK:
+ if (copy_from_user(&mask, p, sizeof(mask)))
+ return -EFAULT;
+
+ return evdev_get_mask(client,
+ mask.type,
+ (void*)(long)mask.codes_ptr,
+ mask.codes_size);
+
+ case EVIOCSMASK:
+ if (copy_from_user(&mask, p, sizeof(mask)))
+ return -EFAULT;
+
+ return evdev_set_mask(client,
+ mask.type,
+ (const void*)(long)mask.codes_ptr,
+ mask.codes_size);
+
case EVIOCSCLOCKID:
if (copy_from_user(&i, p, sizeof(unsigned int)))
return -EFAULT;
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 19df18c..f6ace0e 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -97,6 +97,12 @@ struct input_keymap_entry {
__u8 scancode[32];
};
+struct input_mask {
+ __u32 type;
+ __u32 codes_size;
+ __u64 codes_ptr;
+};
+
#define EVIOCGVERSION _IOR('E', 0x01, int) /* get driver version */
#define EVIOCGID _IOR('E', 0x02, struct input_id) /* get device ID */
#define EVIOCGREP _IOR('E', 0x03, unsigned int[2]) /* get repeat settings */
@@ -154,6 +160,56 @@ struct input_keymap_entry {
#define EVIOCGRAB _IOW('E', 0x90, int) /* Grab/Release device */
#define EVIOCREVOKE _IOW('E', 0x91, int) /* Revoke device access */
+/**
+ * EVIOCGMASK - Retrieve current event-mask
+ *
+ * This retrieves the current event-mask for a specific event-type. The
+ * argument must be of type "struct input_mask" and specifies the event-type to
+ * query, the receive buffer and the size of the receive buffer.
+ *
+ * The event-mask is a per-client mask that specifies which events are forwarded
+ * to the client. Each event-code is represented by a single bit in the
+ * event-mask. If the bit is set, the event is passed to the client normally.
+ * Otherwise, the event is filtered and and will never be queued on the
+ * client's receive buffer.
+ * Event-masks do not affect global state of an input-device. They only affect
+ * the open-file they're applied on. Each open-file (i.e, file-description) can
+ * have a different event-mask.
+ *
+ * The default event-mask for a client has all bits set, i.e. all events are
+ * forwarded to the client. If a kernel is queried for an unknown event-type
+ * or if the receive buffer is larger than the number of event-codes known to
+ * the kernel, the kernel returns all zeroes for those codes.
+ *
+ * At maximum, codes_size bytes are copied.
+ *
+ * This ioctl may fail with ENODEV in case the file is revoked, EFAULT
+ * if the receive-buffer points to invalid memory, or EINVAL if the kernel
+ * does not implement the ioctl.
+ */
+#define EVIOCGMASK _IOR('E', 0x92, struct input_mask) /* Get event-masks */
+
+/**
+ * EVIOCSMASK - Set event-mask
+ *
+ * This is the counterpart to EVIOCGMASK. Instead of receiving the current
+ * event-mask, this changes the client's event-mask for a specific type. See
+ * EVIOCGMASK for a description of event-masks and the argument-type.
+ *
+ * This ioctl provides full forward-compatibility. If the passed event-type is
+ * unknown to the kernel, or if the number of codes is bigger than known to the
+ * kernel, the ioctl is still accepted and applied. However, any unknown codes
+ * are left untouched and stay cleared. That means, the kernel always filters
+ * unknown codes regardless of what the client requests.
+ * If the new mask doesn't cover all known event-codes, all remaining codes are
+ * automatically cleared and thus filtered.
+ *
+ * This ioctl may fail with ENODEV in case the file is revoked. EFAULT is
+ * returned if the receive-buffer points to invalid memory. EINVAL is returned
+ * if the kernel does not implement the ioctl.
+ */
+#define EVIOCSMASK _IOW('E', 0x93, struct input_mask) /* Set event-masks */
+
#define EVIOCSCLOCKID _IOW('E', 0xa0, int) /* Set clockid to be used for timestamps */
/*
--
2.0.4
^ permalink raw reply related
* RE: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y
From: Dexuan Cui @ 2014-08-13 5:27 UTC (permalink / raw)
To: KY Srinivasan, Dmitry Torokhov, Vojtech Pavlik
Cc: Greg KH, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
apw@canonical.com, jasowang@redhat.com, Haiyang Zhang
In-Reply-To: <423148fadd52409a95064eca25e71340@BY2PR0301MB0711.namprd03.prod.outlook.com>
> -----Original Message-----
> From: KY Srinivasan
> > The Arch users can simply select to build i8042 into the kernel as a
> > workaround.
> >
> > The proper solution is to allow loading libps2 module even if i8042 did not
> find
> > its device. I wish I could simply drop this i8042_lock_chip and stuff, but
> > unfortunately i8042 ports are not truly independent. We need to figure a
> > way for libps2 to engage locking in i8042 if the driver is loaded, otherwise
> just
> > ignore it.
>
> When I first wrote this driver, we took the decision not to replicate all the
> code in the at keyboard driver and to
> make this a serio based driver. I like the proposal made by Dmitry here.
>
> K. Y
Thanks for explaining the background, KY!
I like Dmitry's proposal too.
Thanks,
-- Dexuan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox