XWinder Linux

[ardnut]

Hi,

Just wondering whether any work is going on to port XWinder over to Linux.

I use it every day at work on windows 2000 but it would be great if I could use it on my laptop and desktop machines at home (which are running linux/kde).

Thanks.

[JerryKnight]

Here's the old thread (http://forums.fingerworks.com/showthread.php?s=&threadid=326) I started long long ago. I don't think much has changed since then.

Basically all it will take is someone to write the USB handlers in the hand motion SDK and the Xlib calls in Xwinder for window manipulation. If I had the time, I would give it a go. I'm still investigating which way to handle the HID. Either hiddev or evdev or libhid.. Still trying to wrap my brain around the whole mess.

I understand why it is low priority for FW.. They have bigger things to worry about right now. So anyone who can follow the win/mac code and knows a thing about linux USB/HID and Xlib, we'd love to have your expertise.

[fingerworks]

About which HID handling API to use, the best would be one that can pass the raw, unparsed 16 bytes of each Hand Motion report to the Hand Motion SDK, which has its own parsing functions that can take it from there.

If you try to use something like evdev which pre-parses the Hand Motion report into "HID Events" or "HID Elements" (like the Mac OS X HID drivers do), then you'll actually need to reconstruct the original 16 byte packet from the events/elements that come in one by one before the Hand Motion SDK can handle them. If Linux's events/elements don't indicate the Report ID of the data packet they were parsed from, this won't even be possible. We use different report IDs (the first byte of the packet) to distinguish left hand and right hand reports. Thus an X Axis usage event/element can contain either left hand or right hand motion data, and you won't know which if the report ID is not somehow attached to the event.

These are the issues. Hope one of these linux APIs offers an easy solution.

[JerryKnight]

What gets me is the total lack of any clear explanation of USB+HID in linux. I've read just about everything in the first 10 pages of google hits, and nobody outlines it simple enough for me to understand, and in depth enough to cover report processing. Maybe I'm just slow. :)

I got evdev devices to respond to my prodding, but I only seem to get activity from the mouse device and the keyboard device. (Pretty much I just ran a few sample programs from here (http://www.frogmouth.net/hid-doco/c537.html)). hiddev devices have not worked for me on my MDK box, and I can't figure out whether it's a kernel issue or a conflicting module. libHID (http://www.ghz.cc/~clepple/libHID/doc/html/) looks to be a promising portable user-space library, but I'm not sure if it's mature enough yet. So I hope that evdev proves usable, since I've gotten the most response from it.

Thus, one of linux's strengths has become a great hinderance. There are so many variants and setups that it seems very difficult to standardize this kind of application.

Edit: P.S. hiddev contains several structs, most of which contain a "report_id" field. Ie:

struct hiddev_report_info {
unsigned report_type;
unsigned report_id;
unsigned num_fields;
};

In fact, most of hiddev.h is starting to make sense.. too bad I can't get the device files to work.

[fingerworks]

You're not alone. We're confused too...if the solution was clear we probably would have tackled it already :)

Looks like libHID does the aforementioned full HID parsing that would have to be undone if used for the Hand Motion SDK. Not really a good fit to our Hand Motion reports.

We may be wrong, but report ID does not seem to be attached to or deriveable from evdev events.

Do you have any links to hiddev? That looked most promising.

[JerryKnight]

Well here's an overview of hiddev (http://www.frogmouth.net/hid-doco/c100.html), but like I said, not in depth enough to cover report ids. I read through /usr/include/linux/hiddev.h and found plenty of references to reports, ie. HIDIOCGREPORT (for an ioctl() call to get a report). I just wish there was a better way to find out about these things than reading header files. And apparently, the only people who mention hiddev are those trying to get UPS devices working, and even that is just "compile the kernel with CONFIG_USB_HIDDEV" so I'm googled out for now..

All I get from the /dev/usb/hiddev[0-15] device files is "No such device." Now, I am running kernel 2.6.7, so maybe there's an issue with this branch that keeps me from having working hiddev device files. I may try it out on my 2.4 kernel.