add dbar4gun support

[lowlevel-1989]

dbar4gun is a Linux userspace driver for the wiimote with DolphinBar support, specifically designed to be small and function as 4 light guns.

Feature support

• Bluetooth
• Only DolphinBar in mode 4
• N Mayflash Dolphinbar (recommended at the moment)
• 4 wiimote x Dolphinbar (slow with a single bar)
• wiimote with individual buttons
• multiplayer
• nunchuck
• calibration
• Standard configuration for Wii sensor
• dbar4gun supports maximum resolution and sensitivity without causing cursor jumps
• wiimote led -> index mouse (bin number)
• auto key
• Smoothed cursor
• works on linux
• works on retropie
• works on raspbian

repo: https://github.com/lowlevel-1989/dbar4gun

[retropieuser]

This is a great addition as dolphin bar doesn't support two wiimotes in modes 1 & 2, and modes 3 & 4 don't function on retroach or other emulators (except dolphin) with IR functionality

[cmitu]

@lowlevel-1989 thank you for the PR.

Is the driver you're trying to add an alternative to other gamepad/wiimote drivers like cwiid/xwiimote ? I can see it has both lightgun and gamepad capabilities. I don't have an objection of adding another 3rd party driver, but since the driver is very new, does it had any testing done besides what you've done yourself ?

I have installed the driver on a recent RetroPie with a recent RaspiOS and have a few observations:

• installation needs also the python3-virtualenv package installed.
• the installation fails on current RetroPie release for Pi (RaspiOS buster) because numpy has no installation candidate for armh7l and python 3.7. That may be ok, but we'll need to handle with the package flags so installation is not enabled unless RaspiOS Bullseye/Bookworm is detected. Which version of RetroPie/Raspberry Pi did you use to test ?
• the enable/disable functions only operate on the current state. Enabling the driver is not persistent after a reboot. Is the user supposed to run the enable function each time they want to activate the driver ? For other drivers we have (xboxdrv or sc-controller), enable/disable are persisting the configuration across reboots by running the driver's program on boot/disabling the automatic starts. I think you should do the same (see how it's done with the steamcontroller or xboxdrv packages).

As an observation, the driver is not so lightweight as far as Memory is concerned. It consumes about 200+Mb of RES memory (on aarch64, couldn't measure on my Pi3 since it wasn't installable), which it might not be an issue for 1Gb systems, but we should disable it for Pi0/ Pi1 where only 512 Mb is available (a part of it is already reserved for VRAM).

[lowlevel-1989]

@lowlevel-1989 thank you for the PR.

Is the driver you're trying to add an alternative to other gamepad/wiimote drivers like cwiid/xwiimote ? I can see it has both lightgun and gamepad capabilities. I don't have an objection of adding another 3rd party driver, but since the driver is very new, does it had any testing done besides what you've done yourself ?

I have installed the driver on a recent RetroPie with a recent RaspiOS and have a few observations:

• installation needs also the python3-virtualenv package installed.
• the installation fails on current RetroPie release for Pi (RaspiOS buster) because numpy has no installation candidate for armh7l and python 3.7. That may be ok, but we'll need to handle with the package flags so installation is not enabled unless RaspiOS Bullseye/Bookworm is detected. Which version of RetroPie/Raspberry Pi did you use to test ?
• the enable/disable functions only operate on the current state. Enabling the driver is not persistent after a reboot. Is the user supposed to run the enable function each time they want to activate the driver ? For other drivers we have (xboxdrv or sc-controller), enable/disable are persisting the configuration across reboots by running the driver's program on boot/disabling the automatic starts. I think you should do the same (see how it's done with the steamcontroller or xboxdrv packages).

As an observation, the driver is not so lightweight as far as Memory is concerned. It consumes about 200+Mb of RES memory (on aarch64, couldn't measure on my Pi3 since it wasn't installable), which it might not be an issue for 1Gb systems, but we should disable it for Pi0/ Pi1 where only 512 Mb is available (a part of it is already reserved for VRAM).

Thank you for your feedback. The latest version I uploaded no longer requires numpy or cv and only uses native Python to ensure compatibility with older versions. Regarding the RAM usage of the current version, I will review it for optimization. However, this version still requires evdev and pyudev. It is focused solely on functioning as a light gun.

[cmitu]

[..]Thank you for your feedback. The latest version I uploaded no longer requires numpy or cv and only uses native Python to ensure compatibility with older versions. Regarding the RAM usage of the current version, I will review it for optimization. However, this version still requires evdev and pyudev. It is focused solely on functioning as a light gun.

