Disable devices?
-
@mediamogul said in Disable devices?:
I run a little over 300 xboxdrv maps and my
runcommand-onstart
file is only 32k.And here I am complaining about 7k. :) Maybe it's just in my head.
-
@hansolo77 said in Disable devices?:
Maybe it's just in my head.
Maybe not. It could just be some other factor. 7kb shouldn't be slowing you down though. At 32kb, mine loads almost instantly.
-
That is all that it's doing. I'm really not sure how you'd correlate an event name to a jsX assignment for the if/then statement. Perhaps you could get there by extracting and manipulating information from ....
That's possible, because the events are just symlinks to the
jsx
-tree. So the idea @mitu introduced works withrealpath symlink
and gives outputdev/input/js[0-99]
@hansolo77
I think a good approach would be something like thisRNJS="$(find /dev/input/by-id/ -name '*raphnet.net_nes2usb*USB-joystick*')" RNEJS="$(find /dev/input/by-id/ -name '*raphnet.net_nes2usb*USB-event-joystick*')" JSX="$(realpath $RNJS)" if [ "$1" = "openbor" ] && [ "${JSX##*/}" = "js0" ]; then export RNJS RNEJS JSX sudo mv /dev/input/by-id/usb-raphnet.net_nes2usb_1228-joystick /dev/input/js99 sudo mv /dev/input/by-id/usb-raphnet.net_nes2usb_1228-event-joystick /dev/input/event99 fi
-
I love it when ideas exchange and evolve like this. Thinking on it a little bit, this could be used for a couple of different use cases that I've had in mind and didn't know where to start. I've always disliked how device assignment and handling is out of the user's control.
-
It doesn’t solve the problem though. Simply moving the assignment of jsX on the Raphnet didn’t change any of the other assignments. The Xbox controller still wasn’t working because it was assigned to js5. So my Mayflash that was on js2 was picked up as the next controller in OpenBOR. My wireless keyboard was js3 and the mouse was js4. I would have to go through and move the raphnet and the Xbox too. It’s became much more complicated then it should be. XBOXDRV works because you’re removing the kernel driver then creating a new one where you’re assigning the buttons to keyboard keys. It ALWAYS works. But we shouldn’t have to do that. Granted, my particular situation is unique, but the problem is there.
-
@hansolo77 said in Disable devices?:
It doesn’t solve the problem though.
Why do you always have to be so negative? ;) I do think there's a kernel of a solution here, but I also agree that after you wade through the complexity of what it'd take, it's probably best to seek out a simpler option. This type of issue with controller assignments was actually one of the first things I ever posted about on here. In looking for a solution I ran across xboxdrv and years later it's still a great option for these types of things.
-
@mediamogul said in Disable devices?:
Why do you always have to be so negative? ;)
I'm pessimistic.
https://www.dictionary.com/browse/pessimistic
Comes with my depression, anxiety, low self esteem. The whole belief that nothing positive exists in my life, other than being alive and having a job.Back on topic though, I still think in this particular case, even my initial OP to seek a way to disable a device probably wouldn't have worked either, given that the other devices are also enumerated randomly.
-
@hansolo77 said in Disable devices?:
The whole belief that nothing positive exists in my life, other than being alive and having a job.
Don't forget about a kickass retro-gaming console of your own design. That's pretty sweet too.
-
@hansolo77 said in Disable devices?:
Is there a way to disable a device so it's not being detected and identified?
USB devices can be disabled via usb authorisation in udev. For example, this udev rule disables my Mayflash Wireless Wii U Adapter:
SUBSYSTEM=="usb", ATTRS{idVendor}=="0079", ATTRS{idProduct}=="1800", ATTR{authorized}="0"
I got the values for idVendor and idProduct from the output of the
lsusb
command. Alternatively, you can get them for a specific js* device like this:udevadm info -q all -n /dev/input/js0 | grep 'VENDOR_ID\|MODEL_ID'
Just put your vendor and model ids as idVendor and idProduct values in the udev rule and save it in
/etc/udev/rules.d/60-disabled_devices.rules
(the name between 60- and .rules is arbitrary). That should disable the usb device on the next reboot or after running the commandsudo udevadm trigger
.edit: The change is not permanent. Just delete the rule or change its value "autorized" to 1 to enable the device again.
-
@clyde This looks like a generic solution.
Is it save to execute those commands during a running ES session?So on runcommand-onstart a driver is disabeld.
On runcommand-onend all drivers are enabled again.But I think it won't solve the problem, that a specific driver (maybe the XBOX360) will be first row ;)
Any suggetions? I can't test this because all my joypads are simply assigned as js# devices.... there are no events triggered. -
@cyperghost Alas, I don't now how ES and its emulators will react to this on runtime. I didn't use it myself (yet), but researched it only because of this thread and a general interest for future use.
As for specific drivers, I don't have any experience in that either, but as long as they depend on the devices in
/dev/input/
, they should react to disabled devices there accordingly, I suppose.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.