I tried this when I was attempting to debug the problem. At first blush, it appears to work, but there is something more subtle happening here.
After this change, try setting the mouse speed to 2 in TestAbsoluteMouse. Then move the cursor to the extreme right side of the window, and keep moving it right. The cursor behaves nicely, but watch what happens when you start moving the mouse back left. You must move the mouse quite a ways before it starts moving the cursor on the screen.
I don't remember the details (it felt very deep down the rabbit hole), but it seemed to me that the whole implementation of the speed wasn't right. I was logging some values for the mouse location deep in the code, and what appeared to be happening was that the representation of the cursor on the screen was correct, but the actual location was not – a speed of 2 would move the cursor twice as fast as a speed of 1 but at the GL level the actual location of the cursor was half of what you'd expect – that is to say, the representation of the cursorwas moving at speed 2 but the location of the cursor was still moving at speed 1, which is why when you move the mouse past the right side of the screen, the cursor is stopped, but the location keeps moving.
I know I'm not explaining it very well. After I gave up and posted the bug on the forums I tried quickly to find the spot where I got this impression and I wasn't able to. I'm at work now, but if I can track it down when I get home I'll post again.
I just tried these fixes in my application, and emitting mouse coordinates from my MouseInputListener reveals that while the cursor is indeed moving at twice speed, x and y coordinates are being modified at single speed. That is to say, I move the cursor to the top-right of my 1024x768 window, and reported coordinates are 512x384. If I continue to move the mouse up and to the right, that increases to 1024x768, but the position of the cursor does not change.
To test this, merely add a MouseInputListener to the TestAbsoluteMouse class that emits the x and y coordinates to standard out in the onMove().
It is working as designed, just not as you are hoping
There doesn't seem to be any way to adjust the pointer speed in LWJGL or thru any Java library (swing/awt) - so to provide this functionality the AbsoluteMouse code scales system mouse coordinates from LWJGL/AWT to something else - therefore if you want to change pointer speed, you must read all your mouse pointer coordinates from the AbsoluteMouse class. This is why you are seeing the behaviour that you are.
I assume you actually need to use a mouse listener for some reason? so I don't know what the solution here would be or even if there can be one. I had a little play with a couple of ideas, but all felt far to cludgy and didnt really lead anywhere useful.
It is a valid fix for the AbsoluteMouse class as long as you are only using that.
The problems RedHerring has seems to be because they are mixing mouse handlers, and as coordinates are translated by AbsoluteMouse it makes it incompatible with underlying systems. You can't for example use a MouseListener and AbsoluteMouse at the same time and get the same coordinates from both - so I guess you can't use setspeed if you need this or are using a canvas type setup with swing components… ?
I think the only real fix would be to set the mouse speed at an OS level, but I can't find an easy way of doing this (without resorting to native code).
If using hardware mouse, I would say this issue is unfixable unless LWJGL and/or AWT provide a method to change mouse speed. The solution is to use software mouse, which displays the cursor using a quad in the ortho queue.
I am kind of with JOC here and say that it is working correctly (it is moving the correct amount based on absolute coordinates). So maybe just a JavaDoc comment about how it determines the absolute position based on the set speed, and/or something about getting the position from the getHotSpot() method.
And if correct absolute mouse positioning is a must I think a person could use the robot mouse class and set the hardware mouse position after the update. Since jME isn't using event driven listeners it wouldn't care about the mouse position change; however any other listeners (attached to the canvas perhaps) would…