I'm trying to write a component that collects data about connected / attached devices.
My component should work on Linux as well as on Windows.
For the time being I succeeded doing that on Windows machines by querying the Win32_PnPEntity.
I'm looking for a way to programmatically collect data about all attached devices (I.e usb devices, disks, Bluetooth etc...) on Linux.
After searching the internet,
I didn't found any solution to get all of this information.
As I said, in windows I can query the Win32_pnpentity,
Is there a way to do the same in Linux?
(I rather not use utilities, such as lshw etc...)
Thanks,
Amit.
libusb offers examples/listdevs.c, and this code should run equally well on Windows and Linux.
Alternatively, you can simply poke around in /sys/bus/usb/devices. For example, entries like 1-2, 1-4, (a digit, a dash, and a digit) represent whole connected devices, and these directories contain manufacturer and product files representing the device.
I'd use the libusb approach for anything I wanted to distribute widely. If you're doing internally-owned code then the directory approach should work well. Changes to the interface should be few and far between.
Related
Outside of Laptops, changing e.g. brightness of monitors requires DDC/CI. This is best done in userspace, I believe. Loading i2c-dev (kernel module) gives access to i2c-buses under /dev/i2c-<number>. Unfortunately not just monitors supporting DDC/CI have i2c-buses and it is far from ideal to read/write on unrelated buses, while trying to find which connects to what.
It seems that i2c bus adapter drivers already categorize their buses: e.g. I2C_CLASS_DDC for exactly what I’m looking for.
Is there any way to see the adapter class of a i2c-dev device?
(Or equally good: any way to match the device I want to talk to for DDC/CI from X11 workspaces or similar?)
You can try to look at ddccontrol:
ddccontrol -p
This utility scan I2Cs and somehow detects which are connected to monitors.
You can examine it's source code and find solution.
P.S.
This may be not an answer, but, sorry, I have not enough "reputation" to write a comment.
I have a headless Debian ARM machine that I'm running Node on. The device has hard buttons that are mapped to normal keyboard events using gpio-keys.
My goal is to capture the global events from both the hard buttons as well as any attached keyboards in Node. I need a solution that can capture the keydown/keyup events independently of the terminal that it's run in (it will be run over an SSH session). It doesn't have to be cross-platform, as long as it works on ARM Debian I'll accept it.
I am imagining something reading directly from whatever sysfs attributes are necessary, but that's not a requirement.
Can anyone help me on this? I've been stuck for a while.
One of the device files /dev/input/event* will represent the gpio-keys device. You can figure out which one in a number of ways; one easy one is to look at the contents of the uevent file for the device, e.g. /sys/class/input/event0/device/uevent. It'll contain a number of useful key-value properties.
Once you've figured out which device you want, you can open and read from it. It'll return a stream of struct input_events, as defined in <linux/input.h>. These events will correspond to presses and releases for each of your buttons.
You may also want to take a look for existing solutions for at least part of the problem, such as node-keyboard: https://github.com/Bornholm/node-keyboard
I have been trying to understand the mfd framework in linux kernel to write my drivers but there seems to be hardly any documentation and the mfd core itself doesnt seem to have much helpful comments. So, I am trying to understand what the mfd_cell structure describes. That seems to be the basis here. What I m particularly interested in finding out is if this used as a general abstraction for 'x' number of sub-devices or is it intended/useful for a full hierarchy of sub-devices.
An MFD is a device that contains several sub-devices. For instance, in embedded systems a PMIC usually contains a battery manager, a charger and sometimes devices with unrelated functions like a USB PHY, an Audio codec, a Real-Time Clock, ...
A cell is meant to describe a sub-device. The mfd subsystem will use the information registered in that structure to create a platform device for each sub-device, along with the platform_data for the sub-device.
You can specify more advanced things like the resources used by this device and suspend-resume operations (to be called from the driver for the sub-device).
The new platform devices that are created will have the cell structure as their platform data and can access the real platform data through cell->platform_data.
I want to set up my embedded application as a HID device, with a separate process controlling the HID interface to allow dynamic connections to a PC. There seems to be many people out there that have done it, but I would like to do is:
a) Understand how to configure my build (Freescale i.MX Linux using ltib) to include the USB APIs and includes in my build (ie g_hid.h).
b) Where can I find an example application which does something like move the mouse about the screen to demonstrate the operation of the HID?
Thanx for your help!
http://lxr.linux.no/#linux+v3.3/Documentation/usb/gadget_hid.txt is an example of how to operate a mouse HID.
I'm creating a tool that checks for the presence of many (~100) bluetooth devices. I'll have their MAC addresses already. I just want to know if they're in range, even if not set to discoverable.
Using hcitool name <bt_addr> does this. But it's not very fast; it takes up to 5 seconds to check each address, especially if the device is not in range. If I fork parallel subprocesses, it still takes up to 5 seconds each, as if bluez or something in the stack is serializing the requests.
Is there a faster way to check for the presence of BT devices by MAC address? I don't need to know the names of them, just if they're around (whether set discoverable or not). Ideally I'd like to check all ~100 in half a minute or less.
Bonus points if the solution doesn't require sudo (like l2ping), but OK if that's the only way. Platform is Ubuntu Linux, using a Cambridge Silicon BT dongle if it matters...
Thanx,
-- Steve
No
If the device is not discoverable then there is no fast and effecting way.
Any other scheme (including requesting the name) requires establishing a connection - which will take few seconds each, there is no way the connection process can be done in parallel at the radio - it is one at a time.