libff-devel — Discussion about the development of libff

[Libff-devel] Thrustmaster Ferrari F430 Force Feedback Racing Wheel

[Liviu A. <liv...@my...>]

Dear all
I wasn't sure where else to post, so I'm trying my luck here.

I'm currently considering to buy myself a "Thrustmaster Ferrari F430 Force  
Feedback Racing Wheel" [1], and I was wondering what where my chances of  
having it work properly under Linux (Xubuntu 10.04 Lucid 64 bit). I'm new  
to the whole Racing Wheel on Linux business, so I'm not sure where things  
stand with support for this. I found this list of supported device [2][3],  
and several Thrustmaster products were in it, but not this one.

Please advise. Regards
Liviu

[1] http://www.thrustmaster.com/product.aspx?ProductID=151&PlatformID=5
[2] http://sourceforge.net/apps/mediawiki/libff/index.php?title=Main_Page
[3]  
http://sourceforge.net/apps/mediawiki/libff/index.php?title=SupportedDevices



-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: [Libff-devel] How is going libff ?

[Hans-Christoph S. <ha...@ed...>]

Unfortunately, I don't there is anything better.  I think its a project  
looking for a coder.  I'd love to see it develop further, but I don't  
have the time to do so myself.

.hc

On Jan 9, 2006, at 6:41 PM, kaouete wrote:

> Hi,
>
> I just found the existence of this project.
> Reading the mailing lists i can see it is quite un-alive.
> I was wondering if it was just abandonned by the people working on
> it (because of various reason like work, life, etc, i guess) or
> because there is something else like another better project doing
> the same thing or just that this one is in fact useless .. ..
>
> Thanks for you answer :)
>
> kaouete
>

________________________________________________________________________ 
____

"Looking at things from a more basic level, you can come up with a more  
direct solution... It may sound small in theory, but it in practice, it  
can change entire economies."
                                                     - Amy Smith

[Libff-devel] How is going libff ?

[kaouete <ka...@cr...>]

Hi,=20

I just found the existence of this project.
Reading the mailing lists i can see it is quite un-alive.
I was wondering if it was just abandonned by the people working on
it (because of various reason like work, life, etc, i guess) or
because there is something else like another better project doing
the same thing or just that this one is in fact useless .. ..=20

Thanks for you answer :)

kaouete

[Libff-devel] Re: [Libff-kernel] Wingman Force 3D in linux, not only questions.

[<py...@lo...>]

Hi,

> >>3. Identify packets describing the state of the stick. Those are not the
> >>packets you are interested in.
> >
> > Well it's lots of data, trying to find a method for not (at least not
> > fully) manual searchigh through URB-s, however joystick after startup
> > emulates spring, dou You remember (or have it written) if there are any
> > force - related information sent for this reason ?
>
> Yes, I think so. I expect it might send one single spring condition
> effect to emulate auto-center.
>
> Look for URBs similar to those sent by lgff for constant and rumble
> effects, they are similar (same endpoints, same size, only the opcode
> and the parameters change).
>

Well, I had some time to do the sniffing/log analysing this weekend, here are 
some (preliminary) results...

Bulk transfer to set force looks more or less like this:

0x 6b 6e 81 78 00 55 28 where:
first two bytes I guess could be force value - URB-s are sent pretty often for 
example for "ramp" with these bytes changed
third byte might mean constatn force (or something else, however it never 
seems to change, or I have not done enough sniffing with different parameters 
so far ;) )
4th - 6th byte - well no idea for now, they do change but not too often - 
maybe gain or something ?
7th byte - force direction (axis) ?

> >>4. look at the data when effects are played
> >
> > I thought there was some effect tester/modeller with directX (direct
> > input). I guess I was wrong (at least about directx9c), do You know
> > anything (but plain C programs I could write) that allows playing custom
> > effects ?
>
> You can get a trial version of immersion studio there:
> http://www.immersion.com/developer/downloads/IStudio/IStudio.msi
> (I can't believe they made it paying, the full version used to be
> available for free...)
>
> There should also be an effect designer with the directx sdk (not the
> runtime), I'm not sure if I dreamed it or if I actually used it :)

Thanks, I have it now. At first I downloaded too new version of dx_sdk - 
april2005 does not have Force Editor bundled - summer2004 does ;)


> >>5. Identify the packets that were not there in 2 and 1. Those are
> >>probably force-feedback packets
> >>6. Change the parameters of the effects, look at the data, guess what
> >>bytes encode what parameters
> >
> > Well, I'll try;).
> >
> >>I've already done 1 to 5, I was trying to do 6 for spring/friction
> >>effects when my stick stopped working.
> >>The packets for condition effects use the same pipe as packets for
> >>constant force, they have a similar structure as well.
> >>
> >>You might want to install cygwin so that you get access to grep, sort...
> >>they are usefull to sort and filter large anounts of data automatically.
> >
> > 1. Well, I've done some sniffing fo far but results are not yet very
> > clear, I'll have to find some reasonable method not using logitech -
> > provided tester (since it does not generate custom effects - i guess -
> > just shots, crashes and so on).
> > Is there a ready-made tool to send custom packets/sequences of packets to
> > the device, or I will have to write my own one ? (preferably linux one -
> > not to interfere with windows drivers which seem to go crazy with just
> > the sniffer).
>
> Don't know, you should check the usb-devel mailing lists (the archive,
> that's probably a common request).

I found usb-robot which should send custom packets to the device (it is based 
on libusb), however when I'm "trying to talk to device 003 on bus 004 
(idVendor 0x46d idProduct 0xc283), usb-robot-slave on my attempt:

transfer type=bulk ep=0x1 size=7 dir=out
66 78 81 7b 00 5F 03

says:

doing bulk transfer id 2 to ep 0x1, size 7, timeout 10000 frames
status: problem doing write
usb error: error submitting URB: Device or resource busy

Is the driver locking access to the device (is there a way to prevent it ?) or 
there could be another problem ?
I guess parameters I wrote should be fine, since lsusb -v says:

