linuxdc-dev

[linuxdc-dev]Puru puru driver

[Adrian M. <ad...@mc...>]

This seems very easy to do and is almost 'done' in the sense I have written a 
driver that spins this thing around.

Can anyone tell me what functions the puru does - ie does it just rock for 
variable amounts of time or does it do something more?

Adrian

Re: [linuxdc-dev]Puru puru driver

[Adrian M. <ad...@mc...>]

On Sunday 10 Feb 2002 1:21 pm, Adrian McMenamin wrote:
> This seems very easy to do and is almost 'done' in the sense I have written
> a driver that spins this thing around.
>
> Can anyone tell me what functions the puru does - ie does it just rock for
> variable amounts of time or does it do something more?
>
> Adrian
>

Having played "Sonic Adventure" a bit I have come to the conclusion it just 
rocks about (a lot of money for a computer driven motor, but that's another 
story).

The thing is - I cannot find a standard API/IF for this sort of thing for 
Unix/Linux. I could write a custom one, but what's the point of that?

If the idea is to have games/software that is as portable as possible then it 
doesn't make sense.

Should this be classed as an "input" device - when it only does output? Any 
clues anyone...

Adrian

Re: [linuxdc-dev]Puru puru driver

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Sun, Feb 10, 2002:

>=20
> Having played "Sonic Adventure" a bit I have come to the conclusion it ju=
st=20
> rocks about (a lot of money for a computer driven motor, but that's anoth=
er=20
> story).
>=20
> The thing is - I cannot find a standard API/IF for this sort of thing for=
=20
> Unix/Linux. I could write a custom one, but what's the point of that?
>=20

Look for the ruby module of the Linux Console project
(linuxconsole.sf.net).  It contains a working FF api for 2.5.  I don't know
how feasible it would be to backport it to 2.4 or if such a port already
exists - you may want to contact the FF author.

M. R.

Re: [linuxdc-dev]Puru puru driver

[Adrian M. <ad...@mc...>]

On Sunday 10 Feb 2002 5:41 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Feb 10, 2002:
> > Having played "Sonic Adventure" a bit I have come to the conclusion it
> > just rocks about (a lot of money for a computer driven motor, but that's
> > another story).
> >
> > The thing is - I cannot find a standard API/IF for this sort of thing for
> > Unix/Linux. I could write a custom one, but what's the point of that?
>
> Look for the ruby module of the Linux Console project
> (linuxconsole.sf.net).  It contains a working FF api for 2.5.  I don't know
> how feasible it would be to backport it to 2.4 or if such a port already
> exists - you may want to contact the FF author.
>
> M. R.


It's already in the input.h that comes with the latest LinuxDC/SH sources - 
so the answer is - yes, treat it as an input device - and then I can 
implement a very much paired down version of the API (as it does far more 
than seems to be supported by the iForce devices which this is modelled on).

I hadn't thought to look directly in the existing 2.4 sources, but its 
there....

RE: [linuxdc-dev]Puru puru driver

[RC5Stint <rc5...@ya...>]

> The thing is - I cannot find a standard API/IF for this sort 
> of thing for Unix/Linux. I could write a custom one, but what's 
> the point of that?

If a custom API is generic enough and usable enough, it soon becomes
a standard.  Look what happened with IrixGL. :-)

I seem to remember an article on force feedback devices from MIT
Media Lab a few months ago, on an Assoc. of Computing Machinery
magazine (most probably Communications of the ACM.)  The article
claimed force feedback can be used along with sound cues and speech
synthesis, to successfully guide the blind when using a GUI'ed
computer.  The article referred to a mountain of previous Media Lab
research on the subject, most of it on ACM and IEEE publications.

> If the idea is to have games/software that is as portable 
> as possible then it doesn't make sense.

Sure it does!  To make the API portable and generic enough, take a
look at force feedback APIs in other game console and PC platforms,
or just examine the behavior of similar devices in other gaming
platforms (N64 Rumble Pak, PS1 DualShock, PS2 DualShock 2, etc.)

The PS2 Linux kit supports the Dual Shocks through some API.  The
source code to the kit is GPL'ed, and is available from several
places without having to buy a PS2 nor the kit (email me privately
for some URLs.)  Also, someone recently reversed engineered the PS2
Dual Shock 2 API for native PS2 deving.  I can email you the tarball
if you want it.

Did you look in Mac land?  They're usually on the ball with the human
interface side of things.  But I don't yet know where to look for Mac
API docs (maybe the Darwin site has force feedback device driver
sources or API docs?)

Force feedback devices were all the rage these past few years in
Windows game land.  Maybe you could look in MSDN for helpful hints
from DirectX.  Don't look to hard, or you might borrow some useless
Microsoftism we could do without.

After all this research, just provide an API for this type of device,
make it portable and generic enough, and leave it to UI and
application developers to worry about what to do with it.  Don't
sweat it if you yourself can't find a *nix use for the device.

