Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
Hi, Attached is a patch for FGMacOSXEventInput.[ch]xx Torsten, Could you commit it with the following comments: - Fixed: wrong event name for abs-hat0-y Modified: let AxisElement to generate normalized input (-1.0 to 1.0). This can be temporal and can be removed when AxisEvent normalizes its value. Modified: clean up code Added: some comments so other Mac developers can see what's going on - By the way, I found some differences between Linux and Mac OS X implementation, and want to hear some idea on how to eliminate the differences. 1. button index in FGLinuxEventInput.cxx the button index for misc usage begins from 0, but in USB specification, the index for button (on Button Usage Page) begins from 1 (same in FGMacOSXEventInput.cxx) This difference affects the compatibility (among OSs) of event configuration files. So I'm wondering which way we should follow. Maybe we should follow the linux way since it's easier to convert the existing joystick configuration files into new event configuration files. (button index in a joystick configuration file also begins from 0) What do you guys think? 2. event names for buttons of mice, joysticks (for generic desktop page), and gamepads At this moment, there's no button-left, button-right, etc in Mac OS X implementation. The same is applied for gamepad buttons, and joystick buttons. Instead, the button events are named like button-N regardless of device type. I guess it is easier to assign names in button-N format, but if we really need to clearly state button-left, or button-right, button-a, or button-trigger instead of button-N, then I'll add some code to generate these. I want to note that it is doable on Mac OS X by checking CA type of HID usage, but I'm not so sure if it is one-to-one relationship among HID usage and button names in all devices. if not, we must not use the linux way. We also needs to consider the possible Windows implementation. Any idea on this? Thanks in advance, Tat FGMacOSXEventInput.diff Description: Binary data -- 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
Some time ago, I have been playing with input.cxx so that FG takes all the buttons of my Saitek x52pro ( more than 36, that is ). I had to patch plib so that this work. Since input method changed, my trick is obsolete, so I was wondering if the new method based on linux input will take more than 36 buttons natively ? I am not home right now so I cannot try it with the saitek stick, just being curious ! -- 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
Some time ago, I have been playing with input.cxx so that FG takes all the buttons of my Saitek x52pro ( more than 36, that is ). I had to patch plib so that this work. Since input method changed, my trick is obsolete, so I was wondering if the new method based on linux input will take more than 36 buttons natively ? I am not home right now so I cannot try it with the saitek stick, just being curious ! It has not changed, it's just a new, additional way of supporting devices. The old plib driven keyboard/mouse/joystick input still persists. Both options live happily next to each other and you may use the new or the old one. There is no (known) limit for the number of supported buttons or axes with this implementation other than those of your operating system. On linux, buttons, keys and axes are numbered by a 16bit unsigned integer which limits your number of each to 65536. 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
There is no (known) limit for the number of supported buttons or axes with this implementation other than those of your operating system. On linux, buttons, keys and axes are numbered by a 16bit unsigned integer which limits your number of each to 65536. Thank you ! Good, until I find a 65537 buttons joystick, and learn how to use each, that should be enough ;) Patrice -- 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] [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,
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
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 On 2009/08/05, at 5:37, Torsten Dreyer tors...@t3r.de wrote: I Just found out that my notebook's lid switch is an input device: I: Bus=0019 Vendor= Product=0005 Version= N: Name=Lid Switch P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input5 U: Uniq= H: Handlers=event5 B: EV=21 B: SW=1 So - FlightGear now pauses when I close my notebook's lid. This could be very useful when running FlightGear at work and the boss suddenly shows up on a short final... --- --- --- - 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] [DRAFT] generic input devices and hotplug support
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
Re: [Flightgear-devel] [DRAFT] generic input devices and hotplug support
On 21 Aug 2009, at 10:55, Tatsuhiro Nishioka wrote: 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. I was 'responsible' (more like 'guilty') for some of the current PLIB- js HID code, mostly hacked up by reading the SDL sources. I doubt I have anything useful to add beyond what you already know (it's a long time since I touched that code, I hope it's had some bugfixes and maintenance since), but feel free to get in touch if you want a second opinion about anything. I recently updated my tree to CVS head, so I was looking at the new input code wondering if 'd need to write the HID stuff myself - thanks for volunteering! Regards, James -- 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 have just commited basic support for the linux event devices. It is disabled by default and has to be enabled by calling ./configure --with-eventinput (Don't forget autogen.sh before that) If enabled, FlightGear needs dbus-1 and hal devel packages for the headers and libs. The system is not complete, yet. The hotplug support is still missing, there is no support for Mac and Win. The configure script is not perfect: no checking for required packages dbus-1-devel and hal-devel is done. Probably switches --with-dbus-1= and --with-hal= should be added to make the paths for the libs configurable. I can't guarantee that everything works flawless, but it should compile clean and shouldn't break your system. At least, if it's disabled ;-) For usage, check the data/Input/Event/3dconnexion/SpaceNavigator.xml as an example how to configure your devices. The bindings work as they do in other parts of FlightGear. New is the setting section for sending events to the device. One should easily find out, how they work by looking at the sample device. If you want to find out which input devices are supported by your linux these two commands are your friends: $ cat /proc/bus/input/devices or $ lshal Have fun playing with it - Please report bugs or ask questions. 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 Torsten, Hi, I am currently playing with the input subsystem. This was triggered because I have two devices that currently do not work with FlightGear, neither Linux nor Windows. 1. A set of rudder pedals that does not get recognized as a joystick from joydev, because it reports it's axes as RX,RY and Z and the lack of an X-Axis stops joydev from using it as a joystick. 2. A 3dconnexion (http://www.3dconnexion.com/) SpaceNavigator 3D-Mouse which is basically a 6-axes/2buttons/1LED device. Both devices are HID devices and are handled by the Linux input/event driver. For example, the SpaceNavigator shows up in /proc/bus/input/devices as I: Bus=0003 Vendor=046d Product=c626 Version=0110 N: Name=3Dconnexion SpaceNavigator P: Phys=usb-:00:1d.1-1/input0 S: Sysfs=/devices/pci:00/:00:1d.1/usb2/2-1/2-1:1.0/input/input9 U: Uniq= H: Handlers=event9 B: EV=20017 B: KEY=3 0 0 0 0 B: REL=3f B: MSC=10 B: LED=100 My idea is to extend the FGInput class so it can use the devices presented thru the event interface. While at it, I'd also like to add hotplug support for devices, plugged in or out while FlightGear runs. What I have so far locally is a system that can use the input devices. Events and devices are configured with xml config files like this, similiar to joystick config files (just one event shown here for better readability): PropertyList name3Dconnexion SpaceNavigator/name event namerel-y-translate/name binding commandproperty-adjust/command propertysim/current-view/field-of-view/property factor type=double0.01/factor min type=double10.0/min max type=double80.0/max wrap type=boolfalse/wrap /binding /event /PropertyList See it in action here: http://www.youtube.com/watch?v=b8Me8d9UZLA The black knob can be twisted around and shifted along the x/y/z axes. These movements are translated into events which adjust the current-view direction and the field of view. The cool blue LED-light is controlled by FlightGear and indicates gear-down (YES! It's bidirectional communication). Adding/removing of devices is reported by HAL and DBUS on Linux and DirectInput on Win. I don't know how Macs deal with that, but I am certain there is a way for the macs, too. While I really like the new functionality and I see many advantages from moving into this direction, there are also some disadvantage and I'd like to open the discussion before I commit anything. Advantages: - Adding additional and generic support for a wide variety of devices - Named events, no more axis numbers and confusion between Linux/Win/Mac - Bidirectional communication (switch on/off LED's, probably force feedback etc.) - Might obsolete one plib dependency Disadvantages: - Introduces platform dependency, individual implementations needed for Linux/Win/Mac - Adds new library dependency (dbus/hal on linux DirectInput on Win, ??? on Mac) if I am not totally wrong than hal will be skipped in favor of devicekit in the near future by probably all Linux distributions. Fedora 11 is already using some parts of it. What do you think? Are the new features worth introducing new dependencies and platform dependent modules? Torsten P.S.: The GIMP also uses these techniques. Go to the settings dialog and select Input Devices. Matthias -- 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
On Tuesday 04 August 2009 19:54:23 Torsten Dreyer wrote: I am currently playing with the input subsystem. This was triggered because I have two devices that currently do not work with FlightGear, neither Linux nor Windows. My idea is to extend the FGInput class so it can use the devices presented thru the event interface. While at it, I'd also like to add hotplug support for devices, plugged in or out while FlightGear runs. What do you think? Are the new features worth introducing new dependencies and platform dependent modules? I'm really pleased to see someone looking at this - I think it's an area where the current way of doing things is beginning to creak and no longer ideal. As you probably recall I found this last year when I switched to a Saitek X52 Pro stick/throttle/MFD setup with a significant number of buttons, axes and controllable LEDs. Brief thread from the time... http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18466.html While I did eventually manage (with help from various quarters) to hack together enough parts to make everything on the stick work pretty much as I wanted, and the amazing flexibility of FG (which usually seems to provide several workarounds for any given problem) was highlighted, the process was far from optimal. Personally, I'd be very much in favour of this development; the dependencies are hardly exotic on either the Windows or Linux side and presumably something similar is readily available on OSX. Cheers, AJ -- 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 Just found out that my notebook's lid switch is an input device: I: Bus=0019 Vendor= Product=0005 Version= N: Name=Lid Switch P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input5 U: Uniq= H: Handlers=event5 B: EV=21 B: SW=1 So - FlightGear now pauses when I close my notebook's lid. This could be very useful when running FlightGear at work and the boss suddenly shows up on a short final... -- 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
That's very clever! No complaints from my end if you want to pursue this. I suspect this would open up FlightGear to a lot of new and interesting input hardware, and I bet many cockpit builders would welcome generic HID support. Regards, Curt. On Tue, Aug 4, 2009 at 3:37 PM, Torsten Dreyer wrote: I Just found out that my notebook's lid switch is an input device: I: Bus=0019 Vendor= Product=0005 Version= N: Name=Lid Switch P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input5 U: Uniq= H: Handlers=event5 B: EV=21 B: SW=1 So - FlightGear now pauses when I close my notebook's lid. This could be very useful when running FlightGear at work and the boss suddenly shows up on a short final... -- 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 -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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