Bus 004 Device 002: ID 046d:c283 Logitech, Inc. WingMan Force 3D
Device Descriptor:
 bLength                18
 bDescriptorType         1
 bcdUSB               1.00
 bDeviceClass            0 (Defined at Interface level)
 bDeviceSubClass         0
 bDeviceProtocol         0
 bMaxPacketSize0         8
 idVendor           0x046d Logitech, Inc.
 idProduct          0xc283 WingMan Force 3D
 bcdDevice            1.06
 iManufacturer           4 Logitech Inc.
 iProduct               32 WingMan Force 3D
 iSerial                 0
 bNumConfigurations      1
 Configuration Descriptor:
   bLength                 9
   bDescriptorType         2
   wTotalLength           41
   bNumInterfaces          1
   bConfigurationValue     1
   iConfiguration          0
   bmAttributes         0x80
   MaxPower               80mA
   Interface Descriptor:
     bLength                 9
     bDescriptorType         4
     bInterfaceNumber        0
     bAlternateSetting       0
     bNumEndpoints           2
     bInterfaceClass         3 Human Interface Devices
     bInterfaceSubClass      0 No Subclass
     bInterfaceProtocol      0 None
     iInterface              0
       HID Device Descriptor:
         bLength                 9
         bDescriptorType        33
         bcdHID               1.00
         bCountryCode           33
         bNumDescriptors         1
         bDescriptorType        34 Report
         wDescriptorLength     130
cannot get report descriptor
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x81  EP 1 IN
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               none
       wMaxPacketSize          8
       bInterval              10
     Endpoint Descriptor:
       bLength                 7
       bDescriptorType         5
       bEndpointAddress     0x01  EP 1 OUT
       bmAttributes            3
         Transfer Type            Interrupt
         Synch Type               none
       wMaxPacketSize          8
       bInterval              10
 Language IDs: (length=4)
    0409 English(US)

> > Correct me if I'm wrong, I started looking through the linux driver, to
> > find (at least more or less what to look for). In the kernel (source), in
> > hid-lgff.c what stores effects is called "private". It's declared as a
> > void pointer in input.h and it is allocated as lgff_devices structure in
> > hid-lgff.c. When/(or maybe if) I find something useful I should fill this
> > structure's fields with propper data (like it is done int
> > privete->constant->field[0]...).
>
> Yes.
>
> > lgff_device has (among other) elements: constant and rumble, but what
> > about ramp, sine and so on? are they "struct lgff_effect effects[8]" ?
> > (or at the moment there is just no room for them ? Well, I'm just
> > starting to look through the source code to find out what and how is
> > done, so my questions might be quite silly for now ;) )
>
> Note that this device does not support non-constant effects natively
> (does not seem so at least). They are emulated by the driver by updating
> constant effects at regular intervals.
> I don't have my code at hand right now, but I guess you may want to add
> fields for parameters of periodic effects (sine, ramp...)

Well, now I see it ;) In this case I think maybe it would be more convenient 
to keep kernel side driver as-is (or with as few changes as possible, to keep 
it small) and implement more complex effects in a library... 

Michal

[Libff-devel] Re: [Libff-kernel] Wingman Force 3D in linux, not only questions.

[<py...@lo...>]

Hi

Thanks, I started playing with it. 

> My advice:
> 1. look at the usb data when nothing happens (no effect played, joystick
> not moving)

Well, I get some "init", than nothing happens.

> 2. look at the data when the joystick moves

> 3. Identify packets describing the state of the stick. Those are not the
> packets you are interested in.

Well it's lots of data, trying to find a method for not (at least not fully) 
manual searchigh through URB-s, however joystick after startup emulates 
spring, dou You remember (or have it written) if there are any force - 
related information sent for this reason ?

> 4. look at the data when effects are played

I thought there was some effect tester/modeller with directX (direct input). I 
guess I was wrong (at least about directx9c), do You know anything (but plain 
C programs I could write) that allows playing custom effects ?

> 5. Identify the packets that were not there in 2 and 1. Those are
> probably force-feedback packets
> 6. Change the parameters of the effects, look at the data, guess what
> bytes encode what parameters

Well, I'll try;).


> I've already done 1 to 5, I was trying to do 6 for spring/friction
> effects when my stick stopped working.
> The packets for condition effects use the same pipe as packets for
> constant force, they have a similar structure as well.
>
> You might want to install cygwin so that you get access to grep, sort...
> they are usefull to sort and filter large anounts of data automatically.
>


1. Well, I've done some sniffing fo far but results are not yet very clear, 
I'll have to find some reasonable method not using logitech - provided tester 
(since it does not generate custom effects - i guess - just shots, crashes 
and so on).
Is there a ready-made tool to send custom packets/sequences of packets to the 
device, or I will have to write my own one ? (preferably linux one - not to 
interfere with windows drivers which seem to go crazy with just the sniffer).

Correct me if I'm wrong, I started looking through the linux driver, to find 
(at leas more or less what to look for). In the kernel (source), in 
hid-lgff.c what stores effects is called "private". It's declared as a void 
pointer in input.h and it is allocated as lgff_devices structure in 
hid-lgff.c. When/(or maybe if) I find something useful I should fill this 
structure's fields with propper data (like it is done int 
privete->constant->field[0]...). 
lgff_device has (among other) elements: constant and rumble, but what about 
ramp, sine and so on? are they "struct lgff_effect effects[8]" ? (or at the 
moment there is just no room for them ? Well, I'm just starting to look 
through the source code to find out what and how is done, so my questions 
might be quite silly for now ;) )

Michal

[Libff-devel] Re: [Libff-kernel] Wingman Force 3D in linux, not only questions.

[Johann D. <joh...@it...>]

Micha=B3 Pytasz wrote:

> Hi,
>=20
> I'm sorry for bothering You, I hope it is the right list. So fat I read=
 most=20
> of it's history, and I guess (almost) all of what is related to logitec=
h=20
> devices.

That's the right place. It's dedicated to all discussions dealing with=20
drivers for force-feedback devices.

