Re: [Flightgear-devel] RFC: Reading Airport Geometry from Scenery
On Thursday 27 August 2009 00:17:16 Martin Spott wrote: Durk Talsma wrote: runway information from scenery/Airports/I/C/A/ICAO.geometry.xml I think this was supposed to mean 'ICAO.threshold.xml', right ? Yes, that's correct. ;-) D. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, I've implemented Mac specific portion of generic input devices, and am testing it. The Mac specific source (including some local modification on FGEventInput.* and Makefile.am files) ATM are available at: http://macflightgear.sourceforge.net/wp-content/uploads/eventinput/FGMacEventInput.tgz The source files are still in progress, but these work fine on my Mac. Anyway, I have some questions and comments on this: 1. Is AxisEvent::fire suppose to set a raw input value (e.g. -1024 to 1024), or normalized value (-1.0 to 1.0) to its relevant node? I assume it's latter, but the normalization portion seems missing. If it is assumed that the OS specific FGInputDevice must pass a normalized input value to HandleEvent, then I'll add such code to FGMacOSXEventInput.cxx, but then FGAxisEvent's MinRange, MaxRange, etc will be useless. 2. /input/event/device[N]/event[M]/setting seems missing. Is such node set on Linux? It is good to have the setting for adjusting some control (like throttle using controls.throttleAxis()) 3. Hot plug thing seems missing, so I modified FGEventInput.* for attaching/detaching both property nodes and FGInputDevice. it works fine on Mac OS X, so please take a look at my FGEventInput.*[ch]xx. The key thing is that FGMacOSXInputDevice must know an index of a device node, device handler (Mac specific), and an instance of FGInputDevice. So I modified FGEventInput::AddDevice to return an index for the added device, and let FGMacOSXEventInput to map the index with a device handler. This allows me to find a node index when HID Manager tells me a device handler to be detached. By calling FGEventInput::RemoveDevice(index) will remove both FGInputDevice and its relevant property nodes. What do you think about this? 4. What is the naming convention for event names? I read Universal Serial Bus HID Usage Tables (http://www.usb.org/developers/devclass_docs/Hut1_12.pdf) but there's no -translate, -rotate things in its definition. I guess it is good to have some convention so we can add new events in a consistent fashion. I added some event names on my code, and most of the names (except the ones you defined) are directly converted from HID usage table's definition (by changing capital letters to small, replacing white spaces with '-' ). I'm not offensive so -translate or -rotate is ok, but I'm not so sure how to convert vrbx James, Thanks for your concern. Some portion of my code is based on PLIB's js implementation (like element enumerator, and opening device interfaces, etc) I'll ask you for some advice if needed. I wish I could use a new HID Manager code but it is only available on Mac OS 10.5 so I stay with old one. Best, tat On Aug 21, 2009, at 7:02 PM, Torsten Dreyer wrote: Hi, This indeed is a good idea. I took a look at the code, and I believe I can implement the Mac portion of the new input event model using HID Manager. I'll post the patch when I finish implementing it. - Tatsuhiro Nishioka Great! Looking forward to receiving your patch. Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Input Support
Hi Jim,
Thanks for the info and the link to USB spec.
I'm not so sure if Windows need this table, but on Macs it's inevitable.
We also need to look up other usage pages like general desktop page (0x01),
buttons page
since many joysticks use these pages instead of simulation page.
FYI,
There is a newer version of HID usage table.
http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
Best,
Tat
On Aug 7, 2009, at 5:37 PM, Jim Campbell wrote:
Hi,
The HID Usage Tables (extracted from MacOSX) incude a sub-section
specifically for Simulation:
/* Simulation Page (0x02) */
/* This section provides detailed descriptions of the usages employed
by simulation devices. */
enum
{
kHIDUsage_Sim_FlightSimulationDevice= 0x01,/* Application
Collection
*/
kHIDUsage_Sim_AutomobileSimulationDevice= 0x02,/* Application
Collection */
kHIDUsage_Sim_TankSimulationDevice = 0x03,/* Application
Collection */
kHIDUsage_Sim_SpaceshipSimulationDevice= 0x04,/* Application
Collection */
kHIDUsage_Sim_SubmarineSimulationDevice= 0x05,/* Application
Collection */
kHIDUsage_Sim_SailingSimulationDevice = 0x06,/* Application
Collection
*/
kHIDUsage_Sim_MotorcycleSimulationDevice= 0x07,/* Application
Collection */
kHIDUsage_Sim_SportsSimulationDevice= 0x08, /* Application
Collection
*/
kHIDUsage_Sim_AirplaneSimulationDevice= 0x09, /* Application
Collection */
kHIDUsage_Sim_HelicopterSimulationDevice= 0x0A,/* Application
Collection */
kHIDUsage_Sim_MagicCarpetSimulationDevice= 0x0B,/* Application
Collection */
kHIDUsage_Sim_BicycleSimulationDevice = 0x0C,/* Application
Collection
*/
/* 0x0D - 0x1F Reserved */
kHIDUsage_Sim_FlightControlStick= 0x20,/* Application
Collection */
kHIDUsage_Sim_FlightStick = 0x21, /* Application Collection */
kHIDUsage_Sim_CyclicControl = 0x22, /* Physical Collection */
kHIDUsage_Sim_CyclicTrim= 0x23, /* Physical Collection */
kHIDUsage_Sim_FlightYoke= 0x24, /* Application Collection */
kHIDUsage_Sim_TrackControl = 0x25, /* Physical Collection */
/* 0x26 - 0xAF Reserved */
kHIDUsage_Sim_Aileron = 0xB0, /* Dynamic Value */(
kHIDUsage_Sim_AileronTrim = 0xB1, /* Dynamic Value */
kHIDUsage_Sim_AntiTorqueControl = 0xB2,/* Dynamic Value */
kHIDUsage_Sim_AutopilotEnable = 0xB3, /* On/Off Control */
kHIDUsage_Sim_ChaffRelease = 0xB4, /* One-Shot Control */
kHIDUsage_Sim_CollectiveControl = 0xB5,/* Dynamic Value */
kHIDUsage_Sim_DiveBrake = 0xB6, /* Dynamic Value */
etc. etc.
A google search for Universal Serial Bus HID usage will reveal a pdf
document www.usb.org/developers/devclass_docs/Hut1_11.pdf (159 pages so
not included) and it would be useful for cockpit building if some of
these could be recognised, especially pages 0x01(generic) and
0x02(simulation) (see specificially the table on page 36 of the
document)!!
cheers
Jim
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed
Anders, Thanks for the email. Yes, it crashes right after it says JSBSim startup beginning How do I know if an aircraft uses YASim?? I'm using CVS FlightGear which has folders: src\FDM\JSBSim\. That means JSBSim is CVS, right? Thanks, Randy Green - Original Message - From: Anders Gidenstam anders-...@gidenstam.org Date: Wednesday, August 26, 2009 3:50 pm Subject: Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net On Wed, 26 Aug 2009, Randall Green wrote: I get the splash screen of the Cesna, but after it says Initializing Subsystems I get Debug Assertion Failed! File: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c Line 56 Expression (unsigned)(c+1),=256 When I request to debug it takes me to string_utilities.h line 86. Try an aircraft that uses YASim for comparison. There is a string_utilities.h in JSBSim and the version in FlightGear has a few bugs that have been fixed in JSBSim/CVS. One of them is at line 86 so this could very well be the problem. You could also try copying the file from JSBSim/CVS and rebuild. http://jsbsim.cvs.sourceforge.net/viewvc/jsbsim/JSBSim/src/input_output/string_utilities.h?view=log Cheers, Anders -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed
Look in the setfile for an aircraft (the ***-set.xml file), there will be an aero tag that indicates which FDM engine it's using. Cheers, Nic On Thu, Aug 27, 2009 at 11:18 AM, Randall Green randall.gr...@wright.eduwrote: Anders, Thanks for the email. Yes, it crashes right after it says JSBSim startup beginning How do I know if an aircraft uses YASim?? I'm using CVS FlightGear which has folders: src\FDM\JSBSim\. That means JSBSim is CVS, right? Thanks, Randy Green - Original Message - From: Anders Gidenstam anders-...@gidenstam.org Date: Wednesday, August 26, 2009 3:50 pm Subject: Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net On Wed, 26 Aug 2009, Randall Green wrote: I get the splash screen of the Cesna, but after it says Initializing Subsystems I get Debug Assertion Failed! File: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c Line 56 Expression (unsigned)(c+1),=256 When I request to debug it takes me to string_utilities.h line 86. Try an aircraft that uses YASim for comparison. There is a string_utilities.h in JSBSim and the version in FlightGear has a few bugs that have been fixed in JSBSim/CVS. One of them is at line 86 so this could very well be the problem. You could also try copying the file from JSBSim/CVS and rebuild. http://jsbsim.cvs.sourceforge.net/viewvc/jsbsim/JSBSim/src/input_output/string_utilities.h?view=log Cheers, Anders -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed
On Thu, 27 Aug 2009, Randall Green wrote: Anders, Thanks for the email. Yes, it crashes right after it says JSBSim startup beginning How do I know if an aircraft uses YASim?? I'm using CVS FlightGear which has folders: src\FDM\JSBSim\. That means JSBSim is CVS, right? Well, not quite even though technically the source is managed by CVS. You have the development version of FlightGear (usually called FlightGear/CVS). JSBSim is developed by a separate project so the development version of JSBSim (JSBSim/CVS) is sometimes ahead of the version in FlightGear/CVS as the copy of the JSBSim code in FlightGear/CVS is frequently but not continously updated to match JSBSim/CVS. You can test doing such an update yourself by replacing src/FDM/JSBSim/input_output/string_utilities.h with the updated file I linked to in the previous email. I think that will solve your problem. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
I've implemented Mac specific portion of generic input devices, and am testing it. The Mac specific source (including some local modification on FGEventInput.* and Makefile.am files) ATM are available at: http://macflightgear.sourceforge.net/wp-content/uploads/eventinput/FGMacEve ntInput.tgz The source files are still in progress, but these work fine on my Mac. Hi Tat, thanks for that - it looks like you spent a lot of time on it ;-) I will soon merge your updates into my code which has changed a little bit since the last cvs commit. I hope to get it done by the weekend. Do you think your FGMacOSXEventInput.?xx is ready for CVS? Anyway, I have some questions and comments on this: 1. Is AxisEvent::fire suppose to set a raw input value (e.g. -1024 to 1024), or normalized value (-1.0 to 1.0) to its relevant node? I assume it's latter, but the normalization portion seems missing. If it is assumed that the OS specific FGInputDevice must pass a normalized input value to HandleEvent, then I'll add such code to FGMacOSXEventInput.cxx, but then FGAxisEvent's MinRange, MaxRange, etc will be useless. Currently the value is not normalized. To do so, we have to scale the value by the minimum/maximum values delivered from the HID report descriptor. Not sure, if it's physical or logical max/minimum. To be consistent within FlightGear we should normalize the value. 2. /input/event/device[N]/event[M]/setting seems missing. Is such node set on Linux? It is good to have the setting for adjusting some control (like throttle using controls.throttleAxis()) Good point - I will add it. 3. Hot plug thing seems missing, so I modified FGEventInput.* for attaching/detaching both property nodes and FGInputDevice. it works fine on Mac OS X, so please take a look at my FGEventInput.*[ch]xx. The key thing is that FGMacOSXInputDevice must know an index of a device node, device handler (Mac specific), and an instance of FGInputDevice. So I modified FGEventInput::AddDevice to return an index for the added device, and let FGMacOSXEventInput to map the index with a device handler. This allows me to find a node index when HID Manager tells me a device handler to be detached. By calling FGEventInput::RemoveDevice(index) will remove both FGInputDevice and its relevant property nodes. What do you think about this? That's perfect. I admit being lazy and not having implemented hotplug yet ;-) Your RemoveDevice is a good start. 4. What is the naming convention for event names? I read Universal Serial Bus HID Usage Tables (http://www.usb.org/developers/devclass_docs/Hut1_12.pdf) but there's no -translate, -rotate things in its definition. I guess it is good to have some convention so we can add new events in a consistent fashion. I added some event names on my code, and most of the names (except the ones you defined) are directly converted from HID usage table's definition (by changing capital letters to small, replacing white spaces with '-' ). I'm not offensive so -translate or -rotate is ok, but I'm not so sure how to convert vrbx We shall take care that the same device generates the same named event on every operating system. The HID report should assist us in that - the USAGEs describes the event. The usages X, Y, Z are for linear translation along the x,y,z axes while RX, RY and RZ are rotation around the axes. Hence the names -translate and -rotate ;-) I used the event names defined in the linux/input.h from the linux kernel. But I am open for other/better sugestions. Greetings, Torsten -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, On Aug 28, 2009, at 4:28 AM, Torsten Dreyer wrote: thanks for that - it looks like you spent a lot of time on it ;-) I will soon merge your updates into my code which has changed a little bit since the last cvs commit. I hope to get it done by the weekend. Do you think your FGMacOSXEventInput.?xx is ready for CVS? I modified these a bit and I guess these are ready now. The updated files are available at: http://macflightgear.sourceforge.net/wp-content/uploads/eventinput/FGMacEventInput-20090827.tar.gz I also modified your code to eliminate compilation errors (linux headers in FGEventInput.cxx) and warnings (the order of initializing member variables), so please merge these portions to your code. btw, Makefile.am files are my local use only, so don't commit these. # I'll also make a patch so Mac users can build FG with configure/make. Anyway, I have some questions and comments on this: 1. Is AxisEvent::fire suppose to set a raw input value (e.g. -1024 to 1024), or normalized value (-1.0 to 1.0) to its relevant node? I assume it's latter, but the normalization portion seems missing. If it is assumed that the OS specific FGInputDevice must pass a normalized input value to HandleEvent, then I'll add such code to FGMacOSXEventInput.cxx, but then FGAxisEvent's MinRange, MaxRange, etc will be useless. Currently the value is not normalized. To do so, we have to scale the value by the minimum/maximum values delivered from the HID report descriptor. Not sure, if it's physical or logical max/minimum. To be consistent within FlightGear we should normalize the value. I guess you can get min/max values using ioctl, but not that sure.. maybe we can use the similar idea that PLIB's jsJoystick::fudge_axis does. Though we can let users define min/max things in xml files, it's way better to normalize axis inputs without using xml tags. 2. /input/event/device[N]/event[M]/setting seems missing. Is such node set on Linux? It is good to have the setting for adjusting some control (like throttle using controls.throttleAxis()) Good point - I will add it. Glad to hear that! 3. Hot plug thing seems missing, so I modified FGEventInput.* for attaching/detaching both property nodes and FGInputDevice. it works fine on Mac OS X, so please take a look at my FGEventInput.*[ch]xx. The key thing is that FGMacOSXInputDevice must know an index of a device node, device handler (Mac specific), and an instance of FGInputDevice. So I modified FGEventInput::AddDevice to return an index for the added device, and let FGMacOSXEventInput to map the index with a device handler. This allows me to find a node index when HID Manager tells me a device handler to be detached. By calling FGEventInput::RemoveDevice(index) will remove both FGInputDevice and its relevant property nodes. What do you think about this? That's perfect. I admit being lazy and not having implemented hotplug yet ;-) Your RemoveDevice is a good start. Great! I haven't test with more than one plug-able HID devices, so we need to carefully see what happens when device[0] is unplugged and device[1] stays plugged. Maybe device[0] is removed but device[1] is there, and when you plug it again, device[0] shows up again. 4. What is the naming convention for event names? I read Universal Serial Bus HID Usage Tables (http://www.usb.org/developers/devclass_docs/Hut1_12.pdf) but there's no -translate, -rotate things in its definition. I guess it is good to have some convention so we can add new events in a consistent fashion. I added some event names on my code, and most of the names (except the ones you defined) are directly converted from HID usage table's definition (by changing capital letters to small, replacing white spaces with '-' ). I'm not offensive so -translate or -rotate is ok, but I'm not so sure how to convert vrbx We shall take care that the same device generates the same named event on every operating system. The HID report should assist us in that - the USAGEs describes the event. The usages X, Y, Z are for linear translation along the x,y,z axes while RX, RY and RZ are rotation around the axes. Hence the names -translate and -rotate ;-) I used the event names defined in the linux/input.h from the linux kernel. But I am open for other/better sugestions. I also want to know if the event names that I defined are acceptable. most of these are directly converted as I mentioned but some are translated likely-torsten way :-) I also added button- prefix to some OSC/OOC type of elements, but these can be omitted. The problem here is I have only a few devices and I can't test many events to see if I name these properly. Best, Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best
