Thread: [Plib-devel] Saitek X52 joystick with 34 buttons
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Trammell H. <hud...@sw...> - 2005-05-04 15:21:07
|
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). This code in
jsLinux.cxx is the problem:
case JS_EVENT_BUTTON :
if ( os->js.value == 0 ) /* clear the flag */
os->tmp_buttons &= ~(1 << os->js.number) ;
else
os->tmp_buttons |= (1 << os->js.number) ;
break ;
Changing tmp_buttons to a uint64_t, updating the arguments to
jsJoystick::rawRead and jsJoystick::read fixed that for me.
Another problem is that the mode switch holds down one of three
buttons depending on which of the three modes is selected. This
interferes with the calibration routine used by FlightGear and
required me to modify the fgjs program. Any code that uses
level triggered button handling may run into starvation as it
always services the mode buttons.
With FC3 I had to patch my kernel's USB hid-core file, as documented
here to deal with the slow joystick device. Apparently Saitek has some
problems across their entire product line -- the patch was originally
for an X45 joystick, but works for the X52 as well:
http://baron.flightgear.org/pipermail/flightgear-users/2004-July/008234.html
Trammell
|
|
From: Bram S. <br...@sa...> - 2005-05-04 16:25: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). This code in > jsLinux.cxx is the problem: Hi Trammell! I'll be happy to commit your changes to CVS. However, before I do that, I need to check for portability. jsLinux.cxx is pretty safe to adapt. However, js.h is cross-platform, and I wonder about the portability of uint64_t. Do all plib platforms know uint64_t ? It seems to be defined by stdint.h, which is included in inttypes.h This is something I found with google on the subject of inttypes (which seems incompatible with Nec SX-5 super computers ;-) In the email thread, a lack of standardization is mentioned. http://www.cactuscode.org/pipermail/developers/2004-September/000608.html So... what to do? Bram Stolk > > case JS_EVENT_BUTTON : > if ( os->js.value == 0 ) /* clear the flag */ > os->tmp_buttons &= ~(1 << os->js.number) ; > else > os->tmp_buttons |= (1 << os->js.number) ; > break ; > > Changing tmp_buttons to a uint64_t, updating the arguments to > jsJoystick::rawRead and jsJoystick::read fixed that for me. > > Another problem is that the mode switch holds down one of three > buttons depending on which of the three modes is selected. This > interferes with the calibration routine used by FlightGear and > required me to modify the fgjs program. Any code that uses > level triggered button handling may run into starvation as it > always services the mode buttons. > > With FC3 I had to patch my kernel's USB hid-core file, as documented > here to deal with the slow joystick device. Apparently Saitek has some > problems across their entire product line -- the patch was originally > for an X45 joystick, but works for the X52 as well: > > http://baron.flightgear.org/pipermail/flightgear-users/2004-July/008234.html > > Trammell > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 16:39:40
|
On Wed, May 04, 2005 at 06:24:50PM +0200, Bram Stolk wrote: > 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. [...] > > Hi Trammell! Don't we know each other from somewhere else? > I'll be happy to commit your changes to CVS. > However, before I do that, I need to check for portability. > > jsLinux.cxx is pretty safe to adapt. > However, js.h is cross-platform, and I wonder about the > portability of uint64_t. Do all plib platforms know uint64_t ? It is defined in C99 and many platforms have supported it as part of the C9X preliminary standard for the past five years. I can't speak to anything other than Unix like platforms, all of which support it (Linux, BSD, Cygwin and OS X). I only ever use gcc compilers, so this answered the question for me: http://gcc.gnu.org/c99status.html > It seems to be defined by stdint.h, which is included in inttypes.h I don't believe plib is targetting any non-hosted, free standing environments, so you should be safe to include the larger <inttypes.h> header, which also provides formatting macros, etc. Trammell |
|
From: Andy R. <an...@pl...> - 2005-05-04 17:02:40
|
Bram Stolk wrote: > jsLinux.cxx is pretty safe to adapt. > However, js.h is cross-platform, and I wonder about the > portability of uint64_t. Do all plib platforms know uint64_t? The subject came up recently on the FlightGear list, and the upshot is that everyone but Microsoft supports the stdint.h header in recent compiler versions. MSVC does, however, have 64 bit integer types, so what we did is something to the effect of: #ifdef _WIN32 typedef unsigned long long uint64_t; #else #include <stdint.h> #endif etc... In this case, though, I wonder if perhaps the joystick bitmask could just be stored in a unsigned char array instead rather than playing portability games with the preprocessor. Andy |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 17:37:04
|
On Wed, May 04, 2005 at 10:00:08AM -0700, Andy Ross wrote: > In this case, though, I wonder if perhaps the joystick bitmask could > just be stored in a unsigned char array instead rather than playing > portability games with the preprocessor. The other problem with making the arguments uint64_t* is that it is a user-visible change and would require all clients of the jsJoystick class to update their code. I agree that if there is to be a change with the number of supported buttons that it should be done the "right way", rather than another temporary postponement of the inevitable. I can envision a HOTAS stick and radio stack with far more than 64 or 128 buttons or knobs. Who wants to go down in history as having said that: 64 buttons should be enough for anybody. Trammell |
|
From: Bram S. <br...@sa...> - 2005-05-04 17:55:26
|
Trammell Hudson wrote: > I can envision a HOTAS stick and radio stack with far more than 64 or > 128 buttons or knobs. Who wants to go down in history as having said > that: > > 64 buttons should be enough for anybody. He he he ... good one! I think we should consult the man (Steve :-) ) before doing API changes. Maybe a good solution would be to extend the API, instead of changing it. Have a 32 button member func, and a n-button member func in addition. PS: ofcourse I recognized you as the Wizard of aerial robotics :-) Bram > > Trammell > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > plib-devel mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-devel |
|
From: Steve B. <sjb...@ai...> - 2005-05-05 02:39:17
|
Bram Stolk wrote: > Trammell Hudson wrote: > >> I can envision a HOTAS stick and radio stack with far more than 64 or >> 128 buttons or knobs. Who wants to go down in history as having said >> that: >> >> 64 buttons should be enough for anybody. But would you *really* approach that problem using the joystick API? That makes no sense at all. Once you're interfacing to an entire cockpit mockup, you likely also have a bazillion little lights to light up, things like instruments - you name it. At that point, you're going to need a much more serious API. > I think we should consult the man (Steve :-) ) before doing > API changes. Maybe a good solution would be to extend the API, > instead of changing it. Have a 32 button member func, and a n-button > member func in addition. Yeah - but if we do that, we shouldn't just go to a 64 bit word - we should switch to a bool array of variable length or something. But whatever we do, the present API *must* be retained and must continue to work ok for the first 32 buttons. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2005-05-04 21:20:19
|
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). That's practically a keyboard! Changing PLIB to support more than 32 buttons would break 100% of joystick using applications. I personally find it very hard to believe that there are any applications out there that would actually use that many - so for now, I'm not inclined to change the interface to support more buttons. If there is a bug to fix in *limiting* the number of buttons to 32 - then we should fix that. > Changing tmp_buttons to a uint64_t, updating the arguments to > jsJoystick::rawRead and jsJoystick::read fixed that for me. But it would break other applications. We absolutely cannot do that. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Trammell H. <hud...@sw...> - 2005-05-04 23:35:56
|
On Wed, May 04, 2005 at 04:12:55PM -0700, Steve Baker wrote: > 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). > > That's practically a keyboard! I'm not sure I could touch type on it -- I have enough trouble remembering which button is "lower the flaps" and which one will irrevocably initiate the autodestruct sequence. > [...] > I personally find it very hard to believe that there are any > applications out there that would actually use that many - so > for now, I'm not inclined to change the interface to support > more buttons. Flight simulators have an insatiable desire for more buttons and axes. In this case, I have a subset of these mapped, depending on the flight model that I am debugging: Flaps up/down Gear up/down Speed brakes up/down Arrestor hook up/down Forward view POV "Check 6" Autopilot mode Autopilot heading bug left/right Drouge chute Ejector seat Left brake Right brake Timer start/stop/reset Elevator trim up/down/reset Rudder trim left/right/reset Vector sweep forward/aft Thrust vector up/down Weapon select Pause Engine start Flight model load/save/reset > If there is a bug to fix in *limiting* the number of buttons > to 32 - then we should fix that. plib doesn't seem to have a problem, but other applications do. xplane, for instance, maps 32 -> 0 and 33 -> 1 on Linux. On OS X, it doesn't see any button higher than 16 (I think -- not all of them work and I haven't done any serious debugging on it). > >Changing tmp_buttons to a uint64_t, updating the arguments to > >jsJoystick::rawRead and jsJoystick::read fixed that for me. > > But it would break other applications. We absolutely cannot do that. Exactly, which I why I cautioned against on making the change too soon, since there is probably a better way to represent button state rather than a single integral type bitmask. It worked for me on my system, but I was recompiling plib, SimGear and FlightGear from source, so there was no problem with binary compatibility. Trammell |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X