>=20
> I have Logitech Wingman Force 3D and I'm interested in getting to know =
how to=20
> use it in own programs, also I think I could help in driver and library=
=20
> development. Earlier I thought I have problems making it work, since on=
ly=20
> "constant force" in fftest was giving a (hardly) noticable effect. Corr=
ect me=20
> if I'm wrong, but is it the only effect implemented for this joystick (=
at=20
> least at the moment) ?

It's the only effect implemented, it will stay that way unless someone=20
else works some more on the driver.

>=20
> I started learning how to communicate with the device, I have c++ class=
=20
> "Joystick" written mostly using HID howto. For now it can only read pos=
ition=20
> from the device (periodicaly, in separate thread), output some informat=
ion=20
> about the device, set gain and autocenter - so it is very far from fini=
shed,=20
> however when it will be closer to the desired result, I think it could =
be=20
> some "beginning" for more universal library.

Yes, great!

> I would be interested in adding (or helping to add) better support for=20
> Logitech Wingman Force 3D (since it is the device I have at the moment)=
.=20
> Do You have any suggestions for beginner (not in programming, but in re=
verse=20
> engineering) on how to find joystick's abilities (and how to connect th=
em to=20
> specific commands)

When I had a working wingman 3d joystick, I used to look at the usb data=20
it sent and received in windows, using a usb packet snooper (I think the=20
name of the soft was snoopy).
I generated effects using some effects designer by immersion (see their=20
developer web pages).

My advice:
1. look at the usb data when nothing happens (no effect played, joystick=20
not moving)
2. look at the data when the joystick moves
3. Identify packets describing the state of the stick. Those are not the=20
packets you are interested in.
4. look at the data when effects are played
5. Identify the packets that were not there in 2 and 1. Those are=20
probably force-feedback packets
6. Change the parameters of the effects, look at the data, guess what=20
bytes encode what parameters

I've already done 1 to 5, I was trying to do 6 for spring/friction=20
effects when my stick stopped working.
The packets for condition effects use the same pipe as packets for=20
constant force, they have a similar structure as well.

You might want to install cygwin so that you get access to grep, sort...=20
they are usefull to sort and filter large anounts of data automatically.

>=20
> Below a little more detailed version of what I can see using ffutils.
>=20

That won't help you reverse engineer anything, unfortunately. You have=20
to look at what happens in windows.

--=20
Johann

[Libff-devel] Wingman Force 3D in linux, not only questions.

[<py...@lo...>]

Hi,

I'm sorry for bothering You, I hope it is the right list. So fat I read mos=
t=20
of it's history, and I guess (almost) all of what is related to logitech=20
devices.

I have Logitech Wingman Force 3D and I'm interested in getting to know how =
to=20
use it in own programs, also I think I could help in driver and library=20
development. Earlier I thought I have problems making it work, since only=20
"constant force" in fftest was giving a (hardly) noticable effect. Correct =
me=20
if I'm wrong, but is it the only effect implemented for this joystick (at=20
least at the moment) ?

If it is not (and I have done something wrong), first of all, my system:
Linux gentoo using 2.6.11 kernel (gentoo-sources-2.6.11-r6 - it has later=20
patches - 2.6.11.x applied)
gcc 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0,=20
pie-8.7.7)

uname -mo
x86_64 GNU/Linux
(but have tried on x86 as well, same effect)

In the kernel I have:
#
# USB Input Devices
#
CONFIG_USB_HID=3Dy
CONFIG_USB_HIDINPUT=3Dy
CONFIG_HID_FF=3Dy
CONFIG_HID_PID=3Dy
CONFIG_LOGITECH_FF=3Dy
CONFIG_THRUSTMASTER_FF=3Dy
CONFIG_USB_HIDDEV=3Dy
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=3Dy
CONFIG_KEYBOARD_ATKBD=3Dy
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=3Dy
CONFIG_MOUSE_PS2=3Dy
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=3Dy
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
CONFIG_JOYSTICK_IFORCE=3Dm
CONFIG_JOYSTICK_IFORCE_USB=3Dy
# CONFIG_JOYSTICK_IFORCE_232 is not set
CONFIG_JOYSTICK_WARRIOR=3Dm
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDDLER is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=3Dy
CONFIG_INPUT_PCSPKR=3Dm
# CONFIG_INPUT_UINPUT is not set

Whe I connect joystick dmesg shows:
usb 4-2: new low speed USB device using uhci_hcd and address 3
drivers/usb/input/hid-core.c: timeout initializing reports

=46orce feedback for Logitech force feedback devices by Johann Deneux=20
<joh...@it...>
input: USB HID v1.00 Joystick [Logitech Inc. WingMan Force 3D] on=20
usb-0000:00:10.2-2

I started learning how to communicate with the device, I have c++ class=20
"Joystick" written mostly using HID howto. For now it can only read positio=
n=20
from the device (periodicaly, in separate thread), output some information=
=20
about the device, set gain and autocenter - so it is very far from finished=
,=20
however when it will be closer to the desired result, I think it could be=20
some "beginning" for more universal library.
I would be interested in adding (or helping to add) better support for=20
Logitech Wingman Force 3D (since it is the device I have at the moment).=20
Do You have any suggestions for beginner (not in programming, but in revers=
e=20
engineering) on how to find joystick's abilities (and how to connect them t=
o=20
specific commands)

Below a little more detailed version of what I can see using ffutils.

