From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops? Date: Wed, 13 Aug 2014 11:58:51 -0700 Message-ID: <20140813185851.GA34103@core.coreip.homeip.net> References: <20140813170639.GA16164@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pa0-f54.google.com ([209.85.220.54]:50147 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750759AbaHMS6z (ORCPT ); Wed, 13 Aug 2014 14:58:55 -0400 Received: by mail-pa0-f54.google.com with SMTP id fa1so187535pad.13 for ; Wed, 13 Aug 2014 11:58:54 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Aniroop Mathur Cc: "linux-input@vger.kernel.org" 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 > 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