OK, it works (I see a compass and some mem usage data and an X cursor) - although the entire render window just paints blank grey (?).
It should render some sky-gradients, but if it doesn't I don't really care, as that's not the main prob atm.
However, the mouse cursor jumps wildly so I have no idea if it's working or not.
I think that's the linux-behaviour i heard from others.
Note: you CANNOT programmatically jump the mouse cursor in the middle of mouse-movement like you are doing.
Not a very strong argument, but: I *can* do it on Windows.
Besides that: I don't think it's in the middle of the movement, as it's just an event fired by the EDT *after* the native event occured. (?)
there are plenty of tracking devices that are absolute rather than relative, and you break all of them with your method
That's an interesting point. But would you expect FPS-style movement to take that into account? If I were using JInput I would have only access to relative movement right?
although of course I have the built-in trackpad for emergencies, which incidentally wasn't controllable either
Something to be expected as it's probably handled like a normal mouse, which didn't work for other testers on linux too.
Can you send me a stack trace so I can have a look?. Even if you don't want to use JInput, i'd like to know whats going on so that others don't have the same issue.