Quick Disclaimer + Update with fseq
One minor disclaimer I’d like to add is that the driver isn’t necessarily stable yet, so don’t do anything important with it loaded. If it seg faults or something similar it will crash X and anything you have open will be lost. I have it running on my system right now while I work so that I can stress test it a bit, but I’m careful about saving frequently.
Because I use MSA Remote as the primary tracker for my testing, I’ve run into TUIO fseq issues. The issue occurs when my tracker has been running, and I later restart it, thus resetting the fseq count back to 0. The driver will throw away any packets containing fseq numbers lower/older than the last accepted packet, causing any packets after an MSA Remote restart to be ignored – that is, until the fseq count catches back up.
For when I’m testing, I use the “CheckFseq” option that I recently added to disable fseq checking.
To use it, add this to the InputDevice section in your xorg.conf
Option "CheckFseq" "false"
The default for this option is “true” and is not necessary to set unless you want to turn fseq checking off. Once I start adding device properties, I will probably add an option to reset the fseq count at runtime, which would be a more useful alternative.
UPDATE: Instead of ignoring the fseq number, the better solution to this problem is to accept a message if its fseq number is larger than the last received fseq number, OR if the difference between its fseq number and the last received fseq number is larger than a certain threshold value. This is a much better approach because it takes care of the previously described issue without having to ignore anything, and on the off chance that the fseq ever wraps around (i.e. gets above 2,147,483,648 🙂 ) the fseq number will automatically be fixed without causing any issues.
Thanks goes to Martin Kaltenbrunner for that solution :).
On an unrelated note, I hate how this font displays 0’s exactly the same as o’s (the former is a zero, and the latter is the letter O).