summaryrefslogtreecommitdiffstats
path: root/src/newt/native/X11Display.c
Commit message (Collapse)AuthorAgeFilesLines
* NEWT KeyEvent: Use UTF-16 UniCode for key-code and key-symbol exposing well ↵Sven Gothel2013-04-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | defined key encoding and simplify usage. Note, we use one collision to reduce key-code range: [0x61 .. 0x78] keyCodes [F1..F24] collide w/ ['a'..'x'] Since keyCode/Sym won't use lower capital a-z, this is a no isssue. KeyEvent: - 'printable' type is being determined by a nonPrintableKeys table, while 'action' type is set in case !printable and !modifier. - public ctor hidden, use create(..) method instead. This allows us to ensure modifier bit are properly set (incl. the keySym one) w/o performance loss. - ctor validates that only one of the type flags is set, printable, modifyable or action. WindowImpl: - Using IntBitfield of 255 bits to track pressed state, while removing the repeat state tracking since it is redundant. The Windows impl. uses a single field to validate whether a key was already repeated or not. - Properly cast keyCode short values to int for tracking! AWTNewtEventFactory, SWTNewtEventFactory: - Add translation of keyCode/Sym from and to NEWT - All tested via: - Newt -> Awt for AWTRobot - OSX CALayer: AWT -> NEWT - SWT tests X11: - Add VK_CONTEXT_MENU mapping (XK_Menu) LinuxEventDeviceTracker: - Fix apostrophe and grave mapping, i.e. to VK_QUOTE and VK_BACK_QUOTE. Adapted all unit tests, especially: - TestNewtKeyCodesAWT: More fine grained keyCode ranges to test using proper keyCode symbols.
* Bug 641 NEWT/X11: Deliver 'J_VK_WINDOWS'; keySym is layout independent for ↵Sven Gothel2013-04-081-3/+16
| | | | dead-keys (zero keyChar); For 'unshifted' keySym's also unmask Ctrl and Mod* states
* Bug 641 NEWT: X11 Deliver keyCode layout independent, keySym layout ↵Sven Gothel2013-04-081-17/+57
| | | | | | | | | | dependent and UTF-16 keyChar value On X11, the layout dependent keySym was not delivered [1], as well as the UTF-8 to UTF-16 translation was missing [2]. [1] is solved using XLookupString w/o ShiftMask [2] is solved using JNI's NewStringUTF, which takes UTF-8.
* Bug 678: Differentiate ALT (left) and ALT_GRAPH (right) on X11, EventDev, ↵Sven Gothel2013-04-061-8/+24
| | | | | | | Windows and OSX - X11: Memorize pressed Alt_R to decide which 'alt' has to be used for non key modifier fetching - Windows: Only use GetKeyState(..) and compare the US vkey, since int. kbd layout use reduced scancode
* Bug 678 (fix), Bug 641 (API + Windows Impl.), Bug 688 (prep): Update NEWT's ↵Sven Gothel2013-02-191-91/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | KeyEvent handling while distinguish keyCode (kbd layout independent) and keySym (kbd layout dependent) API Changes: - Virtual key codes and symbols are of type short. - KeyEvent.keySymbol() shall return a layout dependent value (Bug 641) - Method returns former keyCode() value, which was layout dependent. - Returns 'short' value - KeyEvent.keyCode() returns a short value, instead of int - KeyEvent.keyCode() shall return a layout independent value (Bug 641) - To ease implementation, we only 'require' the scan code to be mapped to a 'US Keyboard layout', which allows reusing layout dependent code while preserving the goal to have a fixed physical key association - Implementation status: - Windows OK - X11 TODO - OSX: 50/50 TODO - Using layout independent 'action keys' - Using layout dependent 'printable keys' - returning above semantics for both, keyCode and keySym - Android 50/50 TODO - Returning the layout independent keyCode - Mapping probably incomplete - KeyEvent.EVENT_KEY_TYPED and KeyListener.keyTyped(KeyEvent) (Bug 688) - Marked DEPRECATED - No more called for auto-repeat events - Synthesized in WindowImpl.consumeKeyEvent(..): No more injection by native- or java driver code - NEWTEvent.eventType: int -> short - field, as well as all method involving eventType changed to short. - NEWTEvent.isSystemEvent: REMOVED - Never used as well as never being implemented properly Internal Changes: - Simplified keyEvent driver code - Especially the Windows native driver's mapping code could be simplified using scanCode and MapVirtualKeyEx - NEWT Event Factories: hashMap -> switch/case Unit Tests: - - Added NewtCanvasAWT Offscreen Layer Tests important to test the AWT -> NEWT translation on OSX/CALayer: - TestNewtKeyCodeModifiersAWT - TestNewtKeyCodesAWT - TestNewtKeyEventAutoRepeatAWT - TestNewtKeyEventOrderAWT - TestNewtKeyPressReleaseUnmaskRepeatAWT
* NEWT-MouseEvent getWheelRotation() API Update - Fixes Bug 659: NEWT ↵Sven Gothel2013-01-141-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Horizontal Scrolling Behavior (OSX, X11, Win32); Bug 639: High-Res Mouse-Wheel - API update 'float getWheelRotation()': Usually a wheel rotation of > 0.0f is up, and < 0.0f is down. Usually a wheel rotations is considered a vertical scroll. If isShiftDown(), a wheel rotations is considered a horizontal scroll, where shift-up = left = > 0.0f, and shift-down = right = < 0.0f. However, on some OS this might be flipped due to the OS default behavior. The latter is true for OS X 10.7 (Lion) for example. The events will be send usually in steps of one, ie. -1.0f and 1.0f. Higher values may result due to fast scrolling. Fractional values may result due to slow scrolling with high resolution devices. The button number refers to the wheel number. - Fix Bug 659: NEWT Horizontal Scrolling Behavior (OSX, X11, Win32) - See new API doc above - X11/Horiz: Keep using button1 and set SHIFT modifier - OSX/Horiz: - PAD: Use highes absolute scrolling value (Axis1/Axis2) and set SHIFT modifier for horizontal scrolling (Axis2) - XXX: Use deltaX for horizontal scrolling, detected by SHIFT modifier. (traditional) - Windows/Horiz: - Add WM_MOUSEHWHEEL support (-> set SHIFT modifier), but it's rarely impl. for trackpads! - Add exp. WM_HSCROLL, but it will only be delivered if windows has WS_HSCROLL, hence dead code! - Android: - Add ACTION_SCROLL (API Level 12), only used if layout is a scroll layout - Using GestureDetector to detect scroll even w/ pointerCount > 2, while: - skipping 1st scroll event (value too high) - skipping other events while in-scroll mode - waiting until all pointers were released before cont. normally - using View config's 1/touchSlope as scale factor - Fix Bug 639: High-Res Mouse-Wheel - getWheelRotation() return value changed: int -> float allowing fractions, see API doc changes above. - Fractions are currently supported natively (API) on - Windows - OSX - Android - AndroidNewtEventFactory ir refactored (requires an instance now) and AndroidNewtEventTranslator (event listener) is pulled our of Android WindowDriver.
* Fix NEWT KeyEvent: Deliver keyChar w/ pressed and released; Deliver proper ↵Sven Gothel2012-10-311-13/+13
| | | | | | | | | | | | | | | | | | | | | | modified flags and modifier-key events; Simplify Windows key handling Preface: Modifier-keys are SHIFT, CTRL, ALT and META and they have a matching modifier-bit. - Simplify Windows key handling - Employ MapVirtualKey(..) for virtual-key to character and scancode to virtual-key mappings, allowing to drop tracking of keyCode to keyChar in java code. This also removes the platform restriction of delivering keyChar at TYPED only. - Deliver keyChar w/ pressed and released - Due to the lift restriction on the Windows platform (see above), we can deliver keyChar w/ all key events on all platforms. - Deliver proper modified flags and modifier-key events All modifier-keys deliver pressed, released and typed events with their modifier-bit set. The above is covered by unit tests, which passed on X11, Windows and OSX (manual test run).
* NEWT X11 Display: Ignore events w/ NULL window, instead of throwing a ↵Sven Gothel2012-10-281-7/+6
| | | | disturbing and fatal RuntimeException
* Fix NEWT KeyCode: Basic KeyCode Validation on X11, Windows and OSXSven Gothel2012-10-281-0/+2
| | | | | | | - X11: Add VK_QUOTE mapping - OSX: Add single shift, ctrl alt key press; Fix mapping: Command -> Windows, Option -> ALT, add BACK_QUOTE and QUOTE.
* Fix Bug 601 - Auto-Repeat Behavior: Adding unit tests for typed key order w/ ↵Sven Gothel2012-10-261-0/+2
| | | | | | | | | and w/o auto repeat. Incl. fix for Windows. Auto-Repeat tests recognizes whether auto-repeat could be triggered by AWT Robot. The latter is not possible on Windows, hence manual testing was required on this platform. Impact: X11, Windows and OSX produce proper key sequence incl. auto-repeat modifier mask.
* NEWT X11/KeyMap: Add XK_grave -> J_VK_BACK_QUOTESven Gothel2012-10-091-0/+2
|
* Relax Bug 613 workaround of commit 92398025abdabb2fdef0d78edd41e730991a6f94Sven Gothel2012-10-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Utilizing a GlobalToolkitLock in general to lock the display connection results in deadlock situations where locked surfaces signal other [offscreen] surfaces to render. We have to see whether we find a better solution, for now sporadic XCB assertion still happen. But it is preferrable to point to the root cause, then to jumping through hoops to complicate locking or even to deadlock. Locking: - X11GLXGraphicsConfigurationFactory add missing device locking in: - getAvailableCapabilities - chooseGraphicsConfigurationStatic - Newt/X11Window: Discard display events after window close. Relax ATI XCB/threading bug workaround: - ToolkitProperties: requiresGlobalToolkitLock() -> hasThreadingIssues() - NativeWindowFactory: Don't use GlobalToolkitLock in case of 'threadingIssues' the impact is too severe (see above) - NativeWindowFactory: Add getGlobalToolkitLockIfRequired(): To be used for small code blocks. If having 'threadingIssues' a GlobalToolkitLock is returned, otherwise NullToolkitLock. - X11GLXContext: [create/destroy]ContextARBImpl: Use 'NativeWindowFactory.getGlobalToolkitLockIfRequired()' for extra locking Misc Cleanup: - *DrawableFactory createMutableSurface: Also create new device if type is not suitable - *DrawableFactory createDummySurfaceImpl: Pass chosenCaps and use it (preserves orig. requested user caps)
* Fix Bug 616: X11: Remove XInitThreads() dependency while cleaning up device ↵Sven Gothel2012-09-271-91/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | locking, resulting in a native-lock-free impl. The X11 implementation details of NativeWindow and NEWT used the X11 implicit locking facility XLockDisplay/XUnlockDisplay, enabled via XInitThreads(). The latter useage is complicated within an unsure environment where the initialization point of JOGL is unknown, but XInitThreads() requires to be called once and before any other X11 calls. The solution is simple and thorough, replace native X11 locking w/ 'application level' locking. Following this pattern actually cleans up a pretty messy part of X11 NativeWindow and NEWT, since the generalization of platform independent locking simplifies code. Simply using our RecursiveLock also speeds up locking, since it doesn't require JNI calls down to X11 anymore. It allows us to get rid of X11ToolkitLock and X11JAWTToolkitLock. Using the RecursiveLock also allows us to remove the shortcut of explicitly createing a NullToolkitLocked device for 'private' display connections. All devices use proper locking as claimed in their toolkit util 'requiresToolkitLock()' in X11Util, OSXUtil, .. Further more a bug has been fixed of X11ErrorHandler usage, i.e. we need to keep our handler alive at all times due to async X11 messaging behavior. This allows to remove the redundant code in X11/NEWT. The AbstractGraphicsDevice lifecycle has been fixed as well, i.e. called when closing NEWT's Display for all driver implementations. On the NEWT side the Display's AbstractGraphicsDevice semantics has been clarified, i.e. it's usage for EDT and lifecycle operations. Hence the X11 Display 2nd device for rendering operations has been moved to X11 Window where it belongs - and the X11 Display's default device used for EDT/lifecycle-ops as it should be. This allows running X11/NEWT properly with the default usage, where the Display instance and hence the EDT thread is shared with many Screen and Window. Rendering using NEWT Window is decoupled from it's shared Display lock via it's own native X11 display. Lock free AbstractGraphicsDevice impl. (Windows, OSX, ..) don't require any attention in this regard since they use NullToolkitLock. Tests: ====== This implementation has been tested manually with Mesa3d (soft, Intel), ATI and Nvidia on X11, Windows and OSX w/o any regressions found in any unit test. Issues on ATI: ============== Only on ATI w/o a composite renderer the unit tests expose a driver or WM bug where XCB claims a lack of locking. Setting env. var 'LIBXCB_ALLOW_SLOPPY_LOCK=true' is one workaround if users refuse to enable compositing. We may investigate this issue in more detail later on.
* Fix Bug 601: Harmonize order of key events incl. auto-repeat and adding ↵Sven Gothel2012-09-161-2/+16
| | | | | | | | | | | | | | | | | | | | | AUTOREPEAT_MASK modifier bit. Refine InputEvent toString(..) and list modifiers by name. As now described in NEWT's KeyEvent: +/** + * Key events are delivered in the following order: + * <ol> + * <li>{@link #EVENT_KEY_PRESSED}</li> + * <li>{@link #EVENT_KEY_RELEASED}</li> + * <li>{@link #EVENT_KEY_TYPED}</li> + * </ol> + * In case the native platform does not + * deliver keyboard events in the above order or skip events, + * the NEWT driver will reorder and inject synthetic events if required. + * <p> + * Besides regular modifiers like {@link InputEvent##SHIFT_MASK} etc., + * the {@link InputEvent#AUTOREPEAT_MASK} bit is added if repetition is detected. + * </p> + */
* NEWT Platform Driver: Uniform impl. class names [DisplayDriver, ↵Sven Gothel2012-08-181-11/+11
| | | | ScreenDriver, WindowDriver] to reduce complexity and programatic selection.
* C code: remove warningsSven Gothel2012-07-061-4/+4
|
* NativeWindow/Newt X11ErrorHandler enhancement / unification - don't throw ↵Sven Gothel2012-07-051-23/+58
| | | | | | | | | | | | exceptions. Handles also XAWT BadMatch X_SetInputFocus. X11ErrorHandler code now dumps proper information about the opcode and error message and the running Java thread. Having propery "nativewindow.debug.X11Util.XErrorStackDump" or "nativewindow.debug=all' set, a stack trace is dumped. Since the X11ErrorHandler may catch an XAWT error: BadMatch X_SetInputFocus, we cannot throw an exception and better keep running.
* Fix Bug 560 and NEWT window closing behavior in general for all platforms.Sven Gothel2012-05-011-3/+6
| | | | | | | | | | | | | | | | | | | | | | - NEWT/WindowImpl: - 'void windowDestroyNotify()' -> 'boolean windowDestroyNotify(boolean force)', allowing to signal a forced close, as well as replying whether the window has been closed. (called by native code) - destroy(): set states before releasing the window lock - NEWT/X11: Pass windowDeleteAtom for reconfigure window, in case of reparenting child to top-level - NEWT/OSX: - Add 'BOOL windowShouldClose()' impl., ie. having a chance to reject the close attempt - Common impl. for 'windowShouldClose' and 'windowWillClose' -> 'windowClosingImpl' utilizing new 'windowDestroyNotify' code (see above). Fixes bug 560. - NEWT/JOGLNewtApplet1Run: Refine out-of browser window behavior for window-close button - default: move NEWT window back to browser parent - closeable: close NEWT window - jogl-test-applets: Add NApplet-Closeable test (Applet out-of browser window is closable)
* DEBUG Output: More thread-names to drawable/context lifecycle; Remove ↵Sven Gothel2012-02-221-1/+1
| | | | massive '!!!' occurence
* NEWT/X11: Fix regressions of commit ↵Sven Gothel2011-12-231-3/+3
| | | | f3f794fe37a7e33a771a4a702f3f46ead4dc6d03: Unresolved symbols. Disable VERBOSE.
* NEWT Multi-Monitor 1/2: Allow negative window position; Validate Screen-Index;Sven Gothel2011-12-231-0/+660
- Allow negative window position, using flag 'autoPosition' to mark a custom user position. This impacts Windows and X11 window creation code, which supports native auto positioning. - Screen: Validate Screen-Index. In 'big-desktop' mode the Screen index is always 0. This is true for X11 with Xinerama enabled and MS-Windows in general. Platforms w/o multiple Screen support always use index 0. - X11: Separate X11 Display/Screen/Window native code in their respective C files - Windows test scripts: use '%*' to catch all arguments - Add missing (c)