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, 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
