search

darthcloud / BlueRetro

Multiplayer Bluetooth controllers adapter for retro video game consoles
https://blueretro.io
Apache License 2.0
1.23k stars 104 forks source link

Controller Assigned to Player 2 #823

Closed The-Randalorian closed 6 months ago

The-Randalorian commented 8 months ago

BlueRetro firmware version

1.8.2

BlueRetro firmware specification

HW2

BlueRetro firmware variant

System specific

BlueRetro hardware type

Internal install modkit

Manufacturer

Laserbear

System used

Nintendo GameCube

Bluetooth controller brand & name

Xbox Core Controller

What is problem? (only list ONE problem per report)

The device was paired to the console and assigned to player 2 instead of player 1, despite player 1 being empty.

What did you expect to happen?

I expected the controller to be assigned to port 1.

I think this is the same issue as mentioned on the forum here. The solution suggested there was there was another device in the house that was trying to autoconnect to blueretro. The "solution" was to turn off the other device. While this is a decent quick fix for some, there are a lot of times when it doesn't work:

  1. In apartments or dorms (my situation), tracking down devices in other rooms can be extremely difficult if not impossible.
  2. Some people may want to leave the offending device on; if it's a light bulb or light strip (as suggested in the discussion) that device may actively be providing light while the user is gaming.

I think both of these cases (especially the apartment/dorm one) happen frequently enough that the "just turn off the other device" solution isn't good long term. I think some solution (or solutions) to prevent these devices from connecting when they shouldn't is super important. Some ideas:

  1. Don't assign devices to a port until it's known that they're a controller. Even if a misbehaving device connects, if it isn't assigned to a port, controllers will still work as expected.
  2. Blacklist misbehaving devices. Blocking misbehaving devices through the web UI would allow users to block neighbor's devices or devices they wish to leave on.
  3. Whitelist specific devices. A whitelist mode that blocks any non-approved device would be useful in places where there are many misbehaving devices or misbehaving devices come and go frequently (common in dorms.)

Each of these have they're own advantages and disadvantages, and I don't know how hard they will be to implement.

Attach files like logs or Bluetooth traces here

Not sure where to get any logs, but I don't think they're necessary as this is a known issue (I just couldn't find any active issues on it on GitHub). If you need logs, just tell me how to get them.

The-Randalorian commented 8 months ago

I used 1.8.2 instead of the latest (1.9) as other devices connecting kept connecting to my BlueRetro while I was trying to update the firmware. This is also an issue, but the existing solution is still viable here as updating the firmware isn't a super common task. If I really need to update the firmware, I can take my console out of my dorm and update it.

darthcloud commented 8 months ago

Since your controller is paired you could try to set inquiry mode to manual: https://github.com/darthcloud/BlueRetro/wiki/BlueRetro-BLE-Web-Config-User-Manual#22---global-config

I realize this might be hard to do with the other device jumping on blueretro. Maybe try to do the config at another location or press the boot button to kick the device and then try to connect quickly to web.

The-Randalorian commented 8 months ago

I'll give that a shot and come back with how well it works out. If everything is still working after a few rounds of gaming, I'll close the issue.

From my quick testing, it does seem to improve things, however I noticed if the power cycled the adapter would always go into inquiry/pairing mode (shutdown via controller was unaffected, unless the power was cycled while the system was off.)

This doesn't feel like intended behavior, so I'll test further and probably make another issue if I can nail down exactly when it happens.

darthcloud commented 8 months ago

Don't close issue, that's just a workaround.

I need to had a check for BLE device type and then make a deny list.

The-Randalorian commented 8 months ago

The issue is still present anyway, even with the adapter set to manual.

darthcloud commented 8 months ago

I had forgot but there is already some filter in place for BLE devices.

BlueRetro will connect to a BLE device if one of the 3 is true:

  1. The device is explicitly sending us it's beacon (Which mean we were previously pair to it)
  2. It's a HID device
  3. It's a device who got some HID attribute.

I made a build which remove 3 and filter a bit more point 2. Now it more specifically check if it's a HID device that is a Keyboard, Mouse, Joystick or Gamepad. v1.9.1-beta-23-g846dcff_hw2_gamecube.zip

Update then after connect to adapter over web again and validate FW version display at the top is "v1.9.1-beta-23" Then switch back inquiry mode back to auto.

Let me know if that fix the problem.

The-Randalorian commented 7 months ago

I uploaded that to my blueretro and confirmed it said "v1.9.1-beta-23". I'll test it for a few days and come back here.

The-Randalorian commented 7 months ago

@darthcloud do you want me test with inquiry mode in manual or auto?

darthcloud commented 7 months ago

with auto

The-Randalorian commented 7 months ago

I have been unable to replicate this issue once over the past week, despite testing at multiple different times each day. Either was really lucky with what my neighbors were doing, or the test build you sent fixed the issue. I'm leaning towards the latter.

I don't know if you have merged whatever code changes you wrote to fix this, so I will not close this issue myself.

darthcloud commented 6 months ago

Fix is now in v1.9.1