SUBSYSTEM= "usb" ?

[astrorafael]

Hi
Just downloaded the github code and after installing it found out that udev rules did not work (I have a MidiSport 2x2) I found that in y system (Ubuntu 16.04), udevadm monitor -p gave SUBSYTEM="usb", not SUBSYTEM="usb_device"

I changed the rule, restarted udev and it worked.

UDEV  [617922.115527] add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/015
DEVNUM=015
DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=1002
ID_MODEL_ENC=1002
ID_MODEL_FROM_DATABASE=MidiSport 2x2
ID_MODEL_ID=1002
ID_REVISION=0121
ID_SERIAL=0763_1002
ID_USB_INTERFACES=:ff0000:
ID_VENDOR=0763
ID_VENDOR_ENC=0763
ID_VENDOR_FROM_DATABASE=Midiman
ID_VENDOR_ID=0763
MAJOR=189
MINOR=142
PRODUCT=763/1002/121
SEQNUM=5701
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=617922114905

UDEV  [617923.170004] add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
.MM_USBIFNUM=00
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
DEVTYPE=usb_interface
DRIVER=snd-usb-audio
ID_MODEL_FROM_DATABASE=MidiSport 2x2
ID_VENDOR_FROM_DATABASE=Midiman
INTERFACE=255/0/0
MODALIAS=usb:v0763p1002d0121dc00dsc00dp00icFFisc00ip00in00
PRODUCT=763/1002/121
SEQNUM=5702
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=617922123199

[oeai]

so there's 2 ways - you can create a fork call it "for debian" and I'll mention about it in readme or I can create a new branch with your changes, but right now I feel like in another dimension, don't understand a thing, thnks btw good to know

[astrorafael]

Hi. I think it is safer to create a fork. It solves my needs and It should be posible to work with the magic of autotools and figure out a way to handle with these differences in the configuration itself, not doing branches. Then, I would isue a pull request to your repo. The only thing is I have to become an Autotools wizzard :-)

[oeai]

fine! but maybe you just have a different version of udev and we could do a different branches depending on udev version.
my version where i probably tested is 219

[astrorafael]

My version is 229 (udevadm --version). What you could do is to create a 'develop' branch in which we could do some experiments before merging into master or doing another branch. I still don't know if this "usb" or "usb_subsystem" depends on the UDEV version or Linux Distro.

[maxlemieux]

The fix works in Ubuntu 19.04, UDEV version 240, kernel 5.0. Thanks all for keeping this software up to date.
The 'midisport-firmware' package in 19.04 repositories contains this fix.

[lastfreenick]

I can also confirm this fix worked for me. I'm running (X)Ubuntu 20.04 and prior to applying this fix, struggled to get my M-Audio Oxygen 8 Keyboard up and running.

[Some-E]

Okay, I was running from terminal for two years, after each boot to get it working. First verifying the device number and then running the firmwareloader. I think it worked in Ubuntu Studio 19, but not in 20. Still using 20.

Recently I did an extensive debugging session by trying a variations of test rule. I ended up removing the SUBSYSTEM== completely, because it didn't work with "usb" nor "usb_device". There's no point of checking if it's an USB device, because it always is, and there are the vendor, device model and device version attributes to make sure it's the correct device :)

[oeai]

it's nice if it works.
for security reasons, using usb-check is not a wrong really.
so if we loose some security layer, the system goes closer for bugs and vulnerabilities.

thank you for trials .' )
this can be a workaround for people, so maybe you can fork it and show your changes for public .

so in case you don't have a usb check, then it will have to check all present devices in system
and this can hang some process and whole system.
there is a lot of virtual devices, ttys and some others, so it will query those,
but some can be like infinite and this query can also interrupt something.

[Some-E]

so in case you don't have a usb check, then it will have to check all present devices in system and this can hang some process and whole system. there is a lot of virtual devices, ttys and some others, so it will query those, but some can be like infinite and this query can also interrupt something.

Okay, good point! I will have to try again before forking. I find it very weird that "usb" doesn't work. SUBSYSTEM or SUBSYSTEMS? I've got a decent struggle to understand even the basic things... I've read udev manual, but I don't know much about the system.

[oeai]

SUBSYSTEM or SUBSYSTEMS? I've got a decent struggle to understand even the basic things... I've read udev manual, but I don't know much about the system.

i'd suggest you to not getting that deep in code, if it works for and it doesn't harm system, maybe it's alright to leave as is.
i think that you probably want to work with music, not with code really )))
Sometimes you can just find similar program here somewhere and just see how they solve this.

[Some-E]

If this was the only thing :D Recently I got a hardware failure with soundcards... but the cards are ok. Audio just stopped working. I'm suspecting the PCI connector, as nudging the card jammed the whole computer. Took everything off, now just one card, everything works fine. When I'm not busy with projects, I'll add the other cards.

But an actual issue I added today for Studio Controls: one main + TWO extra cards (M-Audio Delta 1010LT, all the same model) seem to go wrong a bit: their inputs are not added to the system (?) in the correct order card by card, they begin to interleave at some point. It's so fun and maybe rare case, that had to tell here too :)

[oeai]

one main + TWO extra cards (M-Audio Delta 1010LT, all the same model) seem to go wrong a bit:
if they are the same they can try to use same firmware and also had some wrong ids.
actually i had about the same issue with SB and EMU cards, it happened that they had a same chip identifier
and wasn't able to resolve it correctly, so i had to make some changes in driver for linux
https://github.com/oeai/emu1212m-alsa-driver - you can check some of my changes there, maybe this can help.
i mean you're not alone and you get to the right place maybe ))))
this can be something about wrong enumeration maybe, but not sure, maybe check/write a config file with exact pci-device numbers or hardware ids.
maybe you should also check each card separately - if it works.

[Some-E]

Thanks. I think I got the idea, but I'm pointing this to the Studio Controls, not drivers. All cards work fine, two of them work flawlessly together when set up with Studio Controls. Three of them work fine when I'm doing the "thing" (multi card config file) myself and choosing it as the master "device" in Studio Controls. I guess Studio Controls is building the multi device config on the fly, but gets confused with the two similar extra cards.