Using some usb headsets causes RunGame to wait 10 seconds before launch

[sedyh]

Ebitengine Version

2.8+ (6452cbc)

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

go version go1.23.1 linux/amd64

What steps will reproduce the problem?

Buy one of DEXP Storm Pro or Redragon Inferno Pro usb headset:

Connect it to usb on Windows 10 Pro 22H2 19045.4780.

Run the example:

package main

import (
    "github.com/hajimehoshi/ebiten/v2"
    "log"
)

type Game struct {}

func NewGame() *Game {
    return &Game{}
}

func (g *Game) Update() error {
    log.Println("update")
    return ebiten.Termination
}

func (g *Game) Draw(screen *ebiten.Image) {}

func (g *Game) Layout(w, h int) (int, int) {
    return w, h
}

func main() {
    log.Println("starting")
    ebiten.SetWindowResizingMode(ebiten.WindowResizingModeEnabled)
    ebiten.SetWindowSize(1000, 1000)
    ebiten.SetVsyncEnabled(true)

    log.Println("running")
    op := &ebiten.RunGameOptions{GraphicsLibrary: ebiten.GraphicsLibraryOpenGL}
    if err := ebiten.RunGameWithOptions(NewGame(), op); err != nil {
        log.Fatal(err)
    }
}

What is the expected result?

2024/09/03 23:08:53 starting
2024/09/03 23:08:53 running
2024/09/03 23:08:54 update

2024-09-03_22-50-12.mp4

What happens instead?

2024/09/03 23:08:53 starting
2024/09/03 23:08:53 running
2024/09/03 23:09:03 update

0, 0% 99.22%, 9.72s, 75.70%, github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*_IDirectInput8W).EnumDevices

(pprof) top10
Showing nodes accounting for 12.74s, 99.22% of 12.84s total
Dropped 67 nodes (cum <= 0.06s)
Showing top 10 nodes out of 52
      flat  flat%   sum%        cum   cum%
    12.73s 99.14% 99.14%     12.74s 99.22%  runtime.cgocall
     0.01s 0.078% 99.22%      2.87s 22.35%  golang.org/x/sys/windows.(*Proc).Call
         0     0% 99.22%     10.11s 78.74%  github.com/hajimehoshi/ebiten/v2.RunGameWithOptions
         0     0% 99.22%      9.72s 75.70%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*_IDirectInput8W).EnumDevices
         0     0% 99.22%      9.83s 76.56%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*gamepads).update
         0     0% 99.22%      9.72s 75.70%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*nativeGamepadsDesktop).detectConnection
         0     0% 99.22%      0.11s  0.86%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*nativeGamepadsDesktop).directInput8Create
         0     0% 99.22%      9.83s 76.56%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*nativeGamepadsDesktop).init
         0     0% 99.22%      0.12s  0.93%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.(*nativeGamepadsDesktop).wndProc
         0     0% 99.22%      9.83s 76.56%  github.com/hajimehoshi/ebiten/v2/internal/gamepad.Update (inline)
(pprof)

profile-inside.zip

Related:
https://stackoverflow.com/questions/10967795/directinput8-enumdevices-sometimes-painfully-slow

*The owner said that it does not happens in any other game / game engine.

Anything else you feel useful to add?

.

[hajimehoshi]

Maybe https://stackoverflow.com/questions/10967795/directinput8-enumdevices-sometimes-painfully-slow

EDIT: Oh yes, you have already noted that

[sedyh]

Oh yes, you have already noted that

Yeah. It's very strange that this doesn't happen on other directx based games.

[hajimehoshi]

DirectInput 8 might be pretty outdated so I would replace it with a new one.

[sedyh]

I'll be glad to retest this after the update.

[hajimehoshi]

This can happen with other engines

• Godot slow to open, slow to edit, slow to launch simple game [Windows, caused by specific USB peripherals] godotengine/godot#20566
• pygame.joystick.init() takes 20+ seconds to initialize, with active USB DAC pygame/pygame#2173

[sedyh]

Looks like a possible fix?
godotengine/godot#20566 (comment)

What about updating directinput?

[hajimehoshi]

What about updating directinput?

You mean injecting some code for DirectInput (https://raw.githubusercontent.com/funkkiy/godot/8cc66b6f940ec77df624cf7f0124f6bfaf75dafb/platform/windows/hid_proxy.cpp) rather than updating DirectInput?

[hajimehoshi]

This overwrites HidD_GetProductString and I don't know it is possible to do this. Would we need something like LD_PRELOAD?

EDIT: Even if it is possible, Windows antivirtus software tends to warn or ban software using tricky hacks for DLL https://news.ycombinator.com/item?id=26984206

[sedyh]

You mean injecting some code

That was the first question.

Rather than updating DirectInput

And that was the second separate question about how difficult/long it will be to make this update.

[sedyh]

I heard that SDL had a blacklist for this kind of devices but this doesn't seem like a solution, except for cases where this device is simply connected nearby and not used (and in our case its intended to be used).

[hajimehoshi]

IIUC, adding a device to a blocklist doesn't work since this would not prevent DirectInput from enumerating connected devices.