#How to map X360 Keytar in YARG Linux?

1 messages · Page 1 of 1 (latest)

bold cliff
#

I have it synced to my wireless reciever, inputs on the gamepad buttons are working correctly in SteamOS as well as "X360 Wireless Controller" shows as a device I can add to the profile, which I did. But all the keys register as Xbox gamepad inputs for some reason, like Left Stick X etc. Not sure how to go about this from here? No other input devices available are really standing out here

compact glen
#

Hey McGriggles, I had the same problem, so I've since written code for YARG to handle inputs from the Xbox360 Wireless Reciever directly, rather than going through the sub-par linux controller driver.

#

At the moment, we're waiting for a review from @hasty kernel , but I can send you a YARG build directly if you would be happy to test it for us 🙂

bold cliff
compact glen
bold cliff
#

Sweet ill check it out after work!

bold cliff
#

Just got around to testing, works great! At least for the 360 keytar, Im not sure if this is a complete rewrite of how the receiver inputs are handled or if this is aimed at the 360 keytar? Either way it seems functional. Only minor gripe is that this seems to intercept the "home" button call functions for SteamOS navigation. Before the Xbox button would bring up the Steam menu on press while running YARG (Of course the keys inputs werent reading right then). But now with YARG running the Xbox button does nothing, but continues to function as expected once this build was closed or the Yarg session was minimized (or shelved or whatever the proper terminology is? When you dont close the game but you arent in the gamescope sandbox

bold cliff
#

Hope this gets merged soon!

bold cliff
# compact glen At the moment, we're waiting for a review from <@464574979841720340> , but I can...

Hello, me again. I decided to test this build out with more X360 receiver instruments, namely 2 wireless P-Bass's and I noticed the devices are now properly recognized as "rockband" instruments instead of a generic x360 controller, but I was not able to map them at all. Just thought I'd give you a heads up. In nightly I'm able to map them but I'm sure you know they just get read as a generic x360 controller and I don't think YARG can recognize them as unique devices if there's multiple instruments connected to the receiver.

#

Which i think means you can only use one at a time? Correct me if I'm wrong there though

bold cliff
#

Disregard basically all of that. Not sure what happened on the first go around but it all seems to be correct now

compact glen
#

Hey @bold cliff , if you're getting intermittent behaviour, you might be fighting with the 'xpad' kernel module, which will also be trying to claim the reciever and communicate with the instruments 🙂

minor zealot
#

Any chance you could share that build with me as well @compact glen ? I'm trying to get an improved YARG setup for Ubuntu. The microphone delay that I had in Windows is gone in Linux, but just need my instruments working 😄

bold cliff
minor zealot
#

Would very much appreciate that @bold cliff, if you don't mind. DM or posting here works for me 🙂

bold cliff
minor zealot
#

Thank you! Just tried it out, and surprisingly my game crashes when I have my OEM X360 receiver plugged in. If I unplug it, the game will run, and the game won't load at all if I have it plugged in. I can try to figure out where to get an error log if you're interested @compact glen

compact glen
minor zealot
#

Hey Joe, here's what I'm seeing on ~/.config/unity3d/YARC/YARG/Player.log

requesting fullscreen 2560 x 1440 at 60 Hz
Desktop is 3440 x 1440 @ 144 Hz
InitializeOrResetSwapChain 2560x1440 hdr=0 samples=1
FindXInputDeviceLayout:MidiDevice 
[<a href="Assets/Script/Song/SongContainer.cs" line="150">SongContainer.cs:RunRefresh:150</a>] Scan time: 0.9156229s
[<a href="/Users/jw/Projects/YARG/YARG.Core/YARG.Core/Song/Entries/Ini/SongEntry.UnpackedIni.cs" line="76">SongEntry.UnpackedIni.cs:LoadAudio:76</a>] Loaded 6 stems
[HIDrogen] Inspecting new USB Device
[HIDrogen] Found X360Receiver
[HIDrogen] [X360Receiver] init
[HIDrogen LibUSBWrapper.cs(191)] Failed to open USB device: Access denied (insufficient permissions) (0xFFFFFFFD)
Caught fatal signal - signo:11 code:1 errno:0 addr:0x48
#

Access denied makes me wonder if it's a me problem as this is my first time running a portable build. I did chmod +x and launched yarg.x86_64 from the terminal

compact glen
#

Did you add the udev rule?

minor zealot
#

That's not ringing any bells. Would that be in the contribution guide?

compact glen
#

Did McGriggles send you a zip or just the yarg.x86_64? There should be a zipped folder with a readme 🙂

minor zealot
#

It was a zip indeed, and I flew right past that README 😄

Finished adding the 69-hid.rules and about to reboot, but let me review that and I'll report back

#

Think I should keep that 69-hid.rules file around before adding the 99-x360-yarg-driver.rules file?

compact glen
#

There shouldn't be an issue with adding them both to the /etc/dev/rules.d/ folder, you'll need the latter one for sure

#

One other thing you might need to do is prevent the native xpad kernel module from trying to claim your reciever. To do this it's modprobe -r xpad. To revert this (in case you want other applications to use the reciever) do the same command without the -r 🙂

minor zealot
#

done! Honestly the only reason I'm running Ubuntu is for YARG so this receiver isn't being used for anything else

#

Not sure if this makes a difference but I moved the new file to /usr/lib/udev/rules.d/ since that's where all the existing files were

compact glen
#

Great! Any luck? Once connected, the device name should appear with 'XInput' at the start, so 'XInput Rock Band Drumkit' for instance

minor zealot
#

trying shortly

#

dang, it crashed. checking log

#

false alarm, I botched the sudo cp lol. trying again!

# 
guy@desktop:/usr/lib/udev/rules.d$ ls -lah 99*
-rw-r--r-- 1 root root   98 Nov  2  2020 99-libsane1.rules
-rw-r--r-- 1 root root 5.0K Oct 17  2024 99-systemd.rules
-rwx------ 1 root root  236 May 19 15:42 99-x360-yarg-driver.rules
#

Paired the keytar!!! Now just checking the inputs

#

We are truly in business now

#

@compact glen , thank you thank you

#

So this update should show up in YARG nightly once the HIDrogen version gets updated then?

compact glen
compact glen
hasty kernel
#

i should have a new HIDrogen version ready somewhat soon, i've been doing a lot of spec reading and cleanup lol

compact glen
hasty kernel
#

it'd probably be best to just throw a pre-built binary into the Plugins folder

compact glen
#

Thanks for your second round of feedback btw, I will aim to get around to that soon 🙂

hasty kernel
compact glen
#

That's cool, I'm not precious about the code or anything, but it would be great to get it merged when time allows 🙂

hasty kernel
#

it already has been

hasty kernel
compact glen
#

Ah I meant in YARG 🙂

hasty kernel
#

ah alright

#

yeah, that should be ready somewhat soon

#

at this point i just need to take one last look over everything and then test it

compact glen
hasty kernel
#

yeah

compact glen
#

Oh awesome! Well in that case it's in excellent hands, happy to pass the torch over. I'm interested to see what's improved, and if you want to share for testing purposes you certainly can

hasty kernel
#

@compact glen got all of my changes finished if you wanna give them a look over and test on Linux

#

one particular note: i'm not 100% certain the library name for libusb was set correctly, you had it as libusb-1.0.0 but the Windows binary is named libusb-1.0, and when installing it on my WSL Ubuntu install it only provided libusb-0.1 and libusb-1.0

image.png
#

i changed it to libusb-1.0.so.0 for Linux specifically to ensure it picks the right versioned one

#

otherwise i'm pretty sure it should all still work

#

capability info should also be mostly complete now, there's a separate output report to request the rest of the capabilities

#

the only thing i'm not certain on how to determine is the flags, there's no specifications for that

compact glen
#

Unfortunatly I'm not able to build the branch at the moment. There's errors in the console about things missing in the ./XInput directory. It looks like the use of #if UNITY_STANDALONE_WIN in there are hiding things from non-windows builds?

compact glen
compact glen
compact glen
#

I'm now hitting Failed to get configuration descriptor: Entity not found (0xFFFFFFFB) from X360ReceiverL97. The libusb method is libusb_get_active_config_descriptor, which makes me wonder if my receiver might not have an active configuration set by default?

hasty kernel
#

hmm

#

that works fine for me on Windows, perhaps the libusb driver there is automatically setting a configuration

minor zealot
#

Hey folks, I wasn't sure if I should mention it here or open another thread but I'm having some issues with my USB Rock Band drumkit, and the behavior seems to be a bit different on this build. On Stable, it will be recognized, but random things like the red pad don't work. On nightly, the pop-up will appear and then show disconnected. On this X360 wireless build no popup appears. If you have any ideas, I'd appreciate it. I've seen Steam Input mentioned as a workaround, but no inputs seem to be recognized in the game unfortunately.

Running this X360 wireless build, here is the error from Player.log when I plug in the drumkit:

FindXInputDeviceLayout:Joystick 
Could not create a device for 'Harmonix Music Harmonix Rock Band Drumkit (Linux)' (exception: UnityEngine.InputSystem.Layouts.InputControlLayout+LayoutNotFoundException: Cannot find control layout 'Unsupported'
  at UnityEngine.InputSystem.Layouts.InputControlLayout+Cache.FindOrLoadLayout (System.String name, System.Boolean throwIfNotFound) [0x0003b] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.Layouts.InputDeviceBuilder.FindOrLoadLayout (System.String name) [0x00005] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.Layouts.InputDeviceBuilder.InstantiateLayout (UnityEngine.InputSystem.Utilities.InternedString layout, UnityEngine.InputSystem.Utilities.InternedString variants, UnityEngine.InputSystem.Utilities.InternedString name, UnityEngine.InputSystem.InputControl parent) [0x00006] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.Layouts.InputDeviceBuilder.Setup (UnityEngine.InputSystem.Utilities.InternedString layout, UnityEngine.InputSystem.Utilities.InternedString variants, UnityEngine.InputSystem.Layouts.InputDeviceDescription deviceDescription) [0x0000b] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.InputDevice.Build[TDevice] (System.String layoutName, System.String layoutVariants, UnityEngine.InputSystem.Layouts.InputDeviceDescription deviceDescription, System.Boolean noPrecompiledLayouts) [0x00087] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.InputManager.AddDevice (UnityEngine.InputSystem.Utilities.InternedString layout, System.Int32 deviceId, System.String deviceName, UnityEngine.InputSystem.Layouts.InputDeviceDescription deviceDescription, UnityEngine.InputSystem.InputDevice+DeviceFlags deviceFlags, UnityEngine.InputSystem.Utilities.InternedString variants) [0x0001a] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.InputManager.AddDevice (UnityEngine.InputSystem.Layouts.InputDeviceDescription description, System.Boolean throwIfNoLayoutFound, System.String deviceName, System.Int32 deviceId, UnityEngine.InputSystem.InputDevice+DeviceFlags deviceFlags) [0x0004e] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 
  at UnityEngine.InputSystem.InputManager.OnNativeDeviceDiscovered (System.Int32 deviceId, System.String deviceDescriptor) [0x000c4] in <10161bd09ede4f5fbcf0351a78e63cd5>:0 )
[HIDrogen] Inspecting new USB Device
[HIDrogen] Ignoring USB Device (VID 0x1BAD PID 0x0003)
hasty kernel
#

it should be picking things up so long as you have hidapi installed and the udev rules for HID devices configured

hasty kernel
#

it also receives the configuration descriptor explicitly by configuration number

minor zealot
# hasty kernel it *should* be picking things up so long as you have hidapi installed and the ud...

I seee. It seems like I have both the hid rules and necessary libs in place mentioned in the README. Wonder if I need different versions of these libraries or something.

$ cat /usr/lib/udev/rules.d/69-hid.rules
KERNEL=="hidraw*", TAG+="uaccess"

$ sudo apt install libhidapi-hidraw0 libudev1
[sudo] password for lilbighead:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libhidapi-hidraw0 is already the newest version (0.14.0-1build1).
libudev1 is already the newest version (255.4-1ubuntu8.6).
libudev1 set to manually installed.
The following packages were automatically installed and are no longer required:
  libfcft4t64 libutf8proc3 ncurses-term
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
compact glen
#

@hasty kernel After the latest commits:

  • I still need to apply my 'fix build for non-windows platforms' commit.
  • libusb_set_configuration works with '1' (configuration number?) not '0' (the index?)
  • unplugging/replugging during play no longer works
  • Exit doesn't seem to power off the controllers
hasty kernel
#

I still need to apply my 'fix build for non-windows platforms' commit.
i forgot about that bit, whoops lol
libusb_set_configuration works with '1' (configuration number?) not '0' (the index?)
the set configuration call isn't happy on Windows with 1 for whatever reason

not sure what's up with the other two

hasty kernel
#

made some more fixes, there were various issues on my end after trying with the WinUSB driver instead of libusbK

#

relying on device handles being unique was also not working, so i made it grab bus/port numbers and device addresses and use those to construct a better unique ID

hasty kernel
compact glen
#

Much better after the latest commits:
✅ it now builds without ifdef changes.
✅ set_configuration works without changes.
It seems like my 'Powering off at exit' issue was because I was testing in the Unity Editor (where class lifecycles seem a bit different?). When testing with an actual build, it works fine.

One remaining issue is hotplugging. I sometimes (maybe one in 5) get a failure to reconnect with the controller. After a bit of debugging, I can see it's because I'm stuck inside the while loop of X360WirelessController.PollThread with a m_ConnectionState of ConnectionState.LinkControl, which is unhandled by the switch statement. No idea why at the moment... hope that helps?

hasty kernel
#

hmm

#

so it's not sending the packet that contains the subtype for some reason

hasty kernel
#

where class lifecycles seem a bit different?
yeah, the editor is a little bit odd with its domain reloading stuff

#

for me, powering off works fine when triggering a script recompile or when starting Play Mode

#

it just doesn't do anything when exiting Play Mode

#

since the input system's state isn't scoped to play mode

#

and HIDrogen isn't doing anything to detect when it's exited

hasty kernel
compact glen
hasty kernel
#

tbh i'm not particularly sure either for Linux lol

#

on Windows i use Wireshark with the USBPcap driver

compact glen
#

After trying to get my head around the new code, I'm not actually sure if you're requesting a link control packet are you? Afaik, you only get one when the controller first connects to the reciver, which could come at a time when we're not listening?

hasty kernel
#

i'll have to double-check that, i didn't see anything about requesting the link packet in the docs

compact glen
#

It was in my code :p

#

Hold on I'll link ya

hasty kernel
#

does that request the link packet? as best as i can tell it only requests the connection status

#

and it's still done in the new code, repeatedly on a timer instead of just once on initialization

#

i desperately need to get some sleep rn lol, so i'll take a further look at it all later once i've had time to rest on it

cerulean grove
#

Just for info, is this going to fix controllers not having certain inputs on Linux? It's just the red buttons I'm so close to having something playable 😭

hasty kernel
#

this will only fix wireless Xbox 360 controllers specifically, but yes

cerulean grove
#

Do you have an idea of how long it will take to fix other controllers? On the issue tracker online it says it's planned for release 1.13 which just came out on beta but it doesn't seem to be fixed

hasty kernel
#

v0.13 has no official form of release beyond the indev nightly versions, not sure what you mean by "just came out on beta" lol

#

any features planned for it are worked on as people have time for it, and they make it into nightly within 12 hours after the commit is pushed

compact glen
compact glen
hasty kernel
hasty kernel
compact glen
#

@hasty kernel I'm still not entirely sure how, but I'm quite easily able to get X360WirelessController stuck in the m_ConnectionState == ConnectionState.LinkControl status after hotplugging a few times, which will never finish the connection process. It seems like there's a race condition somewhere causing the link control packet to get missed.

#

I have found a solution however, which is to add case ConnectionState.LinkControl: to X360WirelessController after L225, which will retry sending the RequestConnectionStatus() packet every 5 seconds 🙂

hasty kernel
compact glen
#

I'm testing on macos

#

It could also be a quirk with my unofficial receiver

#

But other than that, I think it works very well! Is there anything left to do with this now?

hasty kernel
#

only things left are:

  • figure out what's going on with this issue (which you've given a good lead on now)
  • switch to libusb's asynchronous API so that it's not constantly spamming the USB stack with read requests lol