> Should this be classed as an "input" device - when it 
> only does output? Any clues anyone...

Take a break and shug a beer (or two, or three.)  You've been
thinking too hard. :-)

Not trying to insult you, but if it only does output, it's obviously
an output device, dude.

- --
RC5Stint <rc5...@ya...>
PGP Key ID: 0x3B4BEC6F

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32) - WinPT 0.5.1
Comment: For info see http://www.gnupg.org

iD8DBQE8ZuJtifMcQztL7G8RArNvAJoC25ACl2ndAAwsjhRv+TkRzYv9+ACdFstJ
rKw1h332n3nqVgxe8STxxos=
=sffX
-----END PGP SIGNATURE-----

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [linuxdc-dev]Puru puru driver

[M. R. B. <mr...@0x...>]

* RC5Stint <rc5...@ya...> on Sun, Feb 10, 2002:

>=20
> After all this research, just provide an API for this type of device,
> make it portable and generic enough, and leave it to UI and
> application developers to worry about what to do with it.  Don't
> sweat it if you yourself can't find a *nix use for the device.
>=20

Fortunately he's saved from such a trek, since this API does exist in 2.4
already :P.

>=20
> Take a break and shug a beer (or two, or three.)  You've been
> thinking too hard. :-)
>=20

Shoot, at the pace he's going he'll have all Maple devices accounted for in
the next few weeks!

> Not trying to insult you, but if it only does output, it's obviously
> an output device, dude.
>=20

/me comes to Adrian's defense...

Technically yes, but in the conventional sense vibration units are usually
built into the joystick device.  Sega's like the only group insane enough
to physically abstract that implementation, but it still belongs to the
input API, since it follows that general model.

M. R.

Re: [linuxdc-dev]Puru puru driver

[Adrian M. <ad...@mc...>]

On Sunday 10 Feb 2002 9:59 pm, M. R. Brown wrote:
> * RC5Stint <rc5...@ya...> on Sun, Feb 10, 2002:
> > After all this research, just provide an API for this type of device,
> > make it portable and generic enough, and leave it to UI and
> > application developers to worry about what to do with it.  Don't
> > sweat it if you yourself can't find a *nix use for the device.
>
> Fortunately he's saved from such a trek, since this API does exist in 2.4
> already :P.
>
> > Take a break and shug a beer (or two, or three.)  You've been
> > thinking too hard. :-)
>
> Shoot, at the pace he's going he'll have all Maple devices accounted for in
> the next few weeks!
>
> > Not trying to insult you, but if it only does output, it's obviously
> > an output device, dude.
>
> /me comes to Adrian's defense...
>
> Technically yes, but in the conventional sense vibration units are usually
> built into the joystick device.  Sega's like the only group insane enough
> to physically abstract that implementation, but it still belongs to the
> input API, since it follows that general model.
>
> M. R.
Oops didn't finsh that last one...



When you consider that there are people out their dealing with devices where 
feedback goes both ways having this as an input device makes perfect sense - 
its just a very limited example of a larger class of devices.


Adrian

Re: [linuxdc-dev]Puru puru driver

[Adrian M. <ad...@mc...>]

Unfortunately the API for this is a little more complex (or powerful if you 
prefer) than I first thought, so there won't be any diver tonight.

Will be in the next few days though.

What I'd really like to do is get the microphone driver working.... but that 
remains a case of so near, yet so far.


Adrian

Re: [linuxdc-dev]Puru puru driver

[Adrian M. <ad...@mc...>]

On Sunday 10 Feb 2002 9:59 pm, M. R. Brown wrote:
> * RC5Stint <rc5...@ya...> on Sun, Feb 10, 2002:
> > After all this research, just provide an API for this type of device,
> > make it portable and generic enough, and leave it to UI and
> > application developers to worry about what to do with it.  Don't
> > sweat it if you yourself can't find a *nix use for the device.
>
> Fortunately he's saved from such a trek, since this API does exist in 2.4
> already :P.
>
> > Take a break and shug a beer (or two, or three.)  You've been
> > thinking too hard. :-)
>
> Shoot, at the pace he's going he'll have all Maple devices accounted for in
> the next few weeks!
>

That's setting me up for a fall - I only started on this one because I'd 
reached a deadend with the mic :->

> > Not trying to insult you, but if it only does output, it's obviously
> > an output device, dude.
>
> /me comes to Adrian's defense...
>
> Technically yes, but in the conventional sense vibration units are usually
> built into the joystick device.  Sega's like the only group insane enough
> to physically abstract that implementation, but it still belongs to the
> input API, since it follows that general model.
>
I talked to the author of the kernel FF API and I think he was pretty 
surprised about the brain dead nature of Puru Puru (ie there seems to be 
little flexibility in terms of cpu->user and nothing from user->cpu.

When you consider that there are people out their dealing with 


> M. R.