The mouse input system in jME has long suffered from some issues of smoothness. This is especially noticeable when moving the camera frustum from a high fps view to a very low fps view and back again. The issue looks like a bug in how the mouse camera rotation is generated. It uses the displacement of the mouse X the difference in time since the last input system update X an input speed. (actually, I think the speed is actually done twice.) Throwing out the speed since it is a constant, we are left with a mouse displacement (or in other words, how far the mouse moved since the last update on a given axis) and the time.
The bug is that there is no need for time since we really only need to account for displacement amount. All the time variable is doing is magnifying the result when the fps is low (thus raising the amount of time since the last update) or diminishing the result when the fps is high. The time variable was really just a carry-over from the key input system where the action (such as moving forward) is a boolean on/off deal and time is used to account for how long the button is in the on state.
What does this mean? I will be doing a small rework of the mouse input internals (classes like MouseLook and MouseNodeLook which are used by classes like FirstPersonHandler, etc.) to fix the bug. Unfortunately though, this *may* mean that if you are using jME, your mouse input speed may need readjusting. If you were just using default values though, you should be ok as I will attempt to keep things as close to the same as possible. I will also be removing the speed*speed affect of having speed in the MouseLook classes and in the actions (it will just stay in the action.)