compact glen
#

Hey @hasty kernel, I've been doing some testing with linux, and have come across two issues so far:

  • instruments aren't connecting. I've traced this down to a bad second argument in libusb_set_auto_detach_kernel_driver, and hardcoding it to 1 fixes this.
  • when patching around the above, the instruments connect, but inputs are delayed by a second or more and sometimes aren't registered at all. Not exactly sure why yet.
hasty kernel
#

and hardcoding it to 1 fixes this
hmm, it should already be getting 1

image.png
compact glen
#

Is L557 in libusb.cs correct?

hasty kernel
#

ah hold on

#

i have additions skewing the line numbers here

#

it should be, UnmanagedType.Bool refers to the Win32 BOOL type which is typedef'ed as int

compact glen
#

That line must be an issue on non-windows platforms then, as changing it to int and passing 1 works, but I don't yet know enough about c# to tell you why 😉

#

I did also try [MarshalAs(UnmanagedType.I1)] bool enable, and had the same issue :/

hasty kernel
#

it needs to be a 4-byte integer

compact glen
#

Hmm. Something to do with platform endianness?

hasty kernel
#

not very likely, i'm not aware of any modern PC architectures that aren't little-endian

#

in particular, x86 is always little-endian

hasty kernel
#

did some testing in WSL and it all seems to check out (though this is in .NET Core and not Mono)

