emacinnes's picture

macosx problems with device input

Project:The Open Toolkit library
Version:1.0-2010-10-06
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:open
Description

Device input is non-functional on MacOSX (Snow Leopard 10.6.8, mono 2.10.9) in the latest binary download of OpenTK, as well as version 1.0.278.44921. This includes Mouse input as well as Keyboard input, however with slight differences between the two. Mouse input is simply not recognised, whereas any keyboard input causes a hang (the spinning rainbow cursor). No error messages are received on the command line.

This is true of custom applications, as well as the OpenTK Examples.exe binary that is included.

EDIT; Note that this relates to the gamewindow.mouse and gamewindow.keyboard event overloads to detect device states. As per a previous post on this issue, I moved the device input to use the deprecated InputDevice structure, which results in the same issues. The mouse cursor values are also not updated.

EDIT2: The same code works fine in Windows and Linux with device inputs. After taking the OpenTK code and stepping through it, there's something really bizarre going on internally:
Mouse:
There appears to be a duplicate MouseDevice class created somewhere. I put a unique ID on the MouseDevice constructor based on a static var, and the values being retrieved by the GameWindow were on MouseDevice 2, whereas the CarbonGLNative that was getting the events was updating MouseDevice 1. There is only one MouseDevice class listed in the InputDevice structure.

This I suspect is directly related to the hardcoding of the InputDevice.Mouse[0] in the MacOSX implementation, as my app has two contexts, two CarbonGLNatives are running, and therefore two MouseDevices have been created, but somehow the mouse events have got mixed up from one window to the other internally.

Keyboard:
The keyboard events on CarbonGLNative are not being fired at all, neither are they even reaching the EventHandler function or DispatchEvent. This does not initially appear to be for the same reason as the mouse, the keyboard events do not reach the application at all, neither in the background window nor the foreground one.

EDIT4:
Confirmed! If I remove the background GL context from the application, the mouse and keyboard inputs work normally, as far as my application goes. The OpenTK examples.exe was a red herring, it still seems to be hanging on inputs, but that may well be a WinForms + OpenGL issue, WinForms is flaky in mono on linux and never reacted well with OpenGL contexts there either, I assume MacOSX is probably just worse off as far as winforms compatibility goes.