RGBCommander issue with Led-Wiz+GP as second device?

[gray_space]

I've got a cabinet with two Led-Wiz controllers: a Led-Wiz32 (set as device #1) and a Led-Wiz+GP (set as device #2). This is running on a 64-bit Linux system (not a RPi). I've actually reproduced the problem using several systems running Ubuntu 18.04,  in addition to the mini-ITX board running Ubuntu 20.04  I have in the cabinet now.

So far, I have been able to get the two Led-Wiz controllers configured and have RGBCommander put on a light show when Attract Mode starts. Yay! Lights from both controllers are flashed, so they are both appears to be working.

The problem is, whenever RGBCommander  does anything with the LEDs on the Led-Wiz+GP, the "GP" part of the controller boards (i.e. the gamepad) disappears from the system. This is a problem, as all my admin buttons are hooked up as buttons on this controller.

Here's a demo from the command line using rgbcmdcon:

Code: [Select]

$ ls /dev/input/js*
/dev/input/js0  /dev/input/js1
$ rgbcmdcon
 _____ _____ _____                               _         
| __  |   __| __  |___ ___ _____ _____ ___ ___ _| |___ ___
|    -|  |  | __ -|  _| . |     |     | .'|   | . | -_|  _|
|__|__|_____|_____|___|___|_|_|_|_|_|_|__,|_|_|___|___|_| 
RGBcommanderConsole 0.1.0.1 linux
a *nix arcade cabinet led and joystick driver - GUI dev tool
Copyright 2015-2017 Gijsbrecht De Waegeneer
compilation date Dec 25 2017 17:33:45

connected to localhost:2724 RGBcommander linux build 0.4.0.5
set,button,P1_COIN,Red
<data bool="true"/>
^C
$ ls /dev/input/js*
/dev/input/js0

The P1_COIN button is attached to the Led-Wiz/GP controller. Note that after exiting rgbcmdcon, there is only one js device in /dev/inputs. I don't see anything weird in the Linux logs. In fact, I see nothing in the logs around the time I run the commands on the console... not even something acknowledging that one of the joystick devices just disappeared from the system. I've looked at dmesg, kern.log, and syslog. Nothing seems to notice this.

The rgbcommnder log also doesn't see all that odd...

Code: [Select]

11/05/20 12:30:55 [WARNING] [startListening] selectserver: bind failed, error: 98
11/05/20 12:33:01 [INFO] [startListening] selectserver: new connection from 127.0.0.1, socket 13
11/05/20 12:33:31 [INFO] [startListening] eot detected on socket - clearing socket buffer 13
11/05/20 12:33:31 [INFO] [startListening] processing command  set,button,P1_COIN,Red
11/05/20 12:33:31 [INFO] [processCmd] #args is 4
11/05/20 12:33:31 [INFO] [processCmd] set
11/05/20 12:33:31 [INFO] [processCmd] button
11/05/20 12:33:31 [INFO] [processCmd] P1_COIN
11/05/20 12:33:31 [INFO] [processCmd] Red
11/05/20 12:33:31 [INFO] [write] board initialisation -> SUCCESS
11/05/20 12:33:35 [INFO] [startListening] selectserver: socket 13 disconnected

Any ideas on what's wrong?

[ZoOl007]

Hi,

you're out of luck I guess. It has never been tested on a Led-Wiz/GP and it is not on the hw compatibility list.
I do not own such a board. The daemon apparently recognizes it otherwise you won't have leds lit so they must be similar... too similar actually because it's not a Led-Wiz but a Led-Wiz/GP and one should assume they would both have a different identifier... not so it seems.
The daemon happily writes data to all pins, also to the ones where the joystick is attached and that seems to break something.
I can't tell you more without buying such a board and invest time to investigate and implement support for it.

There's no use in trying. It'll never work. You could consider purchasing a PacLED64 and move your leds to it and keep the joystick on the gp. Or perhaps a 2nd Led-Wiz.
I developed it mainly on Ultimarc boards and Mahuti did the testing on a Led-Wiz. Multi-board support should logically work fine as the hardware is nicely abstracted away but it's never been tested by myself.

kind regards.

[gray_space]

Thanks for the reply. That's a shame. Unfortunately, I didn't do enough research when choosing hardware for my cabinet. I saw that there was Linux support for the Led-Wiz, and assumed the whole product line was supported.

I'll likely just try moving the inputs off of the Led-Wiz+GP to a cheap USB input controller.

[mahuti]

I've recently been working on this problem. The solution has to do with  the need within LIBUSB to specifically claim an interface after detaching the kernel driver, then releasing the claim and then attaching the kernel driver again after control messages have been sent.

I have been trying to sort out this same problem for the GpWiz49 as well as the LedWiz+Gp on and off for the last few years. I  the last few days I finally found a simple working solution of a few lines of code. While I havent tested the LedWiz+Gp with my solution, I have tested and corrected the same problem on the GpWiz49. I have some test code for the LW+GP laying around and a working LedWiz+GP, so I'll be making tests for this soon. 

Whether or not that code will work with how RGBCommander works or whether ZoOl007 will have time to implement it... that's another story. At the very least l will likely end up with some kind of simple utility to pass light commands to the LW+GP and still have a working joystick. That utility will be incredibly basic, but probably good enough to get some use out of that controller.

[mahuti]

I set up a test, and it looks like I can drive the lights, while leaving access to the joystick in tact.

This is a quick test I built based on RGBCommander's code

https://github.com/mahuti/setledwiz

once installed, you can run the test like so:

setledwiz 1

And it'll light everything up to a purple-ish color without killing the joystick. The thing that makes it possible is the kernel attach thing I mentioned. I'm not sure how RGBCommander's built, so it may not be able to release the joystick. I don't know. If it can, the method to do so is pretty simple. In the code, this is what does it.

Claim 1 specific interface, otherwise it grabs both the control and the data interface.

Code: [Select]

rc = libusb_detach_kernel_driver(devicehandle, J_INTERFACE);
            libusb_claim_interface(devicehandle,J_INTERFACE);

Release and reattach.

Code: [Select]

libusb_release_interface(devicehandle, J_INTERFACE);
   rc = libusb_attach_kernel_driver(devicehandle, J_INTERFACE);
   libusb_free_device_list(devices, 1);
   cleanup(context, devicehandle);
   return EXIT_SUCCESS;