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-0000:00:1d.1-1/input0 > S: Sysfs=/devices/pci0000:00/0000: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> > <name>3Dconnexion SpaceNavigator</name> > <event> > <name>rel-y-translate</name> > <binding> > <command>property-adjust</command> > <property>sim/current-view/field-of-view</property> > <factor type="double">0.01</factor> > <min type="double">10.0</min> > <max type="double">80.0</max> > <wrap type="bool">false</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
