I just pushed a rewrite of the Mac OS X joystick code…
https://hg.libsdl.org/SDL/rev/1c185bacf915
…this dumps the original way of managing HID devices for a new API
that was introduced in Mac OS X 10.5.
There are various technical reasons for this, but most notably, it lets
the PS4 controller work over Bluetooth out of the box, which is why I’m
trying to cram this in for 2.0.2.
Please test this with your Mac games and joysticks, and report back. If
there are reasonable bugs, I’ll fix them before 2.0.2, but if it turns
out to be a complete disaster or something, I’ll revert the change until
after 2.0.2 ships.
line 1766, is there a reason to ignore wheel devices? Maybe it would make
sense to add:
pDevice->usage != kHIDUsage_GD_Wheel
In the future, are there any plans to add an HID joystick driver to
windows to replace the deprecated DirectInput/WinMM APIs?
2014-02-22 8:46 GMT+01:00 Ryan C. Gordon :>
I just pushed a rewrite of the Mac OS X joystick code…
https://hg.libsdl.org/SDL/rev/1c185bacf915
…this dumps the original way of managing HID devices for a new API that
was introduced in Mac OS X 10.5.
There are various technical reasons for this, but most notably, it lets
the PS4 controller work over Bluetooth out of the box, which is why I’m
trying to cram this in for 2.0.2.
Please test this with your Mac games and joysticks, and report back. If
there are reasonable bugs, I’ll fix them before 2.0.2, but if it turns out
to be a complete disaster or something, I’ll revert the change until after
2.0.2 ships.
Does this change the joystick guids in the game controller database?On Fri, Feb 21, 2014 at 11:46 PM, Ryan C. Gordon wrote:
I just pushed a rewrite of the Mac OS X joystick code…
https://hg.libsdl.org/SDL/rev/1c185bacf915
…this dumps the original way of managing HID devices for a new API that
was introduced in Mac OS X 10.5.
There are various technical reasons for this, but most notably, it lets
the PS4 controller work over Bluetooth out of the box, which is why I’m
trying to cram this in for 2.0.2.
Please test this with your Mac games and joysticks, and report back. If
there are reasonable bugs, I’ll fix them before 2.0.2, but if it turns out
to be a complete disaster or something, I’ll revert the change until after
2.0.2 ships.
–ryan.> On Feb 22, 2014, at 12:36 PM, Sam Lantinga wrote:
Does this change the joystick guids in the game controller database?
On Fri, Feb 21, 2014 at 11:46 PM, Ryan C. Gordon <@icculus> wrote:
I just pushed a rewrite of the Mac OS X joystick code…
https://hg.libsdl.org/SDL/rev/1c185bacf915
…this dumps the original way of managing HID devices for a new API that was introduced in Mac OS X 10.5.
There are various technical reasons for this, but most notably, it lets the PS4 controller work over Bluetooth out of the box, which is why I’m trying to cram this in for 2.0.2.
Please test this with your Mac games and joysticks, and report back. If there are reasonable bugs, I’ll fix them before 2.0.2, but if it turns out to be a complete disaster or something, I’ll revert the change until after 2.0.2 ships.
On page 27 is a list of possible usage values for the Generic Desktop
usage page.
The bold text items are collections (devices). The non-bold ones are
elements on those devices. So we’ll never get a kHIDUsage_GD_Wheel at
this point in the program, and we should reject it as bogus if we ever do.
We do accept elements on those devices that are kHIDUsage_GD_Wheel, in
AddHIDElement(), and treat them as axes.
I could be wrong about the spec’s intentions, though. I’m not a careful
reader.
Ah indeed, you are totally right. I was working with Apple’s HID
documentation, which is rather confusing - the usb.org documentation is
much clearer, thanks!
2014-02-23 2:13 GMT+01:00 Ryan C. Gordon :>
line 1766, is there a reason to ignore wheel devices? Maybe it would
make sense to add:
pDevice->usage != kHIDUsage_GD_Wheel
(My reading of the spec says that) HID doesn’t specify wheels as devices,
just as elements on devices.
On page 27 is a list of possible usage values for the Generic Desktop
usage page.
The bold text items are collections (devices). The non-bold ones are
elements on those devices. So we’ll never get a kHIDUsage_GD_Wheel at this
point in the program, and we should reject it as bogus if we ever do.
We do accept elements on those devices that are kHIDUsage_GD_Wheel, in
AddHIDElement(), and treat them as axes.
I could be wrong about the spec’s intentions, though. I’m not a careful
reader.
We noticed a crash bug on latest SDL2 from Mercurial (changeset 8245:2c63c27c4d1d)
on OSX 10.8.5. We get EXC_BAD_ACCESS at SDL_syshaptic.c line 682 when quitting.
See stack trace below.
This seems to have been caused by Edward’s hotplug work. List item next pointer
is not initialized and points to garbage. On quit we try to free it which fails.
To fix it add
item->next = NULL;
to SDL_syshaptic.c line 252.
We noticed a crash bug on latest SDL2 from Mercurial (changeset
8245:2c63c27c4d1d)
on OSX 10.8.5. We get EXC_BAD_ACCESS at SDL_syshaptic.c line 682 when
quitting.
See stack trace below.
This seems to have been caused by Edward’s hotplug work. List item next
pointer
is not initialized and points to garbage. On quit we try to free it which
fails.
To fix it add
item->next = NULL;
to SDL_syshaptic.c line 252.
