From owner-performer@oss.sgi.com Thu Dec 7 10:32:29 2000 Received: by oss.sgi.com id ; Thu, 7 Dec 2000 10:32:20 -0800 Received: from wellington.concentric.net ([207.155.252.14]:27559 "EHLO wellington.cnchost.com") by oss.sgi.com with ESMTP id ; Thu, 7 Dec 2000 10:31:59 -0800 Received: from aechelon.com ([207.168.131.198]) by wellington.cnchost.com id NAA00062; Thu, 7 Dec 2000 13:31:55 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <3A2FD79E.3C1C1A8B@aechelon.com> Date: Thu, 07 Dec 2000 10:31:58 -0800 From: Philip Nemec X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Performer Dev Subject: [Linux] joystick support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-performer@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;info-performer-dev-outgoing So I haven't seen any traffic on this list yet, so here's my first 2 cent contribution... There's fairly good joystick support in Linux [including serial joysticks] with a uniform interface (variable number of axes and buttons - all scaled/calibrated to give consistency). I'd say that the pfuXformer model is a bit broken and an alternative that includes support for joysticks would be worthwhile... It seems to be that a matrix mapping axes (including from a mouse) and buttons to XYZ should be general enough to support different motion models as well as different input devices. Comments? I think it would probably be worth porting the Linux serial joystick support to Irix (should be pretty easy without the analog joystick mess). I won't volunteer for this though - I'm content to contribute on the more general motion model stuff... From owner-performer@oss.sgi.com Thu Dec 7 15:56:51 2000 Received: by oss.sgi.com id ; Thu, 7 Dec 2000 15:56:41 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54130 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 7 Dec 2000 15:56:21 -0800 Received: from boeing.engr.sgi.com (boeing.engr.sgi.com [130.62.55.185]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07030 for ; Thu, 7 Dec 2000 16:04:31 -0800 (PST) mail_from (flynnt@engr.sgi.com) Received: from localhost (flynnt@localhost) by boeing.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA93876; Thu, 7 Dec 2000 15:54:44 -0800 (PST) X-Authentication-Warning: boeing.engr.sgi.com: flynnt owned process doing -bs Date: Thu, 7 Dec 2000 15:54:44 -0800 From: Tom Flynn To: Philip Nemec cc: Performer Dev Subject: Re: [Linux] joystick support In-Reply-To: <3A2FD79E.3C1C1A8B@aechelon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-performer@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;info-performer-dev-outgoing On Thu, 7 Dec 2000, Philip Nemec wrote: > There's fairly good joystick support in Linux [including serial > joysticks] with a uniform interface (variable number of axes and buttons > - all scaled/calibrated to give consistency). Indeed. For what it is worth, I have an early prototype for a replacement of pfuFlybox that I call pfuJoystick. It handles just Flyboxes on IRIX and both Flyboxes and regular PC-Joysticks under Linux. It is implemented at a C++ class that also has a C-wrapper. As such, you can access multiple joysticks / flyboxes (one per instance of the class). It is also possible to re-map the axes and buttons on the joystick (for example to try to emulate a flybox). There is also a ::print() method that'll output what buttons / axes are being used and what their values are. It would be nice to add support for more than just Flyboxes under IRIX. > I'd say that the pfuXformer model is a bit broken and an alternative > that includes support for joysticks would be worthwhile... It seems to > be that a matrix mapping axes (including from a mouse) and buttons to > XYZ should be general enough to support different motion models as well > as different input devices. > > Comments? > (again, for what it is worth), I have a modified version of the src/pguide/libpfui/fly.c that uses pfuJoystick and the FlightStick motion model (I also have a twoJoysticks.c program). The frustration I had with the motion model was the lack of a throttle (which i blame on pfiXformer). Instead, it seems, one only has control of acceleration or deceleration. Which doesn't work too well with a throttle. It would be nice to modify pfiXformer to accept a throttle-like input. Replacing pfiXformer with something more generic and flexible (as I interpret your suggestion to be) sounds quite desirable as well. well, those are my two cents :) -tom -- "Mongooses are famous for their snake-fighting ability, and are almost always victorious because of their speed, agility, and timing and also because of their thick coat." From owner-performer@oss.sgi.com Thu Dec 14 18:57:47 2000 Received: by oss.sgi.com id ; Thu, 14 Dec 2000 18:57:37 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:13099 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Dec 2000 18:57:11 -0800 Received: from southpark.engr.sgi.com (southpark.engr.sgi.com [130.62.55.189]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA28104 for ; Thu, 14 Dec 2000 18:56:24 -0800 (PST) mail_from (allan@southpark.engr.sgi.com) Received: (from allan@localhost) by southpark.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA83030 for info-performer-dev@oss.sgi.com; Thu, 14 Dec 2000 18:55:50 -0800 (PST) Date: Thu, 14 Dec 2000 18:55:50 -0800 (PST) From: Allan Schaffer Message-Id: <10012141855.ZM1155544@southpark.engr.sgi.com> X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: info-performer-dev@oss.sgi.com Subject: Welcome to info-performer-dev Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-performer@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;info-performer-dev-outgoing Greetings all, The OpenGL Performer "Open Development" Project is officially underway, let's kick off this new mailing list. Source code for libpfdu, libpfutil, libpfui, the database loaders of libpfdb, the sample applications, and programming guide samples are all open to modification, addition, and redesign; new applications or new libraries are welcome also. Let's start off by hearing from you about: - What you would like to see here on this mailing list - What are your wish-list items to be added as far as: . utility library functionality . sample applications . programming guide examples - What your interests are in the context of this project A bit about development philosophy: With Performer being such a mature product and having an established application base, in most cases we seek to minimize API changes, so as to minimize the porting effort from one major release to the next. New functionality tends to be introduced as internal additions to existing APIs, or in completely new APIs, leaving the previously existing methods unchanged. Our users have indicated that they appreciate this approach. This results in the (sometimes less than ideal) situation of having multiple competing suites of similar functionality -- take our event handling & UI code for example. I see a lot of this getting cleaned up for Performer 2.5. It's important for the 'old' functionality to remain, but it can be retired into secondary libraries as has been done before. The corollary to this method is that new functionality can & should be treated as first-class fully maintained code. To sync up with what is happening internally: now that Performer 2.4 is released we are collecting and investigating suggestions & requirements for Performer 2.5. Simultaneously we are implementing bugfixes on the 2.4 stream for an update release, Performer 2.4.1. Backwards _and_ forwards binary compatible Performer updates ship with IRIX roughly each quarter. In most cases, this project will effect the libraries & examples that will ship with Performer 2.5. There may be cases where modifications suggested here can be 'ported back' to 2.4 but they will happen on a case-by-case basis. That's all for now, let's hear from you.. Allan -- Allan Schaffer allan@sgi.com Silicon Graphics http://reality.sgi.com/allan