Posted by Xerxes Rånby on Jan 17, 2013; 1:06pm
URL: https://forum.jogamp.org/JOGL-2-0-OpenGL-OpenGL-ES-backend-for-LibGDX-tp4027689p4027894.html

Sven Gothel wrote

On 01/17/2013 04:01 AM, Xerxes Rånby [via jogamp] wrote:
>     noxo wrote
>     Would be nice to start work on that console based input listener...
>
> I have started some work on a NEWT LinuxEventDeviceTracker, the keyboard
> parser is about done but it needs testing.
> https://gist.github.com/ec17597f5c079708ce72
>

Great stuff!

Regarding daemon thread lifecycle:
  - start @ 1st device nativeOpen
  - stop @ last device nativeClose

.. hence we need a NEWT device association, i.e. impl.,
but I guess we already have that due to RaspPi.

I will activate this code soon for the RaspPi by changing :

Xerxes Rånby wrote

------- src/newt/classes/jogamp/newt/driver/bcm/vc/iv/WindowDriver.java -------
index 21fbea9..bdef8e6 100644
@@ -37,6 +37,7 @@ import javax.media.nativewindow.util.Insets;
 import javax.media.nativewindow.util.Point;
 
 import jogamp.newt.WindowImpl;
+import jogamp.newt.driver.linux.LinuxEventDeviceTracker;
 import jogamp.newt.driver.linux.LinuxMouseTracker;
 
 public class WindowDriver extends WindowImpl {
@@ -76,11 +77,13 @@ public class WindowDriver extends WindowImpl {
         }
         windowHandleClose = nativeWindowHandle;
         addWindowListener(LinuxMouseTracker.getSingleton());
+        addWindowListener(LinuxEventDeviceTracker.getSingleton());
         focusChanged(false, true);        
     }
 
     protected void closeNativeImpl() {
         removeWindowListener(LinuxMouseTracker.getSingleton());
+        removeWindowListener(LinuxEventDeviceTracker.getSingleton());
         
         if(0!=windowHandleClose) {
             CloseWindow(windowHandleClose, windowUserData);


 

Sven Gothel wrote

Yeah, and then the looong discussion about virtual keycodes,
i.e. independent of current keymap - see Bug 641
  https://jogamp.org/bugzilla/show_bug.cgi?id=641

I agree computer keyboard keycode namespace(s) are really a messed up.
We have so many of them:

* The USB keycode namespace. (the codes the HID keyboards actually send)
http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf
- These codes are keymap independent!

* The Linux event keycodes namespace that is a variant of the USB keycode namespace. (the codes i get from the Linux events)
/usr/include/input.h
http://www.kernel.org/doc/Documentation/input/input.txt
http://www.kernel.org/doc/Documentation/input/event-codes.txt
- These codes are also keymap independent!

* The operating GUI system specific keycode namespace (X11, Windows, MacOS, Android)
- These codes have passed through an keymap transformation ...

* AWT namespace
- These codes have passed through an keymap transformation (based on X11, Windows, MacOS...

* NEWT VK namespace
- These codes have passed through an keymap transformation based on which NEWT backend generated the code. needs fixing.
https://jogamp.org/bugzilla/show_bug.cgi?id=641

* The Unicode namespace
- These codes are keymap independent!

* The ASCII character namespace
- avoid...

so yeah.. through and careful thinking is needed to get the same behaviour and output across devices.