Basically, I have a PCIe capture card. Kind of a no-name brand, but it actually works great. But not in Manjaro… Ubuntu and MX Linux both see and can use the card absolutely fine, but Manjaro simply doesn’t see it at all. It turns out that both Ubuntu and MX Linux have the specific 1e4e:7102 Cubeternet Live Streaming USB Device module and Manjaro simply does not, which is really weird.
I guess my question is, why isn’t the module in the Manjaro kernel? At this point, I’m just very curious as to why, especially since Manjaro has had a reputation for best-in-class hardware compatibility.
Well lads, after a lot of poking around, I got some good news and some bad news.
Good news is Manjaro actually does have the needed modules and also has them loaded in already on boot-up. Those modules are uvcvideo and snd_usb_audio.
The bad news is… I don’t know what the problem is anymore. Despite the card working flawlessly in both Windows and two different distros of Linux and despite Manjaro seemingly having all the needed dependencies to at very least see the card, it’s now a mystery to me as to why this card isn’t working at all in Manjaro.
This is because I don’t think my device is really manufactured by Cubeternet at all. I’ve seen one of the visible physical chips on my PCIe card which is actually the main video processing chip and it’s an EJ511 manufactured by eEver (a branch of Etron Tech). lspci also lists another chip in use on the board by the same company. An EJ168 USB Host Controller.
Going off of the spec sheets and information given on the company site, the EJ511 was actually originally intended to be used in USB capture cards, but the company I bought my PCIe card from must have simply manufactured it by taking EJ511 chips and slapping them on a PCIe board instead and configuring it to draw power and output through a PCIe slot instead of a USB port.
You’d think it would be China jank, but it actually works surprisingly well. I’m really impressed by its performance, compatibility (save for Manjaro), and solid featureset.
snd_usb_audio is a standard audio driver for USB devices and any Linux distribution should have the kernel module
uvcvideo is probably standard too, but I do not use webcams to know for sure
The only devices identified by linux-hardware scans from Etron Technology, Inc are two USB 3.0 controllers Etron Technology Inc [1b6f] | linux-hardware.org
I cannot find a Vendor ID for eEver Technology, and their website pagefor this device EJ511
I suggest you check if the microphone is detected as a capture device in ALSA
[ 1.733936] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1.762180] usb 2-1: New USB device found, idVendor=1e4e, idProduct=7102, bcdDevice= 1.00
[ 1.762181] usb 2-1: New USB device strings: Mfr=6, Product=7, SerialNumber=3
[ 1.762182] usb 2-1: Product: Live Streaming USB Device
[ 1.762182] usb 2-1: Manufacturer: eEver
[ 1.762183] usb 2-1: SerialNumber: 20000130041415
[ 4.997332] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 12.340664] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 13.645249] usb 2-1: USB disconnect, device number 2
[ 13.645334] usb 2-1: cannot submit urb (err = -19)
[ 13.645411] usb 2-1: cannot submit urb 0, error -19: no device
…
[ 5.034483] uvcvideo: Found UVC 1.00 device Live Streaming USB Device (1e4e:7102)
[ 5.039454] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 5.039940] usbcore: registered new interface driver uvcvideo
I’ll compare it to whatever Ubuntu says about it in its dmesg.
[ 12.340664] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 13.645249] usb 2-1: USB disconnect, device number 2
[ 13.645334] usb 2-1: cannot submit urb (err = -19)
[ 13.645411] usb 2-1: cannot submit urb 0, error -19: no device
^ It looks like both Ubuntu and MX Linux do NOT have these four lines in their dmesg logs. uvcvideo also logs new lines in both aforementioned distros. Camera not initialized and two other very similar entries I can’t remember.
There is plenty of dmesg data for Arch and Ubuntu systems on linux-hardware, but Ubuntu
systems do not have ALSA data from arecord to show an audio capture device https://linux-hardware.org/?id=usb:1e4e-7102
The 2 Arch probes are showing an ALSA capture device
card 2: Device [Live Streaming USB Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
The probe on Fedora system is showing the device with a different name, but appears to be OK otherwise
card 4: Device [CA FLINT USB Device], device 0: USB Audio [USB Audio]
Guys, this is now (pretty much) a confirmed kernel bug for 5.9.x. Switched back to kernel version 5.4.x and the problem was immediately solved. Also, Ubuntu and MX Linux both use kernel 5.8.x, not 5.9.x as Manjaro does.
Why is Manjaro using 5.9.x anyway when not even Fedora (stable) uses that late of a version?
Kernel v5.9 has been marked End Of Life here for a while now
users are recommended to change to kernel v5.10 or later
For a Ryzen system you may want to try kernel v5.11
I expect you know how to add/remove kernels in manjaro-settings-manager -m msm_kernel considering you installed kernel v5.4
!!ALSA/HDA dmesg
[ 3.569199] usbcore: registered new interface driver snd-usb-audio
[ 3.569708] uvcvideo: Found UVC 1.00 device Live Streaming USB Device (1e4e:7102)
But !!Loaded ALSA modules is not showing snd-usb-audio in use
and the audio device is not detected in !!Soundcards recognised by ALSA
Manjaro does not backport patches to earlier kernels to the same extent as non-rolling distributions, but ALSA might support this audio device with a later kernel and/or BIOS
Started up 5.11.x and still the device does not work at all. Looks like this regression continues all the way up to the latest kernel version I’m afraid.
And I don’t think this is an issue with ALSA nor with the BIOS as it seems as long as the kernel version is <5.9.x it will work completely fine. I updated the BIOS not that long anyway. I should also probably add that Windows also handles the device completely without issue.
I suggest that you get alsa-info data for kernel v5.4 with the device working and open a bug report with the kernel developers at https://bugzilla.kernel.org/
