Re: [Plib-devel] Saitek X52 joystick with 34 buttons

[John D. <sf...@av...>]

Back in December of '05 Trammell Hudson wrote:
>> I"ve recently started using a Saitek X52 joystick with my Linux box and
>> have run into problems with plib"s JS module limitation in the number
>> of supported buttons. It only supports up to 32 buttons due to the
>> MAX_BUTTONS definition and the fact that it uses an int to store the
>> button state, but the X52 has 34 buttons (and 12 axes).

On 2005-05-04 14:20 Steve Baker replied:
> 
> That"s practically a keyboard!

No, it's not a keyboard.

Do you have any idea how many switches and knobs there are in a
real airplane?

It looks like we may be approaching a culture clash:
 -- gamer viewpoint, versus
 -- flight instructor viewpoint.

Hint:  I'm coming from the flight instructor viewpoint.  There
are reasonable people in this world who want to build PC-based
flight simulators that are good enough to ... well ... to simulate
flight.  You know, flight in real aircraft.

I assure you that the X52 is a real and practical product.  It
receives good reviews in the usual places.  Indeed IMHO it does
not have /enough/ knobs and buttons;  the X52 /plus/ a keyboard
is marginally OK for a modest single-engine aircraft but nearly
enough for a multi-engine aircraft, or even for a complex single.

If you just want to fly around and look at the scenery, then you
don't need dozens and dozens of buttons.  But please don't assume
what /you/ want is what everybody else wants.

> Changing PLIB to support more than 32 buttons would break 100% of
> joystick using applications.

Not if it it's done properly.

It can be done upward-compatibly.  It doesn't even require a
major release;  a few hours of work and a minor point-release
would be quite sufficient, unless I am much mistaken.

> I personally find it very hard to believe that there are any
> applications out there that would actually use that many 

Maybe you can't imagine such applications, but there are plenty
of people who can.

> If there is a bug to fix in *limiting* the number of buttons
> to 32 - then we should fix that.

These are rather significant bugs.  If you roll the trim wheel
it fires the gun!

Here we are more than a year after the initial report and the
bugs still haven't been fixed.  They haven't even made it into
the TODO files AFAICT.

>> Changing tmp_buttons to a uint64_t, updating the arguments to
>> jsJoystick::rawRead and jsJoystick::read fixed that for me.

That's not the smart solution.  There are multiple problems with
that.

> But it would break other applications. We absolutely cannot do that.

So we need to do something else.

Hey, this isn't rocket science.  We can see how to do it by
looking at how  snprintf  was introduced.  It solved a big set
of problems and did *not* require breaking any old applications.

Here's how this applies to the present case:

-- In line 70 of js.h, define getNumButtons() in analogy to getNumAxes().

-- In *addition* to (not instead of) things like this:
      void read    ( int *buttons, float *axes ) ;
   we need to define
      void nread    ( unsigned char *buttons, const size_t nb,
                              float *axes, const size_t na ) ;

-- Then anybody who wants to call nread is free to do so.  (FWIW
   the name "nread" could be simply "read";  the c++ overloading
   features are quite capable of figure out which function is wanted.)

-- On the other side of the coin, people who don't know (or don't
   care) are free to continue calling the old read(,) function.

-- We put all the smarts in the nread(,,,) function.  The read(,)
   function is easily implemented in terms of nread(,4,,) plus a
   call to ntohl().  It's not rocket science.

-- In nread(,,,), the number of buttons returned is limited by the
   number of buttons that exist /or/ by the amount of space available,
   whichever is less.

-- I think that's more-or-less all there is to it.

So, what's the next step?