image.png image.png
#

works fine on standalone Mono as well

compact glen
#

Do you have a linux VM or something you could try it on?

hasty kernel
#

that's effectively what WSL is lol

hasty kernel
#

having one heck of a time trying to get the asynchronous API to work correctly lol

#

consistently crashing on exit, and sometimes on startup

compact glen
#

Hey @hasty kernel, I've tried again with the latest changes, and I can't replicate the issue I was having with ConnectionState.LinkControl, so that seems fixed ✅

compact glen
#

Regarding the second arg of libusb_set_auto_detach_kernel_driver... I'm beginning to think that was a bit of red herring, and was never a problem. I'm still getting the 'extreme lag on linux' issue, and I think that was what led me down the path of the second argument. A bit random in retrospect. Sorry for sending you down a rabbit hole on that one. 🙂

#

So yeah, input lagging seems to be the only issue left, which seems to only affect linux and not macos. When the controllers eventually connect, which can often take a minute, I'm seeing missed inputs and sometimes inputs stuck 'on'. This issue wasn't present with my build (which I'm still daily driving atm).

compact glen
#

Hey @hasty kernel. I've had another look at the X360WirelessController class to see if I can spot the issue I'm having with stuck and missed inputs. Is there a good reason to wait for 1ms on L239, in addition to the 5ms of blocking on L308? I'm wondering if the former is the cause of the missed inputs.

hasty kernel
#

without that wait, the read thread will be constantly running and unnecessarily burning through CPU cycles

compact glen
#

The libusb_interrupt_transfer will block for $timeout ms, though, right?

hasty kernel
#

only if there are no packets to receive

#

if a packet is received within that timeframe, it will return before the timeout duration elapses

#

but i don't know whether libusb uses a thread sleep or a busy loop for waiting

compact glen
#

What about if packets arrive when we're not waiting at libusb_interrupt_transfer for 5ms?

#

In an earlier message I guestimed about 1 in 5 input events seem to be missed... this theory lines up almost perfectly with that suspicion

compact glen
#

Considering we're using PollThread exclusivly for libusb_interrupt_transfer shouldn't be a problem to just wait for it to resolve (or timeout)

#

That while loop could essentially be while(true)

granite ingot
#

Hey everyone I know it’s a year out I recently joined this server to look further into making the 360 keytar play on Linux specifically on steam deck and so far no luck is there any method/fixes?

compact glen
#

Hey @granite ingot, welcome to the server!
Your keytar should work fine on Linux, but you will need to follow the step in this document that starts with “For improved compatibility”. Let us know how it goes.

https://github.com/YARC-Official/YARG

GitHub
GitHub - YARC-Official/YARG: YARG (a.k.a. Yet Another Rhythm Game) ...

YARG (a.k.a. Yet Another Rhythm Game) is a free, open-source, plastic guitar game that is still in development. It supports guitar (five fret), drums (plastic or e-kit), vocals, pro-keys, and more!...

granite ingot