
No mouse input from OpenTK.Input.Mouse.GetState() on Mac
Posted Friday, 21 December, 2012 - 21:26 by AndyKorth| Project: | The Open Toolkit library |
| Version: | 1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | in progress (review) |
Jump to:
Description
Mouse input via OpenTK.Input.Mouse.GetState() doesn't work on Mac OS X. It always reports no buttons pressed and a position of (0,0).
I have commit a replication example here:
https://github.com/andykorth/opentk/blob/master/Source/Examples/OpenTK/T...
The short of it is really just:
if(OpenTK.Input.Mouse.GetState()[MouseButton.Left]){ Console.WriteLine("You clicked the left mouse button!"); }
I'd appreciate it if anyone on other platforms could say if I've got my replication correct.. ie: This should work, right?
I'll be looking for a fix next. Note that this input method is suggested in the docs here: http://www.opentk.com/doc/input


Comments
#1
This is probably the same issue as http://www.opentk.com/node/2800
In HIDInput.cs,
MouseDevices (and keyboard devices) is populated from:
The device key isn't sent to the DeviceValueReceived callback. (You can check in /System/Library/Frameworks/IOKit.framework/Headers/hid/IOHIDBase.h) Instead I think the intention was to register different callbacks for each device - specifically different callbacks for the mouse and keyboard, instead of trying to determine which input was from which device inside the DeviceValueReceived callback.
Jase's solution of using the context variable to identify the device is pretty good, it requires a lot less touching of the code. Will keep you folks up to date.
#2
In the interest of being through, this method of accessing the keyboard doesn't work:
As expected, for the same reason.
#3
I have fixed the mouse issue, and I have mouse events in OpenTK! Very exciting :D
Patch:
http://kortham.net/temp/OpenTKIssue3242.txt
And it's been pushed here: https://github.com/andykorth/opentk
In this commit:
https://github.com/andykorth/opentk/commit/39c3f3f54324b80262d10fc5af823...
#4
I thought there were some other keyboard issues, but after a lot more testing than I should have needed to do, it seems like the above commit has fixed keyboard as well. For the sake of documenting what I found:
Press A on the keyboard and hold it, and it generates these four events:
IOHIDValueGetIntegerValue: 4 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: -1
IOHIDValueGetIntegerValue: 0 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: 1
IOHIDValueGetIntegerValue: 1 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: 4
IOHIDValueGetIntegerValue: 4 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: -1
Release A and these four events are generated:
IOHIDValueGetIntegerValue: 0 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: -1
IOHIDValueGetIntegerValue: 0 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: 1
IOHIDValueGetIntegerValue: 0 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: 4
IOHIDValueGetIntegerValue: 0 IOHIDElementGetUsagePage: KeyboardOrKeypad IOHIDElementGetUsage: -1
So I'm going to just ignore the usage of -1.
Here's the change to quiet down some of the error printing:
https://github.com/andykorth/opentk/commit/c98d9e4503cf8f9498a17ddd2d37b...
References: http://www.usb.org/developers/devclass_docs/Hut1_11.pdf and HID headers.