pyudev and evdev are ok and I think the latter is already installed globally (via apt) by RetroPie itself, while numpy and opencv are rather 'heavy' dependencies.

I'll re-test again installation on Pi3/Buster and Pi4/Pi5 with current RaspiOS. Are you testing/using a Raspberry Pi or just using a PC/x86 installation ?

[lowlevel-1989]

[..]Thank you for your feedback. The latest version I uploaded no longer requires numpy or cv and only uses native Python to ensure compatibility with older versions. Regarding the RAM usage of the current version, I will review it for optimization. However, this version still requires evdev and pyudev. It is focused solely on functioning as a light gun.

pyudev and evdev are ok and I think the latter is already installed globally (via apt) by RetroPie itself, while numpy and opencv are rather 'heavy' dependencies.

I'll re-test again installation on Pi3/Buster and Pi4/Pi5 with current RaspiOS. Are you testing/using a Raspberry Pi or just using a PC/x86 installation ?

I'm testing on the rpi4, rpi5 and linux x64, if you prefer wait until tomorrow when I publish a version optimized RAM, I will report the consumption and changes here

[lowlevel-1989]

Hi again

New description

dbar4gun is a Linux userspace driver for the wiimote with DolphinBar support, specifically designed to function as 4 light guns.

Memory Consumption of the dbar4gun

Currently, the dbar4gun consumes ~24 MB. For each Wiimote connected via Bluetooth, an additional ~19 MB is consumed, as a dedicated process is generated to manage each Wiimote.

In the case of the DolphinBar, it is detected as four Wiimotes, even if they are not connected, resulting in an additional consumption of ~76 MB.

Summary of Memory Consumption

Item	Memory Consumption
dbar4gun	~24 MB
monitor	~19 MB
Per Wiimote connected via Bluetooth	~19 MB
DolphinBar (detected as 4 Wiimotes)	~76 MB

rp_module_flags="!all rpi3 rpi4 rpi5" systemd support: persistent after a reboot

[cmitu]

@lowlevel-1989 thank you for the changes. I've re-installed and the memory usage seems considerably better. I re-built the module on a Pi4 and Pi3. Some notes on the installation:

• python3-virtualenv/ python3-venv should be added as dependency, without it the virtual environment will fail. On RaspiOS bookworm this is fatal, since Debian removed the ability to install via pip local modules.
• [optional] systemd integration works fine, could be made a bit better by:
  • usually a systemctl daemon-reload is advised when a unit file is changed/removed.
  • using systemctl enable --now / systemctl disable --now will automatically start/stop the service in the same command.

Leave the module flags as is for now (i.e. no restrictions), we'll just document the the memory requirements in the docs and the users can choose to install it or not.

[lowlevel-1989]

@lowlevel-1989 thank you for the changes. I've re-installed and the memory usage seems considerably better. I re-built the module on a Pi4 and Pi3. Some notes on the installation:

• python3-virtualenv/ python3-venv should be added as dependency, without it the virtual environment will fail. On RaspiOS bookworm this is fatal, since Debian removed the ability to install via pip local modules.

• [optional] systemd integration works fine, could be made a bit better by:

  • usually a systemctl daemon-reload is advised when a unit file is changed/removed.
  • using systemctl enable --now / systemctl disable --now will automatically start/stop the service in the same command.

Leave the module flags as is for now (i.e. no restrictions), we'll just document the the memory requirements in the docs and the users can choose to install it or not.

Thanks a lot for your comments! I have already made the requested changes

[cmitu]

Looks good. One think about the flags - just remove the line, we only use comments for commenting the code and not for disabling/removing code.

[lowlevel-1989]

Looks good. One think about the flags - just remove the line, we only use comments for commenting the code and not for disabling/removing code.

Deleted, I'll keep that in mind for the future.

[cmitu]

@lowlevel-1989 thanks for the PR, I have squashed the commits into one and merged it.

If you want to get more testers for the driver, you can open a topic in our 'Ideas and Projects' forum category and present your driver. I'll add some details about it in our WiiMotes page and ping you if you have any additions to it.

Thanks again.

[lowlevel-1989]

@lowlevel-1989 thanks for the PR, I have squashed the commits into one and merged it.

If you want to get more testers for the driver, you can open a topic in our 'Ideas and Projects' forum category and present your driver. I'll add some details about it in our WiiMotes page and ping you if you have any additions to it.

Thanks again.

Thanks, I'll go to the forum and think about how to present it.