First attempt GLFW gamepad driver (don't merge yet?) #222

mcclure · 2020-02-13T19:59:15Z

This is a standalone driver that provides gamepad support on desktop. Gamepad support on oculus mobile would have to be done separately. In my testing this works on Mac and Windows.

This should probably wait until the isTracked changes to go in. Right now isTracked() returns false for all gamepads because they don't have a pose.

mcclure · 2020-02-13T20:00:41Z

src/core/os_glfw.h

@@ -10,6 +10,9 @@
 #include <GLFW/glfw3native.h>
 #endif

+#ifdef OS_GLFW_H


I did something dubious here. Right now os_glfw.h can only be included in one file because it defines non-static symbols. But os_glfw seems(?) to be the only way we have of getting glfw.h. For this reason gamepad.c #defines OS_GLFW_H and then includes os_glfw.h. Maybe this could be done a cleaner way.

os_glfw is designed to only be included in one translation unit right now, the os_*.c translation units (since it provides most of the symbols in os.h).

Joystick input could go through the existing "os" layer or GLFW could be included directly.

If it's OK with you I think I'll switch to including GLFW directly.

I wonder if the driver should be named "GLFWGamepad" instead of "Gamepad", or something.

mcclure · 2020-02-13T20:03:00Z

src/modules/headset/headset.h

+  MAX_DEVICES,
+
+  DEVICE_GAMEPAD_FIRST = DEVICE_GAMEPAD_1,
+  DEVICE_GAMEPAD_LAST = DEVICE_GAMEPAD_1,


The current gamepad driver accepts 1 gamepad at a time. If you have 2 plugged in and unplug 1, it promotes the other plugged-in one.

But notice, the way gamepad.c is written it can handle an arbitrary number of gamepad devices. The GLFW maximum number of gamepads is, I think, 14. I think having 4 gamepad devices would make a lot of sense. In my testing I had a problem because "spacemouse emulator" was showing up as a joystick device on Windows according to GLFW, so a real gamepad never got a chance to grab the GAMEPAD_1 slot (I uninstalled spacemouse for testing to work around this). If we supported 4 gamepads this would not have been a problem.

mcclure · 2020-02-13T20:03:49Z

src/modules/headset/gamepad.c

+
+void discoverGamepads() {
+  for(int jid = 0; jid < GLFW_JOYSTICK_LAST; jid++) {
+    if (glfwJoystickPresent(jid)) {


I use glfwJoystickPresent(), but maybe we should use glfwJoystickIsGamepad(). It is not clear to me exactly which devices say yes to "present" but not to "isGamepad".

GLFW docs say if you're only interested in gamepads, you can use isGamepad as a replacement for isPresent

bjornbytes · 2020-02-14T16:41:37Z

Currently it isn't possible to access the separate left/right triggers, left/right joysticks, or access the dpad. These features seem important for gamepad input.

Also I think mapping both shoulder buttons to the grip button/axis is confusing, if I saw a grip input on a gamepad I would think it was force-sensitive. Maybe there could be buttons for shoulder/left and shoulder/right.

mcclure · 2020-02-14T17:32:57Z

Agreed, those were stopgap behaviors.
I can think of two approaches for the final behavior:

Add Trigger/left and Trigger/right as you suggest— this does mean cluttering up the enums a lot for a driver we're not even sure we need
Allow you to say something like getStatus("gamepad/1", "thumbstick", 2). So getStatus("gamepad/1", "thumbstick", 1) or getStatus("gamepad/1", "thumbstick") would map to left thumbstick and getStatus("gamepad/1", "thumbstick", 2) would map to right thumbstick. That would complicate the code for getStatus/glob a little but would make talking to a gamepad very much like talking to a handset.

What do you think of possibility 2?

I have no idea what to do with the D-pad.

bjornbytes · 2020-02-14T17:59:28Z

Option 2 sounds like "arrayed buttons and axes" are being proposed. So anywhere a DeviceButton or DeviceAxis is used, another index is used to specify which index of the specified button/axis type is being requested. This would apply to isDown, isTouched, getAxis, and getStatus, and I'm guessing the index would default to 1.

bjornbytes · 2020-02-14T18:01:06Z

I think the dpad could be 4 new buttons.

mcclure · 2020-02-14T21:27:42Z

@bjornbytes What you say in both of your new comments sounds good to me.

bjornbytes · 2020-02-15T00:25:19Z

Ok. I can think of some downsides to adopting the system of arrayed buttons and axes.

It could be confusing or inconsistent to have 'gamepad/1' and 'button', 1 as 2 different ways of representing arrayed things.
Since the full representation of a button/axis consists of 2 values instead of 1 now, it makes it slightly more difficult to add additional arguments to any of the functions that take buttons/axes, and there could be problems with Lua's multiple args handling which wouldn't happen if it was a single value.
Loss of semantics around left/right

There are some benefits though like being able to use numbers instead of format strings if you wanted to programmatically generate buttons or something. So the benefits would need to be weighed against the drawbacks.

Some zip writers do not write the compressed size to the local file headers.

Lua was happily compiling nil chunks and making them return empty strings, which was not a good error experience in situations where your file couldn't be loaded properly. Now we return nil plus an error message, which matches LOVE and other Lua conventions.

Instead it returns a boolean indicating if the send worked.

Instead of anisotropic being its own filter, it is now removed and anisotropy settings can be used with any of the other filter modes.

Surprisingly, this appears to be the only place reading out of enum arrays like this, so there shouldn't be any other places to fix.

as mentioned on slack. there are some situations you can get into (high load in some place or other) where the newer frame submission api will behave much more consistently, and I've noticed no negative effects. besides, the other one is deprecated as best i can tell.

update ovr driver to newer frame submission api

… it is buggy

Kill mat4_transform_project

seems a little strange that vibrating head or something would affect the right controller.

implement haptics on oculus desktop

mcclure · 2020-04-15T18:39:58Z

Merged with master and fixed some bugs.

Outstanding questions before this can be merged:

How do you loop over controllers? getHands returns only hand/left and hand/right.
How do you detect if a controller is present? isTracked will always be false.
How do we handle multiple triggers / multiple thumbstick axes? The two options I see here are introduce separate THUMBSTICK_LEFT and THUMBSTICK_RIGHT or add an, index parameter to isDown and getAxis, from the above I can't tell if bjorn signed on to a particular one.

bjornbytes · 2020-07-10T10:55:29Z

I think for the looping, it would be okay to delegate this to Lua where you can do a for i = 1, 4 and local device = 'gamepad/' .. i thing. Should try to improve the convenience of that at some point though.
It does seem like there needs to be a new "isPresent" concept for the gamepads. I guess headset drivers that don't have connectivity info for some devices could return either nil or true if they're not sure.
I'd prefer separate enumerants like thumbstick/left and thumbstick/right for the multiple buttons/axes. I want it to be easier in the future to do button mappings (started thoughts in Action-based Input System #245), but I think it's too restrictive to implement indexed buttons here just so the left trigger/thumbstick match up with the one on VR controllers.

mcclure · 2020-07-10T17:24:01Z

"it would be okay to delegate this to Lua"

if we include the isPresent.

"I'd prefer separate enumerants like thumbstick/left and thumbstick/right for the multiple buttons/axes"

Alright, but long term I'd still like some sort of method (or easy means to build a method) for merging "thumbstick", "thumbstick/left" and "touchpad" into one input in apps that need that.

Sorry I haven't worked on this in a while…

bjornbytes · 2020-08-16T01:27:02Z

I wonder if getPose could return true and all zeroes if the gamepad is connected. This causes an issue with PS move controllers because with those you would no longer be able to tell if tracking is lost for those. But you would at least be able to do lovr.headset.isTracked('gamepad') for detection. It's a hacky compromise -- I do have some ideas for improving this but it'd be nice to get gamepad support in the meantime.

bjornbytes · 2021-07-19T08:14:27Z

I'm...not sure what to do about this, but I think about it often. There should definitely be joystick input, eventually. But the current structure of the headset module, and how it handles input, makes integrating joysticks challenging. The design of OpenXR's action system, which lovr.headset sort of followed, is not really conducive to joysticks (can't have 'numbered' devices, can't detect whether a device is present/connected).

Thinking super highlevel/longterm I think aligning with OpenXR actions was a mistake, and an engine needs to have its own input abstraction, so that it can integrate with keyboard/mice/joysticks/spacethings. Maybe that input abstraction is still action-based, but it has to be on top of OpenXR, treating it like a lower-level driver. Otherwise it simply can't integrate with the other stuff cleanly. So, maybe someday it will look like lovr.input and lovr.headset? Who knows.

Plugins are a thing now. Maybe starting there would be more successful, free from the confines of lovr.headset? There's even https://github.com/Rabios/lovr-joystick which is an ffi-based solution.

It also seems like this PR has fallen victim to gitrot.

I think it's best to close backs away slowly

First attempt GLFW gamepad driver

d43a48d

mcclure changed the title ~~First attempt GLFW gamepad driver~~ First attempt GLFW gamepad driver (don't merge yet?) Feb 13, 2020

mcclure commented Feb 13, 2020

View reviewed changes

mcclure and others added 21 commits February 19, 2020 17:33

Merge master->driver-gamepad

dc1d887

Fix merge errors, roll back os_glfw.h change

44c8b3a

opengl: Init compareMode for native textures;

81f4232

Start core/gpu;

238496d

core/gpu: indirect drawing commands;

cb4a7a5

core/gpu: gpu_set_vertex_buffers; fixes;

0620cad

core/gpu: will it blend;

aadadb9

core/gpu: Add all uncompressed texture formats;

a658da7

core/gpu: attribute formats;

6452f51

core/gpu: add vulkan backend;

7d2bec7

core/gpu: gl backend compiles;

f428cea

core/gpu: texture views;

b9b8062

zip: read compressed size from central directory;

93d556b

Some zip writers do not write the compressed size to the local file headers.

core/gpu: start shader stuff; coherent buffer mapping;

3d3fb71

Fix Source:setLooping assert;

5d8bf1d

Opaque Buffer;

b045d42

Opaque Texture;

52d4f7e

Opaque Canvas;

d034e8c

Opaque Shader;

aabb8cb

Opaque Mesh; Opaque OpenGL;

f8b8d42

bjornbytes and others added 24 commits February 26, 2020 14:40

Add restart cookie; lovr.event.restart; arg.restart;

90b605f

Shader:send doesn't error on unknown uniform;

0d09841

Instead it returns a boolean indicating if the send worked.

oculus_mobile: Add handModels to bridge;

1d6b761

Scope a variable better;

45648ba

CMake: Don't exclude Lua lib targets;

9c044ee

Tup: emscripten support; LuaJIT flag;

8dcc977

tup: fully support web builds;

a18121b

Add preliminary WebXR backend;

6f6de92

Allow anisotropy to be used with any TextureFilter;

c02839f

Instead of anisotropic being its own filter, it is now removed and anisotropy settings can be used with any of the other filter modes.

Fix lovr.graphics.getDefaultFilter;

a01cc5a

Convert some collider functions to use vectors;

6d0369d

Fix sampler uniform error message enum;

e553672

Surprisingly, this appears to be the only place reading out of enum arrays like this, so there shouldn't be any other places to fix.

Allow initializing empty TextureData with Blob;

37d8df4

Add oculus_touch to action manifest;

aed0499

Merge pull request bjornbytes#234 from shakesoda/patch-1

64362a0

update ovr driver to newer frame submission api

Remove mat4_transform_project, it not only duplicates mat4_transform,…

d8abfcf

… it is buggy

Merge pull request bjornbytes#236 from mcclure/no-mat4-project

89e2e6d

Kill mat4_transform_project

implement haptics on oculus

14e79bf

ignore haptics for non-hands

809d9b7

seems a little strange that vibrating head or something would affect the right controller.

use clamp/max macros

34cef26

Merge pull request bjornbytes#238 from shakesoda/patch-2

eb03795

implement haptics on oculus desktop

Merge driver-gamepad with current master

f297072

Fix bugs: activate gamepad driver properly, multiple-detect bug

0ef8d74

bjornbytes closed this Jul 19, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First attempt GLFW gamepad driver (don't merge yet?) #222

First attempt GLFW gamepad driver (don't merge yet?) #222

mcclure commented Feb 13, 2020

mcclure Feb 13, 2020

bjornbytes Feb 14, 2020

mcclure Feb 14, 2020

mcclure Feb 13, 2020

mcclure Feb 13, 2020

bjornbytes Jul 10, 2020

bjornbytes commented Feb 14, 2020 •

edited

mcclure commented Feb 14, 2020

bjornbytes commented Feb 14, 2020 •

edited

bjornbytes commented Feb 14, 2020

mcclure commented Feb 14, 2020

bjornbytes commented Feb 15, 2020 •

edited

mcclure commented Apr 15, 2020

bjornbytes commented Jul 10, 2020

mcclure commented Jul 10, 2020

bjornbytes commented Aug 16, 2020

bjornbytes commented Jul 19, 2021

First attempt GLFW gamepad driver (don't merge yet?) #222

First attempt GLFW gamepad driver (don't merge yet?) #222

Conversation

mcclure commented Feb 13, 2020

mcclure Feb 13, 2020

Choose a reason for hiding this comment

bjornbytes Feb 14, 2020

Choose a reason for hiding this comment

mcclure Feb 14, 2020

Choose a reason for hiding this comment

mcclure Feb 13, 2020

Choose a reason for hiding this comment

mcclure Feb 13, 2020

Choose a reason for hiding this comment

bjornbytes Jul 10, 2020

Choose a reason for hiding this comment

bjornbytes commented Feb 14, 2020 • edited

mcclure commented Feb 14, 2020

bjornbytes commented Feb 14, 2020 • edited

bjornbytes commented Feb 14, 2020

mcclure commented Feb 14, 2020

bjornbytes commented Feb 15, 2020 • edited

mcclure commented Apr 15, 2020

bjornbytes commented Jul 10, 2020

mcclure commented Jul 10, 2020

bjornbytes commented Aug 16, 2020

bjornbytes commented Jul 19, 2021

bjornbytes commented Feb 14, 2020 •

edited

bjornbytes commented Feb 14, 2020 •

edited

bjornbytes commented Feb 15, 2020 •

edited