We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4564 - Not initializing Joystick subsystem causes SDL_PollEvents to block with some hardware devices connected
Summary: Not initializing Joystick subsystem causes SDL_PollEvents to block with some ...
Status: RESOLVED DUPLICATE of bug 4391
Alias: None
Product: SDL
Classification: Unclassified
Component: joystick (show other bugs)
Version: 2.0.9
Hardware: x86_64 Windows 10
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-24 02:17 UTC by Matheus Valadares
Modified: 2019-04-05 17:23 UTC (History)
1 user (show)

See Also:

Attachments
Repro code, not very useful without the hardware (239 bytes, text/plain)
2019-03-24 02:17 UTC, Matheus Valadares 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matheus Valadares 2019-03-24 02:17:52 UTC 
Created attachment 3711 [details]
Repro code, not very useful without the hardware

This is a very weird bug I found that is a bit hard to reproduce. Here are all the details I could collect:

It happens only when the joystick subsystem is *disabled*.

On Windows 10, with a specific USB hardware device plugged in (it's an USB microphone), every exactly 3 seconds, a call to SDL_PollEvents blocks for ~80 ms.

Initializing the joystick subsystem makes the problem go away, not initializing it causes the problem to appear. Other systems being initialized (other than the gamecontroller one which initializes joystick) does not affect anything. Unplugging the device while the program is running makes the problem go away, replugging brings it back.

The blocking code is in the function hid_enumerate (in hidapi\windows\hid.c). Most of the time is spent in SetupDiGetDeviceRegistryProperty, but some non-insignificant amount of time is spent in other functions too (SetupDiGetClassDevsA, CreateFileA and HidD_GetManufacturerString).

The 3 seconds timer seems to come from HIDAPI_UpdateDiscovery.

This is the microphone: https://smile.amazon.com/gp/product/B001R76D42
Comment 1 Daniel Gibson 2019-04-05 17:23:20 UTC 
This sounds like a duplicate of #4391
The bug has been introduced in 2.0.9, the code is fixed in hg and will be part of 2.0.10 (whenever it's released)

*** This bug has been marked as a duplicate of bug 4391 ***