=46irstly I tried to see if I'm using propper event device, evtest shows:
# evtest /dev/input/event4
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc283 version 0x106
Input device name: "Logitech Inc. WingMan Force 3D"
Supported events:
  Event type 0 (Reset)
    Event code 0 (Reset)
    Event code 1 (Key)
    Event code 3 (Absolute)
    Event code 4 (?)
    Event code 21 (ForceFeedback)
  Event type 1 (Key)
    Event code 288 (Trigger)
    Event code 289 (ThumbBtn)
    Event code 290 (ThumbBtn2)
    Event code 291 (TopBtn)
    Event code 292 (TopBtn2)
    Event code 293 (PinkieBtn)
    Event code 294 (BaseBtn)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value      0
      Min        0
      Max      255
      Flat      15
    Event code 1 (Y)
      Value      0
      Min        0
      Max      255
      Flat      15
    Event code 5 (Rz)
      Value      0
      Min        0
      Max      255
      Flat      15
    Event code 6 (Throttle)
      Value      0
      Min        0
      Max      255
      Flat      15
    Event code 16 (Hat0X)
      Value      0
      Min       -1
      Max        1
    Event code 17 (Hat0Y)
      Value      0
      Min       -1
      Max        1
  Event type 4 (?)
    Event code 4 (?)
  Event type 21 (ForceFeedback)
    Event code 82 (?)
Testing ... (interrupt to exit)
Event: time 1113119732.721622, type 4 (?), code 4 (?), value 65584
Event: time 1113119732.721624, type 3 (Absolute), code 0 (X), value 120
Event: time 1113119732.721624, type 4 (?), code 4 (?), value 65585
Event: time 1113119732.721624, type 3 (Absolute), code 1 (Y), value 100
Event: time 1113119732.721625, type 4 (?), code 4 (?), value -16777215
Event: time 1113119732.721626, type 4 (?), code 4 (?), value 65593
Event: time 1113119732.721627, type 4 (?), code 4 (?), value 65589
Event: time 1113119732.721627, type 3 (Absolute), code 5 (Rz), value 123
Event: time 1113119732.721629, type 4 (?), code 4 (?), value 65590
Event: time 1113119732.721629, type 3 (Absolute), code 6 (Throttle), value =
93
Event: time 1113119732.721629, type 4 (?), code 4 (?), value -16777215
Event: time 1113119732.721630, type 0 (Reset), code 0 (Reset), value 0
Event: time 1113119732.729614, type 4 (?), code 4 (?), value 65585
Event: time 1113119732.729614, type 3 (Absolute), code 1 (Y), value 99
Event: time 1113119732.729616, type 0 (Reset), code 0 (Reset), value 0
Event: time 1113119732.737613, type 4 (?), code 4 (?), value 65589
Event: time 1113119732.737613, type 3 (Absolute), code 5 (Rz), value 124
Event: time 1113119732.737614, type 0 (Reset), code 0 (Reset), value 0
Event: time 1113119732.745610, type 4 (?), code 4 (?), value 65589
Event: time 1113119732.745611, type 3 (Absolute), code 5 (Rz), value 125
Event: time 1113119732.745612, type 0 (Reset), code 0 (Reset), value 0

so I guess it's ok, but than I tried fftest, what I see after running it
# fftest /dev/input/event4
=46orce feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES

Device /dev/input/event4 opened
Axes query:
Effects: Constant
Number of simultaneous effects: 8
Upload effects[0]: Invalid argument
Upload effects[2]: Invalid argument
Upload effects[3]: Invalid argument
Upload effects[4]: Invalid argument
Upload effects[5]: Invalid argument
Enter effect number, -1 to exit

when I press 1, I get hardly noticable change in joystick force, but no oth=
er=20
numbers seem to work.=20



Thanks in advance,

Micha=B3

[Libff-devel] iforce standalone - unknown field in initializer?

[Bill P. <goa...@ya...>]

Hello,

Trying to get an ActLabs ForceRS serial wheel going.

./configure --enable-serial && make

(snip)

