From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dmitry Torokhov" Subject: Re: [RFC 1/2] Input: ff, add FF_RAW effect Date: Thu, 26 Apr 2007 11:58:09 -0400 Message-ID: References: <210731960111436322@karneval.cz> <462688AB.4060707@gmail.com> <38b3b7c0704182125q1928c5barad21ed603088ab04@mail.gmail.com> <200704190058.11625.dtor@insightbb.com> <46278CDD.2000007@gmail.com> <462D0947.3090109@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <462D0947.3090109@gmail.com> Content-Disposition: inline Sender: owner-linux-input@atrey.karlin.mff.cuni.cz List-Help: List-Owner: List-Post: List-Unsubscribe: To: Jiri Slaby Cc: johann deneux , linux-kernel@vger.kernel.org, stenyak@gmail.com, linux-input@atrey.karlin.mff.cuni.cz List-Id: linux-input@vger.kernel.org Hi Jiri, On 4/23/07, Jiri Slaby wrote: > Dmitry Torokhov napsal(a): > > For devices that require tailored application (for example that glove > > - I am not sure how a generic application could control it) old > > phantom way of controlling via ioctl will suffice. The device may > > still use input layer to report back coordinates. > > And how about the individual FF ioctl? Did you mean registering another > chardev, which is totally ugly in my eyes or augment evdev.c to support > driver specific ioctl? i.e. either add another 'E' ioctl with pointer to > struct { code, value } as arg param or changing > if (_IOC_TYPE(cmd) != 'E')) > return -EINVAL; > to sth. like > if (_IOC_TYPE(cmd) != 'E')) > return dev->ioctl ? dev->ioctl(file, cmd, p) : -EINVAL; > in evdev_ioctl_handler, which is acceptable? > I really do not want to have driver-specific ioctls attaching to evdev. What is wrong with a separate device to control phantom? You won't even have to use ioctl but regial write on it. -- Dmitry