linuxdc-dev

[linuxdc-dev]Fishing rod

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

I know the (previous) general view about devices such as the fishing rod is 
that there should be no kernel space driver for them.

But I've just had one delivered and it appears to respond to existing drivers 
anyway (at least puru puru drives rumbling).

What is the consequence for previous plans for this?

Any thoughts?

Adrian

Re: [linuxdc-dev]Fishing rod

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

* Adrian McMenamin <ad...@mc...> on Fri, Mar 01, 2002:

> I know the (previous) general view about devices such as the fishing rod =
is=20
> that there should be no kernel space driver for them.
>=20
> But I've just had one delivered and it appears to respond to existing dri=
vers=20
> anyway (at least puru puru drives rumbling).
>=20
> What is the consequence for previous plans for this?
>=20

Like I said before, if such a "bastard" device is supported by an already
existing kernel Maple interface, then your work is already done.  Otherwise,
your interests are best served with a general purpose Maple driver that
can directly interface userapps with peculiar Maple devices.

> Any thoughts?

Remember that Maple devices export "functions" of what they can do, so the
vibration function of the fishing rod could be handled by the puru-puru
driver while the controller portion (or whatever) could be handled by the
Maple controller code (if it is indeed a controller) or by the general
purpose Maple layer.

M. R.

Re: [linuxdc-dev]Fishing rod

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

* M. R. Brown <mr...@0x...> on Fri, Mar 01, 2002:

>=20
> > Any thoughts?
>=20
> Remember that Maple devices export "functions" of what they can do, so the
> vibration function of the fishing rod could be handled by the puru-puru
> driver while the controller portion (or whatever) could be handled by the
> Maple controller code (if it is indeed a controller) or by the general
> purpose Maple layer.
>=20

Hmm, given the list of usable/existing Maple functions, wouldn't the
fishing rod have to fall into one of the following categories?

#define MAPLE_FUNC_CONTROLLER 0x001
#define MAPLE_FUNC_MEMCARD    0x002
#define MAPLE_FUNC_LCD        0x004
#define MAPLE_FUNC_CLOCK      0x008
#define MAPLE_FUNC_MICROPHONE 0x010
#define MAPLE_FUNC_ARGUN      0x020
#define MAPLE_FUNC_KEYBOARD   0x040
#define MAPLE_FUNC_LIGHTGUN   0x080
#define MAPLE_FUNC_PURUPURU   0x100
#define MAPLE_FUNC_MOUSE      0x200

Anything relevant is already handled by Maple in the kernel.

M. R.

Re: [linuxdc-dev]Fishing rod

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

On Friday 01 Mar 2002 10:33 pm, M. R. Brown wrote:

> Anything relevant is already handled by Maple in the kernel.
>
> M. R.

Possibly, though I am not sure what the winder is - a new function or just 
something that already exists repackaged?

Re: [linuxdc-dev]Fishing rod

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

* Adrian McMenamin <ad...@mc...> on Sat, Mar 02, 2002:

>=20
> Possibly, though I am not sure what the winder is - a new function or jus=
t=20
> something that already exists repackaged?
>=20

Do you have a dump of the functions reported from device info?

M. R.