[Plib-devel] Re: PLIB's JS and generality

[James T. <jm...@dc...>]

Alexander Perry wrote:
<SNIP>
> 1.  plib does not place an upper limit on the number of /dev/js devices,
> which is good because I've currently got eight devices declared and four
> running (and in use) at the same time.  I expect more, see below.

This was a misunderstanding on my part; I have got a new library (that
layers above JS) being discussed on the PLIB list. It will detect as
many joysticks as you like!
So you can breath out.

> 
> > > It would be nice to have the button-type controls be able to take
> > > input from a GUI widget (eg a menu entry) as well as/instead of
> > > a physical button (on mouse, keyboard or joystick) so that people
> > > who are learning (say) FGFS wouldn't have to remember that Alt-Shift-W
> > > means "tune the radio up by 1KHz" and could use the menu instead.
> 
> Yes, also need to convert combinations of buttons/menuitems into an
> emulation of an analog quantity so that people with few analog channels
> can emulate things such as throttle steps and fast sweeps easily.

This is an area I need to think about, and some input (hah!) would be
appreciated; using the 'at' functions is an issue here since my stick
reports it jas axes 4/5, but with only -1, 0 or 1 reported for each
axes. Are there stick out there where the hat is analog?

Again right now I have a total seperation of analog and digital inputs,
so for exmaple flaps is two digitals, a 'raise' and a 'lower'.
Potentially someone may desire to hook-up an analog input, BUT then we
need to specify a 'step-size', since only certain postions of the level
make sense (correct?) Similalry for spoliers.....

possibly a 'dual-mode' input which can be either digital or analog? With
a 'step-size' specified; digital moves in steps, analouge rounds to
nearest. (Or not at all if the input really is linear) And then when a
digital input is set (like 'move to max'), can lock at that position
until the analog source moves by a threshold ....

Comments?

<SNIP>
> I've currently got 12 analog channels and 15 buttons so far,
> and expect to hit about 25 analog and 100 buttons within one year.

Well these are just shortcuts : you can *USE* 0 ... n as the device
number :-)
But also defining the CTL_JS(n) macro is trivial. Personally I'm just
using raw numbers, but I thought that it might be awkward to rember
'what the '1' does' after 6 months :-)

> 
> > ctlAnalouge*
> 
> Either "Analog" for americans or "Analogue" for the europeans.
> Omitting the "u" changes the sound of the "g" so that the word
> will rhyme with "rouge".

Yah, please excuse my lack of spelling; I will convert to Yankee style I
think (dammed colonials!) [happy, Steve?]

<SNIP>
> 
> Don't forget leftbrakeCtl rightbrakeCtl propspeedCtl nosesteeringCtl
> radiovolumeCtl nextradiovolumeCtl panelinstrument[i]Ctl etc etc
> 
This list was not mean to be exhaustive. Obviously adding more axes is
trivial, the FG code was simply meant to test the PLIB library's
functioning.

> You're better off having the various control channels in the simulator
> request the joystick channels that they'd like to offer more generically.

Please explain this in more detail : the current method certainly
doesn't look pretty, but it works (kinda).

James Turner