Isolate joystick.init() submodule so it is only initialised on usage of any function/object - reduce USB related hangs

[GalacticEmperor1]

Issue №1573 opened by Lobsternator at 2020-02-05 17:45:19

Import pygame

pygame.init()

Whenever I run this script it stalls indefinitely when it gets to the init function.

Now the thing is; it works just fine if I have any other monitor connected other than this specific one which I recently got.

So obviously it has something to do with the monitor.

I've tried using different versions of pygame and it works fine if I use pygame 1.9.6 but every 2.0.0.devX version just stalls.

I’m using python 3.7.3 and running a Windows machine, the monitor is a Samsung tv; model t28e310ex

Related Docs: https://www.pygame.org/docs/ref/pygame.html# pygame.init

---

Comments

# # bitcraft commented at 2020-02-06 01:32:06

what is the resolution of the tv?

---

# # Lobsternator commented at 2020-02-12 19:58:53

The resolution is 1366 x 768.

---

# # robertpfeiffer commented at 2020-02-17 07:46:26

How many monitors are we talking about? Just one or is this a multi-monitor setup?

---

# # illume commented at 2020-02-17 18:38:59

Note, it’s possible that it’s related to audio if it’s using hdmi.

Can you please try just using pygame.display.init instead of pygame.init?
This will avoid initializing the audio.

On Monday, February 17, 2020, robertpfeiffer [email protected]
wrote:

How many monitors are we talking about? Just one or is this a
multi-monitor setup?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<pygame/pygame#1573 issuecomment-586858227>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACKRN5QE5YC757MDAUDKLRDI6FFANCNFSM4KQPJZPA
.

---

# # MyreMylar commented at 2020-05-15 19:42:26

@Lobsternator Did you ever try running your code with just pygame.display.init() instead of pygame.init() ?

Obviously it's hard for us to investigate this without your specific monitor.

---

# # Lobsternator commented at 2020-10-12 08:02:01

Alright, yea I understand that, and I'm sorry, I've been having some real-life troubles, especially now with what's happening in the world, anyway, for @robertpfeiffer yes it's a multi-monitor setup with two monitors and the problem arises no matter which display I set to be the main one in display.set_mode() plus reconnecting the extra monitor and then starting the program does not make a difference, neither does restarting the computer.

One "problem" I'm having while testing is that sometimes the initialization does not freeze at all and runs just fine, so it's a bit hard to test due to the unusual inconsistency. But after a bit of tinkering, I can conclude that yes, it works perfectly fine when using pygame.display.init() instead of pygame.init(). I also discovered that it doesn't stall indefinitely, it only stalls for an unreasonably long period of time, and what's strange is that it's the exact same period of time every single time, I ran the program 5 times with pauses in between to mitigate temporal anomalies and kept track of time, and each time it stalled for roughly 40.125 seconds, the longest margin of error only ever being .006 seconds. Every time.

---

# # MyreMylar commented at 2020-10-12 09:42:29

I guess the next test to confirm @illume's suspicion is to try adding:

pygame.mixer.init()

Right after pygame.display.init() and see if it makes the intermittent freeze come back.

Just to confirm - the 'problem' monitor is connected via HDMI? And there are no other changes, nothing extra plugged in via USB or anything?

---

# # Lobsternator commented at 2020-10-12 23:10:09

Alright so I added pygame.mixer.init() and there was no difference, I am however using pygame.mixer.pre_init() originally, could that cause some problems? My parameters are as follows: pygame.mixer.pre_init(frequency=44100, size=-16, channels=2, buffersize=512, allowedchanges=pygame.AUDIO_ALLOW_ANY_CHANGE) Also I checked and there was no difference when I removed allowedchanges=pygame.AUDIO_ALLOW_ANY_CHANGE. I am also doing the initialization in a file that's located in the AppData\Roaming\Python\Python37\site-packages folder, is that something to look at?

And to answer @MyreMylar, kinda, the monitor is connected via an HDMI cable going into an HDIM to Mini DisplayPort converter and then going into the pc.

---

# # MyreMylar commented at 2020-10-13 07:18:23

So to summarize:

When you connect a second monitor over an HDMI cable via an adaptor to a DisplayPort port, and you use pygame.mixer.pre_init() followed by pygame.mixer.init() you get an intermittent freeze on startup of almost exactly 40 seconds? Is that correct? Or does it still only happen with pygame.init()?

I ask because I've seen another logged issue about the joystick module initialisation (also started by pygame.init()) being slow to start. Though in that case they said it was related to a USB DAC being plugged in.

---

# # Lobsternator commented at 2020-10-13 18:32:46

Mm... no using pygame.mixer.pre_init() then followed by pygame.mixer.init() doesn't stall, it's only when I use pygame.init() while being plugged in via the DisplayPort port that it stalls, same as with that other issue you referenced. For almost exactly 40 seconds, yes.

Also, there appears to be no difference if I unplug the monitor and then run the program, it still stalls, however, if I wait for long enough with the monitor unplugged and then run the program, it doesn't stall. Specifically how long I have to wait however is inconclusive.

