I'm trying to understand the layers of software that interface with USB webcams.
As I understand it:
A standard webcam fits into the category of a 'USB Video Device Class', or 'UVC'.
And in linux, Video4Linux (V4L, V4L2) encapsulates all video capture devices. V4L(2) provides two APIs: one is for programs that want to get and use the data from the capture devices. The other API is internal, for the drivers themselves, so those drivers can then be accessed by programs via V4L(2)'s external API.
One of those V4L(2) drivers is the UVC driver which encompasses all standards-compliant USB webcams.
My question:
Looking at that homepage of the UVC driver, it shows a list of supported devices. Has each one of those devices been catered for individually within the UVC driver? Or only if a device had a peculiarity that needed to be dealt with? In other words, should all standards-compliant USB webcams automatically work with the UVC driver, whether or not they're on that list?
Thanks
I believe the text right under the "Supported devices" headline answers your question:
The table below lists known UVC devices. Other UVC compliant video input devices are very likely to be supported.
So, un-listed devices that comply with the standard should work. Speaking from experience with mass storage ("USB flash drives") in embedded environments, your mileage will probably vary since not all devices are fine examples of engineering.
The USB Video Class have released manuals that have specifications, that a Vendor should implement. When a Vendor designs their product considering these specifications, that device becomes UVC Compliant.
I am using a Webcam that is UVC Compliant but not listed.
When I plug in my webcam to a Linux machine, a simple 'dmesg' shows the following messages
1. UVC Complaint device found
2. The device is unlisted.
I am able to easily stream uncompressed frames through this webcam.
Related
I am trying to understand Linux USB Device drivers, most of the documentation speaks about the USB Device decoded into
configuration
interface
Endpoint
Linux only supports one configuration. Are these hardware entities or simply data present in the driver of the data which it passes on USB Device detection
When referring to a USB device, the terms "configuration", "interface", and "endpoint", are all properties of the device. They can be changed if you are able to reprogram the device, but if not then you can just think of them as part of the hardware.
The device has binary chunks of data called "descriptors" which the computer fetches so the computer can know what configurations, interfaces, and endpoints the device has.
You can learn all about those items and their descriptors by reading the USB 2.0 specification:
https://usb.org/document-library/usb-20-specification
I’m working on a project that uses BLE (Bluetooth Low Energy) protocols for transferring data and am currently limited to my MacBook due to some Admin permission constraints on my work machine (running Windows).
I need to find a USB adapter that supports Bluetooth 4.0 Tx/Rx, however I am ONLY finding these dongles that solely support Windows distros. So my question:
1) Why is this? Is Bluetooth SIG or at least BLE somehow a propriety protocol patented or somehow bound to Microsoft? I mean, there exist iOS libraries for high-level BLE management, so...
2) Am I just missing the product I’m looking for and there are such accessories compatible with a Unix based OS?
Who said USB dongles only support Windows? On the contrary, I haven't heard about a single USB dongle that doesn't support Linux. Bluetooth SIG has defined and specified HCI over USB and every device uses that protocol (however some device specific code is often needed to initialize the device). See a list of some tested devices at https://github.com/50ButtonsEach/fliclib-linux-hci/blob/master/README.md#bluetooth-controllers. Those should work with Mac OS X as well, but if the computer already has a built in Bluetooth chip you might need to adjust the currently used device.
I have a USB audio device (Scarlett Focusrite 18i6) which does not require a driver, so I assume it uses the USB HID Audio Class standard.
It works on everything from Windows and Mac to Linux and iOS.
But on Mac and Windows, it has a control application which can for instance enable and disable direct monitoring.
How would I go about reverse-engineering how this is done, so that I can reproduce it on platforms where the control application does not exist?
I'm thinking of booting up Windows in a VMWare session and then logging the USB communication (somehow?) while using the control application, but it does sound tedious considering the amount of data and my very limited understanding of USB.
Any other suggestions?
You could try running the control application using Wine instead of reverse engineering it. However, if it's accessing USB devices then there is a good chance it might be using an API not supported by Wine.
To reverse engineer it, you should find a way to look at the USB traffic between the computer and the device. Total Phase has some hardware USB protocol analyzers, but you might be able to find a good software solution for free.
I am learning to program a USB device (iBall 3.5g USB Dongle) using libusb.h header library.
Until now I am able to identify my device using the Vendor ID and also open the device for operation.
As a next step I would like to know the available commands (or the controls) for example : command to scan the surroundings for available GSM networks.
Obviously I will have to talk to the devices' firmware to extract the necessary information.
I tried to search for the technical datasheet for the 3g dongle, but couldn't find any.
The dongle is powered by a Qualcomm chip
Do you know any of the methods in which I can get the control commands for a usb device ?
Thanks in advance.
There is no simple procedure for figuring out what commands a USB device has. You need to use a combination of looking at the descriptors reported by the device, seeing if the device supports any particular USB device class, reading the USB specification, and maybe doing some reverse engineering using a protocol analyzer.
A good first step would be for you to use lsusb -v to print human-readable descriptions of the device's USB descriptors.
I wonder whether it is possible to emulate a specific bluetooth device like a Remote Controller for a TV or another device with my PC. I'd be okay with installing an additional hardware device for my computer (e. g. a BlueTooth PCIe card).
I imagined something like "recording" all single commands of my original remote controller using my Bluetooth card and afterwards use these recorded commands to turn on my TV for example.
Is something like this possible (with additional hardware maybe)?
Of course this is possible. Bluetooth is just a protocol and you can impliment it in your custom software to emulate all kinds of devices. If you need to emulate simple devices like keyboard or mouse, there are many ready solutions like this.
But if you have non standard device, there won't be any ready solutions and you will have to implement it yourself. What can help you:
If you have some kind of controller for PC and you want to emulate device with unknown protocol, you can use WireShark or other sniffer to understand what's going on.
There is an emulator called BT-Sim, but it is so poorly documented that I can't even guess what it does.
You can can take as example different android software like described in answers to this question.
You can check different program samples for PC like this.
For hardware you need only simple Bluetooth dongle. However, if you want to spy on some BLE (Bluetooth Low Energy) devices, you can buy hardware sniffer like this.
(At least in Windows 10) Microsoft Store has an application called "Bluetooth LE Explorer" which is able to simulate different kind of Bluetooth GATT profiles as a peripheral.