FYI, I've recently added these. I think the Keyboard one is pretty complete (including events)... The Mouse one is missing events (not using them yet). Irrisor, maybe you can have a look at adding that that when you get a chance?
The AWTMouseInput class has a few other methods available for controlling how you want to use things... For example, it can calculate the mouse delta either by the difference between previous and current mouse positions or by using an offset from the center of a Canvas (which allows for something similar to a captured mouse.) You can also enable/disable both classes for example if you only want mouseover actions when the canvas has focus, etc. There's a few constants that need better access and such, but it seems to work pretty well.
For a taste, see my fledgling RenControlEditor.
Just updated and found VK_WINDOWS and Canvas.setPreferredSize being new in JDK 1.5.
Regarding the awt mouse events - sure, I'll have a look.
The RenControlEditor runs really fine!
I have added the listener calls into AWTMouseInput.
While doing this I had a closer look into the implementation. I would suggest to change the behaviour of the delta methods to return the same value until the next call of update (reset the delta in the update method instead of when calling getDelta). This would match the behaviour of the LWJGLMouseInput. Should I do that and add a comment to the delta methods accordingly?
I was doing that originally but it wasn't working because I was missing a call to update in the Canvas class. I'll patch that up. Thanks for adding the events, it looks good.
Hmm… one thought one this. in the LWJGLMouseInput class we have this:
/**
* <code>getWheelDelta</code> retrieves the change of the mouse wheel,
* if any.
* @see com.jme.input.MouseInput#getWheelDelta()
*/
public int getWheelDelta() {
return Mouse.getDWheel();
}
Doesn't lwjgl's system clear the delta on each call?
True, that should be changed, too.
delta change fixed on awt input class. I'll let you take on lwjgl. 
As awt stuff moved into jmex we have a dependency to jmex in the core (InputSystem). Maybe we should think about a better way to choose the implementation - e.g. by specifying a classname instead of "LWJGL"…
Agreed.
Agreed on taking the classname as constant?
This would mean we'd need constants for each input type separately instead of in InputSystem. E.g.
KeyInput.KEY_INPUT_PROVIDER_AWT = "com.jmex.awt.input.AWTKeyInput"
I can do this if you want it like this.
Or agreed on discussing it?
An alternative could be to go with the current constants and instantiate the implementation via reflection: replacing
instance = new AWTKeyInput();
with
instance = Class.forName( "com.jmex.awt.input.AWTKeyInput" ).newInstance();
Just "Agreed, we should look at doing that."
In a way, passing a classname into KeyInput for type doesn't bother me at all… If our default is the lwjgl one, then most people never have to bother with it. It's also immediately usable, no need to alter KeyInput if you write your own XXXXKeyInput class.
As you liked the idea to specify the class, I have implemented that.
We have a similar problem in LWJGLDisplaySystem: Canvas and LWJGLCanvas reside in jmex/awt, too. This cannot be solved with the same idea. I think we should move the createCanvas to some class in jmex/awt (maybe Canvas itself) as its return value should remain a subclass of Component - which is awt…