The program also sometimes stops stalling even with the monitor plugged in as well, however, it's usually very random and quickly goes back to stalling on startup again. However, once the program stops stalling with the monitor unplugged I've never had it go back to stalling ever, not until I've reconnected the monitor again.

It's definitely quite a bit of a mess.

---

# # MyreMylar commented at 2020-10-13 18:38:22

Ok, I wonder if it is the Joystick module then?

You could add one after the others like so:

pygame.display.init()
pygame.mixer.pre_init(frequency=44100, size=-16, channels=2, buffersize=512, 
                      allowedchanges=pygame.AUDIO_ALLOW_ANY_CHANGE)
pygame.mixer.init()
pygame.joystick.init()

And see if that brings back the freeze. Debugging weird shit like this is very time consuming :)

---

# # Lobsternator commented at 2020-10-30 07:46:25

Alright, finally after a lot of fiddling around I can confirm that yes when I add pygame.joystick.init() it stalls, and when I remove it, it runs fine. It also doesn't seem to change if I add or remove any other initialization. But it still seems weird because I've never had this issue before, it only started appearing after I started using this new monitor. I have no idea how monitors and joysticks are supposed to be connected in any way.

Puzzling.

---

# # Zireael07 commented at 2020-10-30 07:48:02

@Lobsternator: Some monitors double as a USB hub, pygame is not the only engine that has such an issue (Godot also has something extremely similar, with some USB devices making it start very slowly)

---

# # Lobsternator commented at 2020-10-30 07:54:06

@Zireael07 Huh okay, interesting. Is it well know what causes it?

---

# # MyreMylar commented at 2020-10-30 08:52:37

It seems very likely this is the same USB/joystick issue linked above. You may be able to solve it by setting an environment variable if you can figure out the manufacturers USB VID & PID of your monitor hub. Usually these can be found in hardware settings
e.g.

The you could try this code before calling joystick.init():

import os
os.environ["SDL_GAMECONTROLLER_IGNORE_DEVICES"] =  "VID_HERE/PID_HERE"  #  Should look like this: "0x262A/0x9023"
pygame.init()

Not 100% that it works but at least some of these hints seem to be processed as environment variables.

---

# # zuzzy commented at 2021-03-08 11:59:54

On pygame 2.0.1 on Mac Air M1 Big Sur Python 3.9.1 the code below would freeze within the pygame.init() call on about 2 in 3 times. I noticed this in porting some existing code over to Mac Air Big Sur M1 platform after I had been using it without problems on W10.

Fixed by changing pygame.init() to pygame.display.init(), reasons not understood, but it seems related to the above reports.

import pygame
from pygame.locals import *
from pygame import Surface
from pygame import surfarray
from pygame import display
from pygame import quit
from pygame import time
from pygame import event
from pygame import freetype
from pygame import draw
from pygame import transform
print("Initialising pygame")
pygame.init()
print("Initialised pygame")

---

# # MyreMylar commented at 2022-07-16 21:15:44

Updated snippet of code above to remove _HINT_ as that seems to be how the pipeline from pygame to SDL works:

import os
os.environ["SDL_GAMECONTROLLER_IGNORE_DEVICES"] =  "VID_HERE/PID_HERE"  #  Should look like this: "0x262A/0x9023"
pygame.init()

I don't think there is much we can do about this from the pygame end. Ultimately some slightly wonky USB hub/DAC devices were made that don't respond in a timely manner to operating systems asking what they are.

---

# # Starbuck5 commented at 2022-07-16 21:18:15

One thing I've thought about in the past is isolating the joystick init. So instead of pygame.init() calling it, it would automatically be called if you tried to do anything in the joystick module.

This isn't like a great solution, but it would minimize the impact of this issue quite a lot.

---

# # MyreMylar commented at 2022-07-16 21:27:29

One thing I've thought about in the past is isolating the joystick init. So instead of pygame.init() calling it, it would automatically be called if you tried to do anything in the joystick module.

This isn't like a great solution, but it would minimize the impact of this issue quite a lot.

yeah it might help. SDL is blacklisting individual VID/PIDs in some commits and also added this:

libsdl-org/SDL@5ed71f3

...which stops random DACs from being enumerated. So hopefully the issue is much reduced in recent SDL releases

---

# # Starbuck5 commented at 2022-12-04 02:12:33

Encountered someone running into this on the pygame discord. Sent them a custom build of pygame with SDL 2.26.1 and it didn't fix the issue for them.

They were on Windows 10, desktop PC, several monitors (none of which had USB hubs). No weird peripherals besides headphone charger, issue persisted when that was unplugged.

Told them the workaround with individually initializing modules, that got them past the issue. Shame this isn't fully fixed though.

[MyreMylar]

Might it be worth lazy loading the joystick module as we are planning with the numpy modules to avoid this problem - unless you specifically want to use a joystick/controller and need to dive into the vagaries of USB?

See: #3232