
|
[haiku-development]
||
[Date Prev]
[05-2008 Date Index]
[Date Next]
||
[Thread Prev]
[05-2008 Thread Index]
[Thread Next]
[haiku-development] Re: Some questions
- From: gsc70@xxxxxxxxxxx (Greg Crain)
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 01 May 2008 15:17:11 +0000
> > -------------- Original message ----------------------
> >> > Actually there's no way to tell if a joystick is connected to a
> >> > gameport, unless some proprietary extensions I don't know of. Also,
> >> the
> >> > port support 4 axis and 4 buttons, so it is possible to have 2
> >> joysticks
> >> > with 2 axis and 2 buttons each with an Y-splitter cable; but it
> >> > doesn't work with all the ports and all the joysticks. Over the years,
> >> > makers such as Microsoft and Logitech used the game port in _very_
> >> > creative ways...
> >> >
> >> > An ideal design for a game port driver would be to just publish the
> >> > ports and just report the raw readings, then let the user create the
> >> > joystick device by let him choosing which port it is connected to.
> >> This
> >> > approach allows for different uses, back at school we used it in some
> >> > electronics projects.
> >
> >> Some clarification about "publishing devices you don't have as it does
> >> today."
> >> I was talking about the Gameport. If you don't have a Gameport it should
> >> not show two as it does today :)
> >>
> >
> > The standard Gameport is just memory mapped I/O in low address space.
> > That memory space will always be there. I'm not sure how you would
> > determine if a gameport should be published. When the gameport is being
> > used, the data in that memory will change.
> k didn't know that. But the driver for the soundblaster live gameport only
> publish the gameport if the card exist (i think) perhaps something similar
> can be used? but this would explain why the gamports are always showed in
> R5
>
I think in one of the Be newsletter, one of the engineers recommended that the
old gameport should be abandoned. It requires continuous polling of the data
ports, which is terribly inefficient and likely will slow the rest of the
system down.
As far as the SBLive and Audigy,etc.. the gameport is treated like a completely
separate device. They have their own PCI-ID, different from the soundcard ID
(you can look at Devices under R5). Ages ago, I wrote a gameport driver
for the Audigy using the generic module :-)
Greg Crain
|

|