lkml.org 
[lkml]   [2005]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Add Force Feedback interface to joydev
Vojtech Pavlik wrote:
> On Thu, Jul 07, 2005 at 05:20:59PM +0300, Anssi Hannula wrote:
>
>>But I think we should not apply (with or without 64-bit) the patch (not
>>yet, anyway), as I'm (slowly) working on restructuring the kernel FF
>>interface and developing a user space library (and writing a generic HID
>>PID FF-driver).
>
> That sounds interesting. However - I don't know of many devices that'd
> be PID compliant except for the MS SideWinder ForceFeedback Pro 2.
> All the Logitechs, as far as I know don't implement full PID.

Unfortunately so :( Do you have any info on how close the FF
implementation of the common FF devices is to the PID standard?
I had a poor choice of words in the previous message; I have only little
code written, mainly I've been just thinking on a bunch of ideas on how
we could do these things better (in other words, I've taken a summer break).
What I have written, is the PID driver (not complete yet) and a simple
FF driver for Zeroplus based devices (VID 0x0c12, PID 0x0005 and 0x0008,
very cheap Playstation-pads with USB connector, I have two branded "XFX
Executioner Dual Impact" (BTW, their Windows driver is crap, doesn't
support multiple devices and hangs Control Panel windows continuosly)).
I could post a patch for the Zeroplus support, but with current FF
driver model, that would be 90% copy-paste of hid-tmff.c & hid-lgff.c.

>
>>As a matter of fact, I have two (lengthy) questions:
>>
>>1. What would be the best way to decide when to delete the effects of a
>>specific process from the device? Currently it is done when flush is
>>called. However, if one process holds multiple fd's to the interface
>>(for example input fd through some gaming-input library and FF fd with
>>the FF library), when any of these closes, all effects are deleted. Good
>>way to overcome this would be fd-specific effects instead of
>>process-specific, but I've got no idea how that would be done. One
>>possible way would be introducing a new device file solely for the FF
>>(so there would be no reason to hold multiple fd's to this file by the
>>same process), but would that be overkill?
>
>
> I don't think that the fact that when a process holds the device open
> twice, the first close flushes the FF effects is that big a problem.
>

Ok.

>>2. Many simpler devices do not have any effect memory, for example there
>>is just one HID report that is used to apply an effect and stop it. They
>>could share very much of their timing code (they have effect memories
>>and timers implemented in software in the kernel). These would also need
>>software handling of envelopes, which is currently not implemented at
>>all (also some effects could possibly be software emulated). So, should
>>these be implemented by the kernel at all or should they implemented in
>>the userspace library?
>
> Probably both. The timing sensitive stuff in the kernel, all the rest in
> an userspace library.
>

Hmm, that wouldn't leave much stuff into the userspace library (Effect
storage for devices without memory, converting effects with envelopes to
magnitude+time -sequences for devices without envelope support, etc).
Maybe we should implement everything in the kernel... I have to think
about it, maybe something big that should be implemented in userspace
comes to my mind.

--
Anssi Hannula

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-08 18:17    [W:0.042 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site