Re: DINPUT: Generic FF effect implementation (FF #4)
Could I get some feedback on why this has not been applied? I've got several additional patches prepared already that depend on it and if something needs to be changed I'd like to know before I get even more that do. It still applies cleanly to CVS. If it's just not being applied because it's considered dead code I can submit the other patches that actually use it. Thanks, Daniel Remenak On 8/6/05, Daniel Remenak <dtremenak(a)gmail.com> wrote:
The fourth in a series of patches to enable force feedback through DirectInput on linux event devices.
Changelog: Add a generic force feedback effect implementation
This patch includes a bunch of support code for all DirectInput FF effects, and adds stubs for a generic FF effect interface.
Details: 1. Stubs for a generic implementation of the IDirectInputEvent interface 2. Debug utility functions to dump common structures 3. Implementations of necessary object functions (e.g. AddRef, Release, QueryInterface) 4. Complete implementations of system-independent SetParameters and GetParameters
This patch adds two files, effect.c and effect_private.h, in the dlls/dinput directory. This patch depends on FF #3 in order to compile.
--Daniel Remenak
<Attachment: ff-4-effect.diff, 20K>
Daniel Remenak <dtremenak(a)gmail.com> writes:
Could I get some feedback on why this has not been applied? I've got several additional patches prepared already that depend on it and if something needs to be changed I'd like to know before I get even more that do. It still applies cleanly to CVS. If it's just not being applied because it's considered dead code I can submit the other patches that actually use it.
That would be good. The pseudo vtbl functions that are not used in a vtbl don't look right to me, but I'm not sure what you are planning to do with that. -- Alexandre Julliard julliard(a)winehq.org
Submitted #5 a couple days ago, along with a short explanation of how it all worked together. Any comments? If you'd like me to change the architecture I'm willing to do so, if you can give me some hints about what direction to go with it. If you want some other changes made, please drop some clues about what they might be. If you want to see more, I have more that can be cleaned up for submission. If you need more clarification on some issue I can give it. I just loathe sitting around wondering if these are good enough or not when I could be working more on them if they need revision or the next batch if they don't ;) --Daniel Remenak On 8/10/05, Alexandre Julliard <julliard(a)winehq.org> wrote:
Daniel Remenak <dtremenak(a)gmail.com> writes:
Could I get some feedback on why this has not been applied? I've got several additional patches prepared already that depend on it and if something needs to be changed I'd like to know before I get even more that do. It still applies cleanly to CVS. If it's just not being applied because it's considered dead code I can submit the other patches that actually use it.
That would be good. The pseudo vtbl functions that are not used in a vtbl don't look right to me, but I'm not sure what you are planning to do with that.
-- Alexandre Julliard julliard(a)winehq.org
Daniel Remenak <dtremenak(a)gmail.com> writes:
Submitted #5 a couple days ago, along with a short explanation of how it all worked together. Any comments? If you'd like me to change the architecture I'm willing to do so, if you can give me some hints about what direction to go with it. If you want some other changes made, please drop some clues about what they might be. If you want to see more, I have more that can be cleaned up for submission. If you need more clarification on some issue I can give it. I just loathe sitting around wondering if these are good enough or not when I could be working more on them if they need revision or the next batch if they don't ;)
It looks a bit overdesigned to me. With this patch you add even more infrastructure, generic interfaces, etc. and it still doesn't do anything. I'd suggest going the other way around: implement one working version of the code without worrying about being generic, without trying to abstract interfaces or anything, just a simple source file implementing the COM interface directly. Then if there's really a need for other implementations to share a lot of code we can look at abstracting parts of it. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Daniel Remenak