I know that this is not exactly ‘input’, but would it be possible to add some kind of mouse cursor control to jinput ? In fact, single method for setting mouse coordinates would be enough. If we could control mouse cursor shape (mainly for disabling it), it would be great.
I’m thinking about implementing mouse look - but to do this, I need to recenter mouse cursor every frame. I can use java.awt.Robot, but I would like to minimize dependencies on awt toolkit.
I’m going to have to oppose anything more than turning off the cursor because it doesn’t fall under the realm of device input. The mouse itself receives no special treatment under JInput, it being just one of many devices that get enumerated.
I agree… in fact I would put the pointer hiding into JOGL, even though it isn’t OpenGL it IS more display-oriented. If you aren’t using JOGL then AWT already has the ability, and I think so does LWJGL.
Ok, let’s forget about cursor hiding - my main RFE was about ability to set mouse cursor coordinates. IMHO this is a realm of device input, in same way as force feedback.
Hi
sort of, but my response would be that the decive (mouse) doesn’t give screen position, it gives movement relative to where it was, so, it might be logical to allow you to move the mouse by a certain amount (don’t read pixels here, mice know nothing about them), but not to set a position. Screen positions and pixels are somrthing that the GUI knows about.
Cheers
Endolf
Ditto. This is something that the application would have to setup. The JInput system can tell you in relative terms where/how the mouse is moving, but it actually has no idea where it is.
You may be misunderstanding the concept of what the API does. JInput is just telling you what happened - its not changing the state of anything on the screen. If you’re using JInput, you’re not controlling the ‘Java native mouse pointer’ but instead some other pointer representation you’re drawing yourself - similar to what you would have to do with LWJGL back in 0.6, though I believe they’ve done some work for peeking/poking the native cursor. All you’re getting from JInput are offsets - what you do with those offsets, button presses, etc are up to you.
[quote]Ditto. This is something that the application would have to setup. The JInput system can tell you in relative terms where/how the mouse is moving, but it actually has no idea where it is.
You may be misunderstanding the concept of what the API does. JInput is just telling you what happened - its not changing the state of anything on the screen. If you’re using JInput, you’re not controlling the ‘Java native mouse pointer’ but instead some other pointer representation you’re drawing yourself - similar to what you would have to do with LWJGL back in 0.6, though I believe they’ve done some work for peeking/poking the native cursor. All you’re getting from JInput are offsets - what you do with those offsets, button presses, etc are up to you.
[/quote]
So, what’s supposed to happen with things like graphics tablets?
E.g. if tablet is in absolute-mode, what data will JInput provide to the app? (At the moment WACOM tablets on several platforms are only supported in absolute-mode…although there are OS projects to try and provide drivers that enable the relative mode too - I hear it’s a pretty simple change!)
Obviously, if tablet is in relative mode, then the driver is going to deliver mouse-like relative events, so no problem there…
If I get any free time soon, I’ll experiment with my WACOM tablets and let you know what actually happens :), but it could be a long time before then 
Good question… in fact I just bought a Wacom tablet for my powerbook and forgot completely that I should see what JInput has to say about it.
I suspect that the tablet will show up as a device with 2-3 axis and a few buttons and that the values returned for each will be straightforward.
x & y axis will return the x & y position of the pen - assuming the device always returns absolute co-ordinates and the OS manipulates these to provide a relative “mouse” cursor.
I would guess a third axis, not sure what it will be called (z?), will likely return the pen pressure. And buttons are simple enough.
Although a tablet is not really a gaming device… so maybe support will be limited in JInput if it is going to take too much effort to make it work right. I’m betting it won’t be much trouble though.
Hi
Under the linux version at least, if the device reports having absolute axes then absolute values will be reported to jinput, and the type of axis can be obtained from jinput. I’ve not tried one to test it, as I don’t have access to one.
Will be interested to see what happens
Cheers
Endolf
i noticed that the mouse movement is shown on the axis the same as the joystick, either a 1,0 or -1
is there a way of actually determining the amount the mouse moved since the last poll?
edit:
i also noticed that having 2 mice (USB and ps2) plugged in didnt make a diference to the number of devices detected. i assume mice are reported as a single device by the OS
[quote]i noticed that the mouse movement is shown on the axis the same as the joystick, either a 1,0 or -1
is there a way of actually determining the amount the mouse moved since the last poll?
[/quote]
This only seems to happen with Windows/DirectX… on the Mac I am seeing reasonable numbers. This is only with the jinputtester app… I haven’t tried anything “real” with the mouse yet.
In OSX, the graphics tablet is in a different HID class that doesn’t even get enumerated so its highly unlikely to be supported on OSX as it would open the door to enumerating a whole host of other devices that really shouldn’t be enumerated and will cause JInput to break if those devices were plugged in.
Remember, HID enumerates anything on the USB bus - so you narrow it down by category. In this case its getting anything the HID chain quantifies as a game controller. Without categories we’d be getting a whole host of strange things like UPSs, hard disks, memory card readers, etc.
linux reports the amount moved too, I beleive Jeff has this on his work list, but it’s a long list. I’m in the US on a training course atm, then i’m moving, maybe i’ll take a look at it after that if it’s not changed.
Endolf
[quote]Remember, HID enumerates anything on the USB bus - so you narrow it down by category. In this case its getting anything the HID chain quantifies as a game controller. Without categories we’d be getting a whole host of strange things like UPSs, hard disks, memory card readers, etc.
[/quote]
But but but… HID stands for Human Interface Device…
UPSs, HDs, memory cards, etc. have no business being enumerated by HID… sigh…
Don’t shoot the messenger - I didn’t write it ;D
Yeah, I know 
So are you saying that there is basically no easy way to pick out all of the USB devices that are truly HIDs? You would figure that the USB guys would have built that into the USB HID spec somehow.
I feel like filing a bug with Apple for being bone headed…
[quote]i noticed that the mouse movement is shown on the axis the same as the joystick, either a 1,0 or -1
is there a way of actually determining the amount the mouse moved since the last poll?
edit:
i also noticed that having 2 mice (USB and ps2) plugged in didnt make a diference to the number of devices detected. i assume mice are reported as a single device by the OS
[/quote]
Yes this is an open issue.
Shouldn’t be THAT hard to fix but I’m snowed under with Sun server-side game stuff.
Do we have any volunteers?
While we’re at it, it was also decided that the queuing of the KB input really wasn’t the most desirable behavior. Whoever hits the oen issue should probably hit the other.
Hi
I can try and take a look at the mouse values one, but the other I dunno where to start on, again, this depends on me getting my knackered old laptop to play nice with forte and jinput.
Cheers
Endolf