iforce-serio.c:162: unknown field `write_wakeup' specified in initializer

Any suggestions?
Thanks!


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: [Libff-devel] Sidewinder FF driver

[Johann D. <jo...@do...>]

Fabien Brachere wrote:
> Hello,

Hi,

> I'm new to the list, and I'm working on a Microsoft Sidewinder Force
> Feedback 2 driver (Product ID=0x001b, Vendor ID=0x045e).
> I started to study USB, HID and PID protocols and the joystick seems to
> follow PID specification.
> I implemented a skeleton driver (with latest development kernel 2.5.7)
> which do the following things:
> when insmod'ed : reset device, adjust gain, upload an arbitrary effect
> (sort of machine-gun effect sniffed from the Windows test of the
> joystick) and play it, and it works !
> when rmmod'ed : stop effect, reset device.

That sounds really interesting.

> For the moment, no IOCTL and no relation with evdev except for position
> of joystick and buttons.
> 
> The theory of operations:
> the driver uses 4 flow of data with the device: control in (for "block
> load report" and "pid pool report": see pid spec.), control out (for
> "create new effect report") , interrupt in (for joystick state (axes,
> buttons, power, optical switch)) and interrupt out for all other
> commands (set effect report, set envelope report, device gain report,
> pid device control , ....)
> 
> I've not release yet any file, because it's in early alpha stage and
> it's very dirty code, must clean up before all, implement correct data
> structures to follow PID spec...

There really is no reason to be ashamed of dirty code. I don't think any 
hacker really cares about dirtyness at such early development stages.
Several people already started to work on this subject, and I believe 
the amount of code we have seen does not reflect the total amount of 
time spent on it.
Furthermore, if you have an heart attack today, what I don't wish you, 
we lose all your work.

> I think in a few weeks (depend on the time I have), I put all of that on
> a Web site.
> 
> I've a problem with this driver: I can't insert it without rmmod hid, I
> think it's the fault of hid-input who register the device, so I can't
> register it twice. Any idea ? (without modify hid code).
> 

This is how I did for the Logitech WingMan Cordless Rumble Pad: I 
slightly modified hid.h, hid-core.c and hid-input.c to add new function 
entries.
Then I added a file called hid-ff.c where the code for force feedback 
goes. It's available in linuxconsole's CVS on sourceforge. I designed 
the framework so that other protocols could be added.
Please have a look. If you like the way it's done, please use the existing
framework. If you don't, please explain why so that we can improve it ;)

By the way, I think we should have discussions about drivers on the 
linuxconsole mailing list, and discussions about the userland force 
feedback library on libff-devel.

-- 
Johann Deneux

[Libff-devel] Sidewinder FF driver

[Fabien B. <fab...@fr...>]

Hello,
I'm new to the list, and I'm working on a Microsoft Sidewinder Force
Feedback 2 driver (Product ID=0x001b, Vendor ID=0x045e).
I started to study USB, HID and PID protocols and the joystick seems to
follow PID specification.
I implemented a skeleton driver (with latest development kernel 2.5.7)
which do the following things:
when insmod'ed : reset device, adjust gain, upload an arbitrary effect
(sort of machine-gun effect sniffed from the Windows test of the
joystick) and play it, and it works !
when rmmod'ed : stop effect, reset device.
For the moment, no IOCTL and no relation with evdev except for position
of joystick and buttons.

The theory of operations:
the driver uses 4 flow of data with the device: control in (for "block
load report" and "pid pool report": see pid spec.), control out (for
"create new effect report") , interrupt in (for joystick state (axes,
buttons, power, optical switch)) and interrupt out for all other
commands (set effect report, set envelope report, device gain report,
pid device control , ....)

I've not release yet any file, because it's in early alpha stage and
it's very dirty code, must clean up before all, implement correct data
structures to follow PID spec...
I think in a few weeks (depend on the time I have), I put all of that on
a Web site.

I've a problem with this driver: I can't insert it without rmmod hid, I
think it's the fault of hid-input who register the device, so I can't
register it twice. Any idea ? (without modify hid code).

Thanks in advance.

Fabien Brachere

Re: [Libff-devel] Re: [Vegastrike-devel] commit: improved force feedback

[Johann D. <de...@if...>]

Alexander Rawass wrote:
> Hi,
> 
> 
> On Monday 18 March 2002 09:30, you wrote:
> 
>>>Maybe it's better to leave it off, so that it can be used free?
>>>
>>It's not really my choice. There are I-Force commands to enable and
>>disable force feedback. The first application to open /dev/input/eventX
>>will enable force feedback, the last application to release it will
>>disable ff. It's not as if I manually created a spring effect. The
>>spring is created by the device itself.
>>
> 
> If FF is disabled, this spring effect comes up?
> 

Yes.

> 
>>>>>What do I have to do in the destructor to release the joystick?
>>>>>
>>>>Nothing at all.
>>>>
>>>Can I say something like 'delete effect nr. 2?' or 'clear all effects' or
>>>'reset stick'?
>>>
>>You can delete effects individually, but only those effects created by
>>your process.
>>There is no clear all effects or reset stick command. Those are
>>incompatible with the idea of concurrent access by several applications,
>>and would be merely a
>>bad work-around a bug. Bugs should not be worked around, but fixed.
>>
> 
> Then, you should verify if the process that own those effects is still 
> running.
> 
> Cause if VS crashes, the 15 effects I uploaded are still there - and if I 
> start it new, I can only upload 5 effects then.

IF VS dies, the system closes all its file descriptors. This is when 
effects are cleared from the device's memory. Or at least that's what I 
assumed the system would do.
Are you sure VS isn't still running after the crash ?

> 
> Maybe check for all effects on the device if the process is still running, 
> anytime an applications wants to upload an effect and fails?
> 

I would rather avoid that solution if possible.

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

Re: [Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Johann D. <de...@if...>]

Quick fix (not yet tested): comment the kfree(iforce) in
iforce_delete_device in iforce-main.c. It's done twice (also in
iforce_serio_connect in iforce-serio.c), which is not a good thing to do.
Grmbl. I added this kfree to fix what I thought was a memory leak.
I don't know if it will solve your problem, but that's one fewer bug at
least.

'will make a patch after further testing. That is, not tonight, because 
of &@#$ exam on a saturday morning :(

-- 
Johann Deneux

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

Re: [Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Johann D. <joh...@la...>]

Alexander Rawass wrote:
> Hi,
> 
> 
> On Monday 18 March 2002 13:37, you wrote:
> 
>>Alexander Rawass wrote:
>>
>>>Hi,
>>>
>>>I am having problems with my system, running kernel-2.4.17 with Johanns
>>>iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:
>>>
>>>Sometimes, I am getting such errors:
>>>
>>>Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
>>>Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
>>>Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
>>>
>>>This bug also seems to happen only, when the joystick isn't switched on
>>>on startup/driver installation?
>>>
>>I am puzzled  ?-/
>>
> 
> This definetely happens only when the joystick is switched off at boot/driver 
> install time.
> 
> When It's on - everything's fine.
> 

What's the scenario ?
insmod input
insmod serio
insmod serport
insmod iforce
inputattach
<switch on joystick>

You *must* allways switch the stick on *before* starting inputattach. I 
will try to have a look at what happens when timeouts occur, though. 
That should never corrupt memory.

> When it's off - kmail goes kaboom when closing a window.
> 
> See attachments for dmesg output.
> 

If you could also run ksymoops on these messages, it would be very helpful.

-- 
Johann Deneux

[Libff-devel] Re: [Vegastrike-devel] autocenter

[Alexander R. <ale...@us...>]

Hi,

On Thursday 21 March 2002 10:05, you wrote:
> >
> > Except, that my force-feedback joystick is rather unusuable with force
> > feedback disabled - because, it's too easy too steer - I never get the
> > crosshairs exactly on the target ....
>
> Did you try enabling autocenter using ffset ?

Argl.

Good point.


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Alexander R. <ale...@us...>]

Hi,


On Monday 18 March 2002 13:37, you wrote:
> Alexander Rawass wrote:
> > Hi,
> >
> > I am having problems with my system, running kernel-2.4.17 with Johanns
> > iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:
> >
> > Sometimes, I am getting such errors:
> >
> > Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
> > Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> > Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
>
> > This bug also seems to happen only, when the joystick isn't switched on
> > on startup/driver installation?
>
> I am puzzled  ?-/

This definetely happens only when the joystick is switched off at boot/driver 
install time.

When It's on - everything's fine.

When it's off - kmail goes kaboom when closing a window.

See attachments for dmesg output.





Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Libff-devel] Re: [Vegastrike-devel] commit: improved force feedback

[Alexander R. <ale...@us...>]

Hi,


On Monday 18 March 2002 09:30, you wrote:
> > Maybe it's better to leave it off, so that it can be used free?
>
> It's not really my choice. There are I-Force commands to enable and
> disable force feedback. The first application to open /dev/input/eventX
> will enable force feedback, the last application to release it will
> disable ff. It's not as if I manually created a spring effect. The
> spring is created by the device itself.

If FF is disabled, this spring effect comes up?

> >>>What do I have to do in the destructor to release the joystick?
> >>
> >>Nothing at all.
> >
> > Can I say something like 'delete effect nr. 2?' or 'clear all effects' or
> > 'reset stick'?
>
> You can delete effects individually, but only those effects created by
> your process.
> There is no clear all effects or reset stick command. Those are
> incompatible with the idea of concurrent access by several applications,
> and would be merely a
> bad work-around a bug. Bugs should not be worked around, but fixed.

Then, you should verify if the process that own those effects is still 
running.

Cause if VS crashes, the 15 effects I uploaded are still there - and if I 
start it new, I can only upload 5 effects then.

Maybe check for all effects on the device if the process is still running, 
anytime an applications wants to upload an effect and fails?


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Fwd: Re: [Libff-devel] force feedback in the future?

[Alexander R. <ale...@us...>]

----------  Forwarded Message  ----------

Subject: Re: [Libff-devel] force feedback in the future?
Date: Mon, 18 Mar 2002 11:09:45 -0300
From: Rodrigo Damazio <cu...@uo...>
To: Alexander Rawass <ale...@us...>

Alexander Rawass wrote:
>Hi,
>
>On Sunday 17 March 2002 17:18, you wrote:
>>        Btw, I'm not dead, I've been working on the PID force feedback
>>driver, since without that, I can't test libff(I only have a PID stick).
>
>What is a PID stick?

        PID means Physical Interface Device...it's the USB standard for
force feedback, which the kernel does not yet support(that's what I'm
working on though). The MS Sidewinder Force Feedback 2 is an example of
such device(and it's the one I have).

>Which types of sticks will be supported by kernel drivers in the future?

        Ideally, all of them =c) It's just a matter of someone sitting
down and writing the drivers.

>For which other types is currently ff support developed?

        I-Force.

>What should I tell a VS user, if his ff may work in the future?

        Well, for now, you can tell them I-Force works, and PID is on
its way.

>Alex

Rodrigo

-------------------------------------------------------

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Libff-devel] Re: Support for Logitech Cordless rumble pad added

[Vojtech P. <vo...@su...>]

On Mon, Mar 11, 2002 at 09:55:00AM +0100, Johann Deneux wrote:
> Vojtech Pavlik wrote:
> > On Thu, Mar 07, 2002 at 12:16:36AM +0100, Johann Deneux wrote:
> > 
> >>Hi,
> >>
> >>I've just committed a few changes to the hid code. Few changes on the 
> >>existing files, most of the code is situated in the newly added hid-ff.c 
> >>file.
> >>
> >>Please have a look at these files and make comments on the way I chose 
> >>to leave room for other force-feedback protocol implementations.
> >>
> >>I also copied the Makefile and Config.* files from kernel 2.5.5-dj1. As 
> >>those files had last been touched when kernel 2.5.1 went out, I guess 
> >>the parts that were missing from the files in the CVS tree were 
> >>additions we missed (and not removal done on purpose).
> >>
> > 
> > Hmm, just wondering - why did you do things differently than the
> > hiddev/hid-input stuff already in there? Btw, I'm considering to
> 
> What do you mean ? I see obvious differences (these objects don't do the 
> same thing), but beside that, they look quite similar to me. They add 
> their specific data hook to hid (input, hiddev, ff_private). I also add 
> a few function hooks (ff_exit, ff_event) that I could move to 
> ff_private. That's the biggest difference I see. Was that the one you 
> had in mind ?

I meant that you could use the same bitfield for the CLAIMED stuff, etc.
However, considering that you still need the hid-imput code for the
hid-ff, which means things have to be a little different.

Second thoughts, I think it's pretty much OK.

> > modularize the stuff completely, making hiddev, hid-input, and hid-ff
> > separate modules ...

> Yes, I also wondered if I should make hid-ff a module of his own. I can 
> see that I will probably need to split hid-ff when new protocols are 
> added, but I am not sure this means it should be a module of his own.
> I understand that each driver should be compilable as a module, but what
> are the rules to decide if a multi-part driver should be split into several
> modules ?
> 
> I foresee one difficulty: hid and hid-ff need to register to the input
> layer at the same time. Isn't it simpler then to leave them as one
> multi-part driver ?

Probably it is. I'd like to merge the wacom driver in later as well,
because it really *uses* HID, although for a very specific purpose of
encapsulating its own serial protocol ...

-- 
Vojtech Pavlik
SuSE Labs

Re: [Libff-devel] effect groups

[Johann D. <jo...@do...>]

Alexander Rawass wrote:
> Hi,
> 
> I had the idea that we should implement 'effect groups' in libff.

I believed that's planned. I don't know if it's in the headers, though.

> 
> Because I want to have many effects - most of them consisting of 2 or 3 
> simple effects, and they won't fit in the memory of all devices, I believe.
> 
> So libff should care take of that, allow the user to design effect groups, 
> and then libff should find out automatically which effects to stop and which 
> to play.
> 
> For VS, I would have the following effects groups:
> 
> * afterburner on
>    - jerk  0
>    - wiggle x  1
>    - wiggle y  1
> *afterburner off
>   - wiggle x  2
>   - wiggle y  2
> * bolt fired
>   - jerk 0
>   - vibrate x 2
> * shield hit 
>  - jerk  0
>   - vibrate  1
> 
> etc etc
> 
> The numbers are meant to be effect priorities, with 0 being the highest one.

Good idea.

>[...]
 >
> Some more questions:
> 
> If I get the number of effects with EVIOCGEFFECTS - what does this tell me?
> 
> a) the (maximum) number of effect that can be played at the same time
> b) the (maximum) number of effects that can be hold in memory

It does not tell much really. I should remove this ioctl from the API. 
For I-Force devices, it's the maximal number of effects that can be 
stored, which might as well be the maxmimum number of effects playable 
at the same time. Since several applications may use the device at the 
same time, nothing tells you will actually reach this number.

> 
> Do different effect types use a different amount of memory - like, you can 
> upload 20 constant effects or 10 periodic effects, because periodic effects 
> need more mem etc?

They do take a different amount of memory, indeed. However, on the 
devices I know, the amount of RAM is largely enough to contain all the 
heaviest effects.

> 
> 
> If I am getting an error when I am updating an already existing effect (when 
> I am updating too fast, I mean) - does this mean
> a) that this special effect cannot be updated at the moment or
> b) that the device cannot be updated at the moment
> 
> If a), I could try and find another slot that is currently capable of 
> updating.

It's a). This does not exclude the possibility of b), however.

-- 
Johann Deneux

[Libff-devel] effect groups

[Alexander R. <ale...@us...>]

Hi,

I had the idea that we should implement 'effect groups' in libff.

Because I want to have many effects - most of them consisting of 2 or 3 
simple effects, and they won't fit in the memory of all devices, I believe.

So libff should care take of that, allow the user to design effect groups, 
and then libff should find out automatically which effects to stop and which 
to play.

For VS, I would have the following effects groups:

* afterburner on
   - jerk  0
   - wiggle x  1
   - wiggle y  1
*afterburner off
  - wiggle x  2
  - wiggle y  2
* bolt fired
  - jerk 0
  - vibrate x 2
* shield hit 
 - jerk  0
  - vibrate  1

etc etc

The numbers are meant to be effect priorities, with 0 being the highest one.

there should be an alg to handle those effect groups like this:

playEffectGroup(groupid){
	foreach effect in effectgroup do {
		slot=findUnusedSlot(effect); // find a completely unused slot
		if(!slot){
			slot=findSlotWithLowerPriority(effect); // returns the oldest currently 
played slot with lower pri than the new effect
			if(!slot){
				slot=findSlotWithSamePri(effect); // let's try one that has got the same 
pri
				if(!slot){
					// can't play it
				}
			}
		}
		uploadEffectToSlot(slot,effect);
		playSlot(slot);
	}
}

something like that.

This would have these advantages:
		
If you want to play too much effects at the same time, or your device doesn't 
have the mem/slots, then the effect with pri 0 will get played surely - these 
are the basic effect - and if your device can take it, the other effects, too.

The player could also set a variable saying 'use only effects with pri 0' or 
so, when he's annoyed by too much of effects and wants to have simpler ones.

Some more questions:

If I get the number of effects with EVIOCGEFFECTS - what does this tell me?

a) the (maximum) number of effect that can be played at the same time
b) the (maximum) number of effects that can be hold in memory

Do different effect types use a different amount of memory - like, you can 
upload 20 constant effects or 10 periodic effects, because periodic effects 
need more mem etc?


If I am getting an error when I am updating an already existing effect (when 
I am updating too fast, I mean) - does this mean
a) that this special effect cannot be updated at the moment or
b) that the device cannot be updated at the moment

If a), I could try and find another slot that is currently capable of 
updating.



Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
http://tuxfleet.sourceforge.net http://qtreemap.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Libff-devel] herakles

[Johann D. <joh...@la...>]

Alexander Rawass wrote:
> Hi,
> 
> with the patch in attachment I could compile herakles.
> 
> Where is the CVS of herakles?
> 

It's now in libff's CVS. I imported a new directory called "herakles" at 
the top level.

-- 
Johann Deneux

[Libff-devel] Re: Xlib errors

[<jg...@pa...>]

Typically, this happens when the request stream gets corrupted.
The X server keeps track of how many requests it has seen and returns this
sequence number in replies.

This can happen a number of ways:
	1) multithreaded application not using locking properly (Xlib has
	locking for MT use, but you have to turn it on).
	2) memory trashing bug
	3) Xlib or X server error.
	4) some corruption in the data stream between the X server and client.

3) and 4) is quite rare: I'd suspect 1 or 2 to start, until proven otherwise.
			- Jim


--
Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
jg...@pa...

Re: [Vegastrike-devel] Re: [Libff-devel] force feedback in the future?

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

> Alexander Rawass wrote:
>
>> Hi,
>>
>> On Sunday 17 March 2002 17:18, you wrote:
>>
>>>        Btw, I'm not dead, I've been working on the PID force feedback
>>> driver, since without that, I can't test libff(I only have a PID 
>>> stick).
>>>
>>
>> What is a PID stick?
>
>
> PID is the protocol used by MS force-feedback sticks.
>
>>
>> Which types of sticks will be supported by kernel drivers in the future?
>>
>
> I don't know, I dropped my crystal ball on the floor yesterday ;) 
> Seriously, the status is the following:
> - IForce: fairly well supported (we say it's in the beta stage, almost 
> fully functional)
> - Logitech Cordless Rumblepad: ongoing work, not fully functional
> (timings not handlded)
> - Logitech WingMan Force 3D: I have it at home, the protocol looks 
> easy to understand, but no code working so far.
> - PID: We have the spec of the protocol, and assuming MS sticks to it, 
> it should not be too hard to support (in theory). What do you say, 
> Rodrigo ? How is it going ? 

        I've been learning the USB API...so I've been sending raw 
packets to it, without using the API or implementing ioctls...I've 
gotten it to move already..

>
>> For which other types is currently ff support developed?
>>
>> What should I tell a VS user, if his ff may work in the future?
>>
>
> You should tell him to be patient. There is no guarantee whatsoever 
> that  any other device type will be supported, although there is hope. 

        A Linux user should already know that though, just by reading 
the GPL =c)

Rodrigo

-- 
* Rodrigo Damazio
* cu...@uo.../rod...@po.../rda...@ls...
* ICQ: #3560450         Homepage: http://www.vros.com/cuddly/
* Engenharia da Computação / Laboratório de Sistemas Integráveis(LSI)
* Escola Politécnica - USP - São Paulo

[Libff-devel] Re: [Vegastrike-devel] Xlib errors

[Johann D. <jo...@do...>]

Alexander Rawass wrote:
> Hi,
> 
> I am having problems with my system, running kernel-2.4.17 with Johanns 
> iforce-patch from 3.3, my joystick attached via RS232 and XFree 4.0.2:
> 
> Sometimes, I am getting such errors:
> 
> Xlib: sequence lost (0x252aa > 0x16203) in reply type 0x8a!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x2ad55 > 0x16203) in reply type 0x87!
> Xlib: sequence lost (0x20000 > 0x16203) in reply type 0x0!
> Xlib: sequence lost (0x2ad55 > 0x16203) in reply type 0x86!
> Xlib: sequence lost (0x175bb > 0x76fa) in reply type 0x12! 
> Xlib: sequence lost (0x10700 > 0x7e8) in reply type 0x1c!
> Xlib: sequence lost (0x10000 > 0x880) in reply type 0x0!
> Xlib: sequence lost (0x103ff > 0x880) in reply type 0x0!
> Xlib: sequence lost (0x10000 > 0x880) in reply type 0x0!
> Xlib: unexpected async reply (sequence 0x89f)!
> Xlib: sequence lost (0x30c56 > 0x20d31) in reply type 0x1c!
> 

"unexpected async replies" happen when multi-threaded applications use 
multiple threads to communicate with X.
I don't know about the lost sequences.

> The application I use (kmail,galeon) quits (without me wanting it), but the 
> window stays there, frozen.
> 
> This seems mostly to happen to kmail-1.3.1/KDE-2.2 and also
> galeon-0.12 using gtk1.2/gnome-1.4.0.2 when a sub-window closes.
> 

That could be it, if the sub-window is handled by a concurrent thread.

> This doesn't seem to happen with konsole,xemacs
> 
> Are there any reported problems with XFree4.0.2/kernel-2.4.17 ?
> 
> I don't think that it has got to do anything with the iforce patch, but maybe 
> you have run into such problems with newer kernels??
> 

I ran into such problems a long time ago, even with 2.0.x kernels. I 
don't think the kernel is responsible, but I may be wrong.

> With kernel-2.4.2, that stuff didn't happen.
> 
> I've not yet tried kernel-2.4.17 without iforce-patch, I had not yet the time 
> to apply Johanns latest patch.

I don't think my latest patch would correct this.

> 
> This bug also seems to happen only, when the joystick isn't switched on on 
> startup/driver installation?
>

I am puzzled  ?-/

-- 
Johann Deneux

Re: [Vegastrike-devel] Re: [Libff-devel] Effects in space fighter games

[Johann D. <jo...@do...>]

Alexander Rawass wrote:
> Hi,
> 
> On Saturday 16 March 2002 17:02, you wrote:
> 
> 
>>>How much effects, rumbling and rattling can my stick take?
>>>
>>That depends on sticks, I guess.
>>
>>
>>>What for example, if I make effects the way that the stick rattles and
>>>rumbles most of the time, so that it get's really heavily used - won't
>>>that severely reduce the lifetime of such a stick?
>>>
>>I don't know for the stick, but it might reduce the lifetime of the nerves
>>of the player, which is way more worrying.
>>I would advise against over-using vibrations. I am no physician, but some
>>cases show their can be a danger when players play a very long time.
>>
> 
> We probably should show the player a 'force feedback can de dangerous for 
> your health or your stick' screen :-)
> 

Yes, maybe. I wouldn't say force feedback is dangerous for the stick. If 
it is, this can only be a design flaw of the device.

> 
>>>Cause I fear that my ideas might be overdoing it a bit.... :-)
>>>
> 
> At the moment, I am actually aiming in overdoing it - cause I wanna know what 
> happens when lots of effect get played etc, and how's that programmed best.
> 
> 
>>>So, general question, how should the effects feel like?
>>>
>>>
>>>>* firing lasers
>>>>
>>>a) slight jerk back
>>>b) vibrate along X
>>>c) vibrate along Y
>>>
>>>a or b or c or them alltogether?
>>>
>>a followed by b sounds nice (firing lasers is a continuous action, isn't
>>it ?)
>>
> 
> No - it gets played every time a player fires a bolt.
> 
> Beams are of course different (when I meant laser, I meant bolt)

Ah, ok, I thought you meant beams.


> 
>>>>* afterburner
>>>>
>>>a)    stick wobbles around a lot
>>>b)    harder to steer
>>>
>>>a,b, a or b?
>>>
>>I really like b.
>>
> 
> I'll try to make this:
> * afterburner on:
> 	stick jerks back
> 	stick vibrates around both axis (two periodic effects) very strong (attack) 
> and then settles for an acceptable magnitude
> * afterburner off:
> 	stick vibrates more (attack) and then drops off to nothing (fade)
> 
> That may be overdoing, but I have to know how that is programmed :-)

Right.

> 
> 
>>>>* collision
>>>>  stick jerks into a new position, stays there
>>>>
>>I don't understand this one. Are you dealing with contacts, or collisions
>>?
>>
> 
> Collisions.
> 
> This should simulate that your ship is rolling around uncontrollable around 
> some axis for some time.

... what will make it even less controllable. We can try it anyway.

> 
> 
>>>Any more ideas?
>>>
>>>I've got:  Wind
>>>
>>>Well, actually solar wind, that drives the stick in a random direction
>>>:-)
>>>
>>I don't like it. That's also an effect that reduces playability.
>>
> 
> I like the idea - more to be felt. But let's see.
> 
> 
> My problem is: XwA and Freespace2 had rather sparse effects - for them, I 
> wouldn't have bought a stick, I was rather dissappointed.
> 
> I'll overdo it now, discuss that, and then maybe downgrade :-)
> Or lots of options :-)
> 

Good idea. Some smart guy once said you knew a design was good when you 
had nothing left to take away. Let's use the same approach with effects.

-- 
Johann Deneux