Re: [RFC] dinput: Length can actually be 0.
On Tue, Mar 29, 2011 at 1:57 PM, Vincent Pelletier
plr.vinc...@gmail.com wrote:
(Sorry for sending to wine-patches initially, it was intended for wnie-devel.)
This fixes force feedback devices slamming for 10ms at full strength, as
attack is an absolute value, not a factor of effect level.
Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure
which combination) cause the effect to be not played (possibly played with 0-
level) on devices using the Linux iforce driver. This is the reason of the
comment in the code.
But to other drivers, such as hid-ff, this code causes the device to jump as
full strength, which was reported (to me directly) for example when playing
Live for Speed[1] with a steering wheel having strong force feedback
(Logitech G27).
My question: Is it acceptable to risk some regression for iforce driver (until
bug is identified) to fix other devices ?
I guess iforce devices also suffer from the too-strong attack/fade effect.
[1] http://www.lfs.net (demo available, I didn't try it)
---
dlls/dinput/effect_linuxinput.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c
index fbc5994..0154f49 100644
--- a/dlls/dinput/effect_linuxinput.c
+++ b/dlls/dinput/effect_linuxinput.c
@@ -606,13 +606,12 @@ static HRESULT WINAPI
LinuxInputEffectImpl_SetParameters(
else env = NULL;
if (peff-lpEnvelope == NULL) {
- /* if this type had an envelope, reset it
- * note that length can never be zero, so we set it to something
minuscule */
+ /* if this type had an envelope, reset it */
if (env) {
- env-attack_length = 0x10;
- env-attack_level = 0x7FFF;
- env-fade_length = 0x10;
- env-fade_level = 0x7FFF;
+ env-attack_length = 0;
+ env-attack_level = 0;
+ env-fade_length = 0;
+ env-fade_level = 0;
}
} else {
/* did we get passed an envelope for a type that doesn't even have
one? */
--
1.7.4.1
My 2 cents:
This patch reflects the original intent of the code. The current
values are effectively a workaround for poor behavior from the iforce
driver (at least in combination with the Wingman Force), which (six
years ago) was the only reasonably reliable FF driver on linux. It
was not clear to me at the time whether it was a driver problem or a
more general evdev issue.
This patch correctly fixes one part of bug 9221 (the part about acting
like a pneumatic hammer). As a side effect, it also disables most
FF on devices using the iforce driver.
Today, HID FF devices are far more common than iforce devices (which
AFAIK have not been manufactured since the very early 2000s). The HID
driver works well (has for years), and works as documented (for
instance, that patch works, as it should). I think making FF usable
for HID devices is worth it; perhaps it will even spur someone to fix
envelope support for the iforce driver.
Regards,
Daniel Remenak
Re: dinput: Add effect gain support
On Mon, Jan 19, 2009 at 12:52 PM, Vincent Pelletier plr.vinc...@gmail.com wrote: dinput: Add effect gain support -- Vincent Pelletier Vincent, This patch is ok as far as it goes, but not completely correct. Firstly, SetParameters needs to apply the parameters to effects while they are playing, not just store them. Existing parameters are all part of the effect structure, so that is taken care of automatically. Since gain is handled by a different mechanism, you also need to handle the while-playing case (unless DIEP_NODOWNLOAD is specified). This probably means you need to implement GetEffectStatus, since you won't want to apply the gain unless the effect is playing. Secondly, the kernel's ff.txt suggests that evdev handles the gain globally for the device. Since the DirectInput definition of gain is per-effect rather than per-device, you should also test what happens when you set the gain differently in two simultaneously-playing effects on the same device. If Windows mixes them (i.e. truly applies the gain per-effect) then we need to come up with some logic to do the same (probably by scaling the effect envelope or magnitude, depending on the effect type, and keeping it updated when the user modifies the scaled parameters). Thirdly, SetParameters still has a comment that says gain and sample periods aren't supported. Please update any applicable comments when you update the code - outdated comments are worse than no comments at all. Regards, Daniel Remenak
Re: [PATCH 2/5] dinput: Stop and unload effect when freeing it.
On Sat, Jul 5, 2008 at 9:24 PM, Vitaliy Margolen [EMAIL PROTECTED] wrote: snip +LinuxInputEffectImpl_Stop(iface); +LinuxInputEffectImpl_Unload(iface); snip Vitaliy, Native behavior is for Unload to stop the effect also (see msdn or test it yourself), so the call to Stop here is unnecessary. If the call to Stop is required, it must be done in Unload, not Release, as it's not unusual to unload an effect without releasing it when a game has a large number of available effect instances. It is my understanding that no explicit call to Stop is needed, either in Release or Unload, as evdev has the same behavior documented (see section 3.3 of ff.txt in the kernel docs). The call to Unload is certainly correct, and I don't think there's anything strictly wrong with calling Stop; just make sure it's not covering up a bug in Unload. Regards, Daniel Remenak
Re: RICHED20: EM_SETTEXTEX must support RTF strings too
When you fix bugs that are documented in comments, please fix the comments also. At the top of the file: EM_SETTEXTEX 3.0 (no rich text insertion handling, proper style?) And in the case itself /* FIXME: this should support RTF strings too, according to MSDN */ Thanks, Daniel Remenak On 10/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Another fix for Zoiper (www.zoiper.com). This app can display an About dialog with a richedit control that displays program credits. The text is a RTF string pasted with EM_SETTEXTEX, which should result in formatted text being displayed, but instead results in raw display of RTF codes. The attached patch fixes this. Changelog: * EM_SETTEXTEX should also support RTF strings, just like WM_SETTEXT
Re: Are *any* games as popular as World of Warcraft?
No other single game has the market penetration and staying power of WoW as things stand. XFire collects statistics[1] from their (large) network, if you're interested in minutes played as opposed to copies sold.Be aware that it's not a random sample, though; some game communities (like Call of Duty) have a proportionally large XFire presence compared to others. As far as subscriber-driven MMORPGs go, MMOGCharts[2] is another reasonable source of statistics (note that Guild Wars and certain other MMOGs are not subscriber driven, so they won't show up on their lists). [1] http://www.xfire.com/cms/stats/ [2] http://www.mmogchart.com/Chart7.html --Daniel Remenak On 10/1/07, Dan Kegel [EMAIL PROTECTED] wrote: I spent some time noodling around looking at what games are really popular (I wouldn't know firsthand, I don't play much). There's some data at http://www.amazon.com/gp/bestsellers/videogames (click on PC Games). I tried to cross-check titles with Google Trends to see which ones seem enduringly popular, but I haven't found any that beat World of Warcraft yet: http://www.google.com/trends?q=world+of+warcraft%2C+guild+wars%2C+tomb+raider%2C+bioshock%2C+half-life+2 Is Google search popularity a bad measure, or does it reflect the public's mood well? - Dan
Re: DIB Engine, some summarization
On 2/11/07, Damjan Jovanovic [EMAIL PROTECTED] wrote: What about the case where you draw with GDI, then render with OpenGL on top of that, then draw on top of that with GDI, then swap buffers? If you draw only client-side, you have to copy to the server, then copy back, then copy to the server *again*. You have to upload or download the image *every time* you go between OpenGL and GDI drawing, whereas when you draw with X11, there is no uploads/downloads unless you use DIB sections and draw directly. Not that it's relevant to this conversation (since wine needs to support legacy apps), but just so you know, even Microsoft no longer supports this sample scenario. Drawing with GDI over OpenGL (or DX), and reading from the GDI buffer on a hardware-accelerated window, are both undefined (officially not supported) operations on Windows Vista. Caused a ton of problems for my company's product. I can't directly quote what our nVidia rep sent to us (for legal reasons), but this link might be helpful: http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx --Daniel Remenak
Re: DIB Engine, some summarization
On 2/12/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: On 2/11/07, Damjan Jovanovic [EMAIL PROTECTED] wrote: What about the case where you draw with GDI, then render with OpenGL on top of that, then draw on top of that with GDI, then swap buffers? If you draw only client-side, you have to copy to the server, then copy back, then copy to the server *again*. You have to upload or download the image *every time* you go between OpenGL and GDI drawing, whereas when you draw with X11, there is no uploads/downloads unless you use DIB sections and draw directly. Not that it's relevant to this conversation (since wine needs to support legacy apps), but just so you know, even Microsoft no longer supports this sample scenario. Drawing with GDI over OpenGL (or DX), and reading from the GDI buffer on a hardware-accelerated window, are both undefined (officially not supported) operations on Windows Vista. Caused a ton of problems for my company's product So IDirect3DSurface9::GetDC does not work any longer? (Or IDirectDrawSurface7::GetDC) /me parties! Unfortunately, no; it looks like you can still render GDI onto a DX surface, just not directly onto a window which is also being rendered to by DX. From the linked blog article: Note that there is an alternative that can often work for an application -- DirectX is capable of handing back a DC to a DirectX surface, and applications can perform GDI rendering to that DC. From the DWM's perspective, that DirectX surface remains purely rendered by DirectX, and all is well. --Daniel Remenak
Re: fix for the winemp3 module
I thought at first you just diff:ed the file against mplayer's code however, as mplayer's uses the old mpglib code, one could also ask mplayer's team to release the diffs they made to mpglib as LGPL (which they have to...) They don't have to (although it would certainly be kind of them to do so, particularly in this case). Section 3 of the LGPL states: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. --Daniel Remenak
Re: wine audio testing results
On 5/19/06, Tom Booker [EMAIL PROTECTED] wrote: I hope you dont take this to be directed at you, Stu, but I need to say something, and yours was a good example. PLEASE!! Anyone that is reading this, do not paste your console output! I cannot read it in my gmail web interface, because I have a tiny monitor ( 14.1 which is like around 13 viewable), so I have to use 640x480 for my resolution in order to be able to see anything, and then the adverts for the web interface cut everything off halfway. Again, I ask everyone to please attach console output, do not paste it in either bugs on bugzilla, nor here. No offense intended, but Stu's message DID have two attachments. If you don't believe me, click on his message, then More Options, then Show Original, and you'll find two text file attachments in encoded in base64. The fact that gmail chooses not to tell you they're attachments and displays them inline stems from the fact that they have a content-type of text/plain. I don't know of any options to disable that behavior. --040006020306030603060203 Content-Type: text/plain; name=winetest-alsa.out Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=winetest-alsa.out
Re: Question about copyright lines
On 3/3/06, Segin [EMAIL PROTECTED] wrote: Aric Cyr wrote: Marcus Meissner meissner at suse.de writes: On Fri, Mar 03, 2006 at 03:20:48PM +0100, Stefan Dösinger wrote: Hello, At the top of every fine there's are some Copyright year name lines, listing the persons who have contributed to a file, and when. Are there any specifc rules about that? If you reverse the name and year, the copyright is invalid and unenforcable in the United States and many European states. In the United States and the United Kingdom, that is certainly not true, and probably not in any other Berne Convention country (Since the Berne Convention prohibits formal requirements that affect the exercise and enjoyment of the copyright, the United States changed its law on March 1, 1989, to make the use of a copyright notice optional.). See http://www.copyright.gov/circs/circ03.pdf and http://www.copyright.gov/fls/fl100.html for the United States, and http://www.patent.gov.uk/copy/indetail/copyclaim.htm and http://www.intellectual-property.gov.uk/faq/copyright/index.htm for the UK. The use of a copyright notice is no longer required under U.S. law, although it is often beneficial. (circ03) Although a few countries require that a work be marked with the international (c) mark followed by the name of the copyright owner and year of publication, this is not essential in most countries, including the UK. (copyclaim) All the Western European countries, the USA and Russia belong to the Berne Convention which does not even require your work to be marked in any way for automatic protection to apply. (copyright faq) In the U.S., The notice for visually perceptible copies should contain three elements. They should appear together or in close proximity on the copies. The elements are: 1 The symbol (c) (the letter C in a circle), or the word Copyright, or the abbreviation Copr.; and 2 The year of first publication...and... 3 The name of the owner of copyright in the work, or an abbreviation by which the name can be recognized, or a generally known alternative designation of the owner. (circ03) The elements just need to be in close proximity for the notice to be valid...and the notice itself is not strictly necessary for copyright protection, it's just useful for the lawyers if it gets challenged. (e.g. There may still be instances, such as the defense of innocent infringement, where the question of proper notice may be a factor in assessing damages in infringement actions...The omission of notice does not affect the copyright protection, and no corrective steps are required if the work was published on or after March 1, 1989. (fl100)). For protection in countries which are signatories to the UCC but NOT the Berne Convention (I don't know of any offhand), the year and name do need to be in a specific order, AND you must also include the C-in-a-circle symbol (c). To guarantee protection for a copyrighted work in all UCC member countries, the notice must consist of the symbol (c) (the word Copyright or the abbreviation are not acceptable), the year of first publication, and the name of the copyright proprietor. (circ03) Disclaimer: This message does not constitute legal advice. --Daniel Remenak
Re: Licensing question
Dan Kegel is correct. You can create a DLL containing LGPL code and load it from a proprietary application, as long as the source to the DLL is distributed. From the LGPL Preamble: This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. --Daniel Remenak On 1/4/06, Dominic Wise [EMAIL PROTECTED] wrote: Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible. Anyone else have any thoughts on this? The 'inspiration' route seems like cheating to me. I would much rather simply use the Wine code in a way that is compatible with the LGPL, if this is possible. If not, I probably just won't tell the developer working on this where to find the Wine code.
Re: josystick driver layer and support of multiple devices of one kind
On 12/14/05, Christoph Frick [EMAIL PROTECTED] wrote: - check also winmm out for the joystick relevant drivers * see if there is support for both kind of joysticks * see if there is support for multiple devices WinMM under wine supports only /dev/js devices. It does support multiple devices, with some limitations. Under wine, winmm joysticks are hard mapped as JOYSTICKID1 to /dev/js0 and so on. It's possible to end up with ID1 usable and ID2 not, or vice versa. It's even theoretically possible to end up with neither ID1 nor ID2 usable if your joystick is connected to /dev/js2 or higher, although I'd rate the chances of that actually happening as slim to none. Dinput joysticks are even worse as far as multiple devices, since they just iterate through, take the first working one they find, and call it the wine joystick. If you want to make multiple joysticks work correctly you'll have to write quite a bit of new code, there's no way around it. - put all the logic how to access the joystick hardware away from dinput.dll and utilize winmm - extend the support for multiple devices, for the parts where it is not yet working Please be aware that the DInput devices (both abstractly and the current wine implementations) contain significant additional functionality that the multimedia devices do not. Using winmm as a base for dinput is probably not practical without significant reworking; it simply doesn't do enough. Force feedback comes to mind. I'm not sure quite what stick everything in a single driver, and handle the complexity here means, but there are a couple things to be aware of: 1. It should be possible to use more than one type of device simultaneously. E.g. I might have a /dev/js* device not registered by /dev/input/*, and a /dev/input/* device not registered by /dev/js*. I should be able to pick between them without hassle (e.g. they should both be reported to the application). DInput does this now, by having two separate drivers for /dev/js* and /dev/input/*. This may be even more important in the future with both joystick capabilities on other platforms (BSD, OSX, whatever), and with other interfaces on the various platforms (XInput, SDL, whatever). 2. The two extant dinput joystick backends are quite similar and have a lot of code duplication...this is what you noticed when you were moving stuff between them. Bear in mind that not all possible joystick backends will share as much code; /dev/js* and /dev/input/* were _designed_ at the kernel level to have similar interfaces. From experience writing code that uses FreeBSD's USB HID for joystick access, there is very little in common between it and the linux interfaces. XInput is even more different. --Daniel Remenak
Re: [msvcrt] how to handle msvcr*.dll ?
On 11/27/05, Raphael [EMAIL PROTECTED] wrote: Hi, since visual studio .net (2002,3,5) MS provides newer versions of msvcrt: - msvcr70.dll - msvcr71.dll - msvcr80.dll ... (and same equivalents for msvcp*.dll) how we will handle that on wine: - creating new dll forlders and using forwards to current msvcrt.dll or - creating only new .spec files on msvcrt folder ? Regards, Raphael See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp Particularly the section What is the difference between msvcrt.dll and msvcr71.dll? Copied here in case the URL changes: The msvcrt.dll is now a known DLL, meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components. An application should use and redistribute msvcr71.dll, and it should avoid placing a copy or using an existing copy of msvcr71.dll in the system directory. msvcr## and msvcp## are not system dlls, they're application dlls. msvcrt.dll *is* a system dll. It wouldn't make sense for us to create msvcr##/msvcp##, since they are supposed to be distributed by the application and not even placed in the system directory. Windows does not and will not distribute them, and neither should wine. --Daniel Remenak
Re: respect ph.dwHow on SetProperty and some other transfers from joystick_linux.c
@@ -859,15 +939,14 @@
JoystickImpl *This = (JoystickImpl *)iface;
intxfd = This-joyfd;
inti,axes,buttons;
-intwasacquired = 1;
TRACE(%p-(%p)\n,iface,lpDIDevCaps);
-if (xfd==-1) {
+
/* yes, games assume we return something, even if unacquired */
- JoystickAImpl_Acquire(iface);
- xfd = This-joyfd;
- wasacquired = 0;
+ if (xfd==-1) {
+ IDirectInputDevice8_Acquire(iface);
}
+
lpDIDevCaps-dwFlags = DIDC_ATTACHED;
if (This-dinput-dwVersion = 0x0800)
lpDIDevCaps-dwDevType = DI8DEVTYPE_JOYSTICK |
(DI8DEVTYPEJOYSTICK_STANDARD 8);
@@ -885,15 +964,20 @@
lpDIDevCaps-dwAxes = axes;
lpDIDevCaps-dwButtons = buttons;
-if (!wasacquired)
- JoystickAImpl_Unacquire(iface);
+ if (xfd==-1) {
+ IDirectInputDevice8_Unacquire(iface);
+ }
return DI_OK;
}
What's up with the change from JoystickAImpl_Acquire to
IDirectInputDevice8_Acquire?
It will break this function; in the middle of GetCapabilities is
axes=0;
for (i=0;iABS_MAX;i++) if (test_bit(This-absbits,i)) axes++;
buttons=0;
for (i=0;iKEY_MAX;i++) if (test_bit(This-keybits,i)) buttons++;
if (This-has_ff)
lpDIDevCaps-dwFlags |= DIDC_FORCEFEEDBACK;
absbits, keybits, and has_ff are all set properly only when the
joystick is acquired with JoystickAImpl_Acquire. absbits and keybits
are also set during joydev_have, but if you have more than one device
they may not be set for the correct device unless you explicitly
acquire it. has_ff is not set at all until the stick is acquired.
Re: dinput force feedback header detection
The patch to fix that error is at http://www.winehq.org/pipermail/wine-patches/attachments/20050903/636b08f6/protect-ff-status.diff The headers are correctly detected but the use of the constants was not protected. --Daniel Remenak On 9/5/05, Jesse Allen [EMAIL PROTECTED] wrote: Hi I got this compile error from current cvs: make[2]: Entering directory `/home/jesse/.local/build/wine/dlls/dinput' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o joystick_linuxinput.o joystick_linuxinput.c joystick_linuxinput.c: In function `alloc_device': joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first use in this function) joystick_linuxinput.c:305: error: (Each undeclared identifier is reported only once joystick_linuxinput.c:305: error: for each function it appears in.) joystick_linuxinput.c: In function `joy_polldev': joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use in this function) joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': joystick_linuxinput.c:1182: warning: unused variable `dei' joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': joystick_linuxinput.c:1266: warning: unused variable `dei' make[2]: *** [joystick_linuxinput.o] Error 1 make[2]: Leaving directory `/home/jesse/.local/build/wine/dlls/dinput' make[1]: *** [dinput] Error 2 make[1]: Leaving directory `/home/jesse/.local/build/wine/dlls' make: *** [dlls] Error 2 Apparently the linux/input.h version 2.4.31 does not have support for force feedback. I've installed headers for 2.6.12.5 and now have it compiled. So something might need to be done to improve detection, else others still running 2.4 will get this error. Jesse
Re: DINPUT: Generic FF effect implementation (FF #4)
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 [EMAIL PROTECTED] wrote: Daniel Remenak [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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
Re: DINPUT: Detect force feedback joysticks (FF #1)
Executive summary: In order for effects to be played, the correct
ff_effect structure will need to be present; if you can't play the
effects it's better not to detect the joystick as FF, because it's
really not.
The structure is not used *yet*, but will be. There was an older
version of force feedback code before (in some of the stock 2.4
kernels) which had some of the same features (such as the EV_FF bit),
but has incompatible structures, and afaik there were never any force
feedback drivers written for it. The newer interface has working
iForce (logitech, guillemot, et al) and MS sidewinder drivers written
for it, so that's the one I was targetting. You can see them side by
side if you have linux/input.h from an unpatched late 2.4 kernel and a
2.6 kernel.
E.g. from 2.4.29:
struct ff_effect {
__u16 type;
__s16 id;
struct ff_trigger trigger;
struct ff_replay replay;
union {
struct ff_constant_effect constant;
struct ff_periodic_effect periodic;
struct ff_interactive_effect interactive;
} u;
};
and from 2.6.11:
struct ff_effect {
__u16 type;
__s16 id;
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
union {
struct ff_constant_effect constant;
struct ff_ramp_effect ramp;
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
} u;
};
Both versions have the same version define, but code for one will
obviously not compile with the other. Testing for ff_effect.direction
was the most direct way I could think of of differentiating the two.
The code in FF #1 and #2 will theoretically work on either version,
it's true...but detecting that a joystick has FF is not much use if
you can't play any effects on it.
--Daniel Remenak
On 28 Jul 2005 12:56:19 +0200, Alexandre Julliard [EMAIL PROTECTED] wrote:
Daniel Remenak [EMAIL PROTECTED] writes:
1. Configure checks for the availability of a new enough linux/input.h
to support force feedback. This pretty much means any kernel 2.6 or
kernel 2.4.x with the ff patchset found at
http://sourceforge.net/projects/libff/. Some of the structures were
changed without changing the version define, so this check is
necessary.
Why do you need to check the structure since you are not using it?
Shouldn't you simply do a #ifdef on the ioctl code or whatever else
that you use and may not be defined?
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: DINPUT: Detect force feedback joysticks (FF #1)
Yes, I saw your (perhaps old) patch for adding FF support to joydev while I was doing some research before starting this project. I was under the impression that the current Sidewinder PID driver was working, though...a bit of poking at the code tells me I was pretty wrong :) I use a Wingman Force personally, so I hadn't done much looking at the PID side of things. --Daniel Remenak On 7/28/05, Anssi Hannula [EMAIL PROTECTED] wrote: Daniel Remenak wrote: The newer interface has working iForce (logitech, guillemot, et al) and MS sidewinder drivers written for it, so that's the one I was targetting. Well, if you mean the Sidewinder Force Feedback 2, that driver seems to be only a stub. I am currently working on a new PID FF driver (which will cover that Sidewinder). Also I'm planning some kernel internal FF interface updates and probably introducing FF interface to /dev/input/jsX also. -- Anssi Hannula
Re: OLEAUT32: Don't crash on divide by zero
IEEE floating point has a special zero value. See http://stevehollasch.com/cgindex/coding/ieeefloat.html in the Special Values section. You can compare against this value, and (a - a) = 0.0f. You do lose that precision when you introduce multiplication and division...so you might end up with ((b * a) / b - a) != 0...which is why everyone warns against comparing with zero. Nevertheless, 5.0f / 0.0f will still trigger a divide by zero error, and that can be avoided by checking the denominator against 0 (which is what this patch does). On Apr 11, 2005 1:06 PM, Marcus Meissner [EMAIL PROTECTED] wrote: On Mon, Apr 11, 2005 at 12:47:22PM -0700, Daniel Remenak wrote: Changelog: Return DISP_E_DIVBYZERO instead of crashing when asked to divide a variant by zero. You cannot really compare floats against 0 I think. Ciao, Marcus
