Re: [linuxdc-dev]Microphone for Dreamcast / Dreameye camera

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

* Adrian McMenamin <ad...@mc...> on Mon, Jan 28, 2002:

> On Monday 28 Jan 2002 10:48 pm, M. R. Brown wrote:
> > * John Wiggins <lin...@ho...> on Mon, Jan 28, 2002:
> > > I take it that it would be too much trouble to look at the maple bus =
in
> > > the same light as one would for USB...
> >
> > We do ... although you have to question the intelligence of adding all
> > those Maple drivers in the kernel tree itself.  True that USB does, but=
 is
> > that necessarily the right thing to do?  USB does include mass storage,
> > audio, networking, etc. but it's a heck of a lot more organized (and
> > standardized) than Maple ever could be.  Besides, those USB drivers hook
> > into other Linux subsystems.  I can't imagine what subsystem the maracas
> > would hook into.
> >
>=20
> Well, I doubt we'll ever really have maracas drivers, but why should thes=
e be=20
> treated any differently (in terms of running as kernel code) than, say, a=
=20
> mouse, which is an utterly useless article when it comes to a Dreamcast?
>=20

Because there is provision for mice in more than one spot in the kernel.
The mouse hooks into the input subsystem via mousedev, so it's presence is
more than justified in the kernel itself.  There is no such maracasdev or
any other input mechanism that one could subscribe to that would justify a
hacked up kernel interface to the maracas.

I wasn't saying that we don't include Maple device support because it is or
isn't useful, but the argument is whether or not they are useful as kernel
drivers or userspace drivers.  IMO, if the device deviates from the
standard Maple input list and introduces a proprietary protocol that can't
be utilized sanely anywhere else in the kernel besides Maple, then support
for it belongs in userspace.  I don't know enough yet about the maracas,
dance pad, fishing rod, etc. to make that determination, but my best guess
is that they don't look like controllers to Maple.

I think in those extreme cases that a more generic Maple driver and
userspace access library would work, similar to how evdev works as a
catch-all in the input subsystem.  I do not think that we should spend time
making those devices "emulate" real Maple input devices for the sake of
coolness.  The lightgun is as hacked as I am willing to go, only because it
*must* be a hack, there is no other sane way to support it.

We've already talked about borrowing from or integrating USB and Maple, and
that is more than enough challenge by itself.

M. R.