What is the pci.ids file? Where can I find it? What is the purpose of this file?
I'm new in Linux programming and stumbled over this file.
This is a repository of known ID's used in PCI devices: ID's of vendors, devices, subsystems and device classes. It is used in various programs to display full human-readable names instead of cryptic numeric codes.
The location of this file is at: /usr/share/hwdata/pci.ids
Read more
Related
I'm learning about Bluetooth (and LE), and I'm writing simple desktop application for Windows 10 to communicate with different kinds of BLE fitness devices.
I have Bluetooth up and running and I can send and receive data, but I have a small problem; sometimes I don't get correct manufacturer name from "Manufacturer Name String". I need to know the manufacturer so that I can send manufacturer specific commands to the devices.
The problem seems to be related to different computer hardware and/or drivers, because the problem happens only on my friends computers, not on my computers. The devices I use don't support "PnP ID" and "System ID" so I can't use those to get needed information.
I also read somewhere that I can use MAC address to know the manufacturer, but the devices I use don't give me the address in a format that can be used to get Company Identifier.
What else can I use to get the manufacturer name and/or code?
If the advertising data contains a manufacturer data record, the 16-bit manufacturer id can be looked up here:
https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers
Looking at the MAC address will probably be very unreliable, as many BTLE devices use a random MAC address for privacy reasons.
However, there is also the UUID of the individual BTLE characteristics, which contains a manufacturer code. See here for a list: https://www.bluetooth.com/specifications/assigned-numbers/16-bit-uuids-for-members (note that this applies to shortened 16-bit UUIDs, not to the full 128-bit ones).
Considering most of the fitness devices follow GATT specification, 0x2A29 uuid corresponds to org.bluetooth.characteristic.manufacturer_name_string.
https://www.bluetooth.com/specifications/gatt/characteristics/
Scenario:
I have an usb-RFID reader
attaching it to notebook it works as an newly attached USB keyboard, e.g. without needing to install any drivers
when touching the reader with RFID tag
it enters into my current window (for example terminal/shell) the RFID number (like 0009339384\n) - e.g. it even sends the \n.
so, it works exactly as if I had typed the numbers in my notebook's keyboard
The questions are:
is it possible read the RFID reader directly without some kernel-level drivers, e.g. something like cat /dev/keyboard1 ...
in other words, how can I determine from which "keyboard" the characters are coming?
using OS X, but would be nice to know the solution for Linux too.
Moreover, I want attach two readers - so I definitely need to clearly differentiate between the two readers. And I want use the rfid-reader in a bash (perl) script, so I'm definitely looking for a solution without compiling some "drivers"... It is possible?
The OS X identifies it as:
SYC ID&IC USB Reader:
Product ID: 0x0035
Vendor ID: 0xffff
Version: 1.00
Serial Number: 08FF20140315
Speed: Up to 1.5 Mb/sec
Manufacturer: Sycreader RFID Technology Co., Ltd
Location ID: 0x14100000 / 18
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
EDIT Okay, looks like in Linux it can be done - just found
this https://unix.stackexchange.com/questions/72483/how-to-distinguish-input-from-different-keyboards
also Accessing multiple keyboards input by C++ (or python) in linux
For OS X - exact duplicate on unix: https://unix.stackexchange.com/questions/228413/route-keyboard-through-only-dev-ttys000-on-mac-os-x - unfortunately, closed without any answer :(
Ok, so - easily solvable in Linux. As in edits in the question - here are already many similar questions like this.
The solution is: reading the particular /dev/input/eventN device(s).
In my case, me using the Linux::Input perl module. Works perfectly.
It is pointless adding code here, the package comes with the evtest.pl - so anyone could easily check how it works.
Still need solve one issue - e.g. even when reading the device and nicely getting all events from the rfid reader (4 events for one number), the rfid-code still is inserted into the active window, like it coming from a keyboard. (This will be an another question).
For OS X i haven't an easy solution yet, but now focusing for the Linux variant. :)
There is one thing that might help you solve this problem without resorting to programming in C. It is called multiseat. I didn't do it myself I just know it exists. In general it is a way how multiple people can work on same computer at the same time just using multiple keyboards, mice and monitors. It is not exactly what you are looking for but there might be possible way.
I need to do some NON-STANDARD signal processing operations with an RFID-reader, so I'd like to know if it is possible to extract antenna's individual analog (actually digital samples right after ADC) input signal samples with Motorola FX7500 (if you know how this works on FX7400 or FX9500, please do tell, could be helpful). Samples would be processed in a JAVA-based host computer program.
What I've already tried:
Investigating Motorola's own RFID3 API's possibilities, it doesn't go deep enough to actually get in touch with input analog signal samples.
Using LLRP to its full extent, it doesn't allow analog signal sample access either. RFsurvey-functionality would have been helpful to some extent, but FX7500 doesn't support it either.
Accessing RFID-reader's linux terminal, trying to find the driver function(s), that could listen the input sample stream. If current input sample(s) could be extracted from the input stream, I could (in theory) make a script, that would save a few of those sample values in a txt-file in the host computer during a tag inventory round. My linux skills are kinda bad, hence I ask this question.
The only realistic way to solution seems to be via linux terminal, so if you folks have any ideas about that (where to look and what to do), please advise!
Contents of reader:
rfidadm#FX7500abcdef:/$ ls -1
apps
bin
dev
etc
home
include
lib
linuxrc
media
mnt
platform
proc
readerconfig
run
sbin
sys
tmp
usr
var
I cannot completely rule that out, but it's highly unlikely you can get the raw signal digitized; the devices you're looking at aren't really software defined radio devices, typically.
"speaking" RFID physically is a bit different from "usual" wireless communication: The reader doesn't only observe the energy transmitted from the tag, but more importantly the fluctuations of energy extracted from the near field of the reader's antenna coil. Hence, you don't actually have a baseband of RF bandpass signal, but hardware-specific modulations of transmitted (and inversely, antenna-reflected) energy. Demodulation is hence usually done in specialized hardware.
However, do not fret: It's totally possible to build a software defined RFID reader. There have been several approaches to that, but personally, I trust these based on Ettus USRPs and/or GNU Radio best. Look through the results IEEExplore gives you, eg. this search.
Most probably this is not possible with the Motorola readers. What you can do, is use one of the RFID chipsets available on the market: either the AMS RFID IC's, or the Impinj RFID IC's. As far as I know, both IC's support retrieving the digital samples that are received. They also have a development kit to test-drive the IC's.
We are considering using the vendor and product ID of a USB device (obtained via IOKit) to unlock certain features of an application. I'm aware that these values can be spoofed, but I'm not sure how easily it can be done on OSX. What is involved in spoofing the vendor and product ID? Is it something that a non-programmer can do fairly easily?
I suspect it would be fairly easy (for a programmer) to create a kext that creates a reasonably realistic IOUSBDevice object in kernel space. However, once done anyone would be able to load it.
It may also be possible to build a codeless kext using AppleUSBMergeNub to masquerade a device as another (though I haven't tested this, it looks like it might work, assuming you only try to match the IOUSBDevice without actually using it).
It would probably be easier to just hijack your API calls in userspace and give your software the answers it expects.
A non-programmer cannot do that. What you can do is writing a kernel extension (an IOKit driver) for the device, that has a matching dictionary matching the real vendor-/product-ID of the device, which causes the system to automatically load the kernel extension when this device is connected and pass a reference to the device object. The driver is now responsible for initializing the device and create all necessary user space information that is necessary for the IOKit framework (the user space library) to communicate with the device. Usually Apple has default IOKit drivers for most USB device classes (that's why you don't need an extra driver for every USB mouse or keyboard for example), but if there is a more specific driver found, then this driver will be used instead. And when creating the user space data, of course the driver may lie about the vendor-/product-ID, causing the user space program to see false values. Since IOKit is written in C++ and heavily depends upon objects and object inheritance, it is not even necessary to write the driver from scratch, but instead it can inherit from Apple's default driver and just override some methods and otherwise rely upon the super implementation. However, writing IOKit kernel drivers is not that easy and even people developing Mac software for years may have no idea how to do that and the IOKit documentation is one of the worst ones Apple is offering.
So to answer your question: Is it possible? Yes. Is it fairly easy? No. Can non-programmers do it? Certainly not, unless someone else has written a ready to use extension for them, that they only need to install.
It's actually rather EASY, and I'm definitely not a programmer!
Found the guide here
http://rolande.wordpress.com/2012/10/25/getting-the-aten-usb-serial-adapter-working-with-mac-osx-lion
Thanks, Rolande!
I was able to change the IDs of a USB Ethernet adaptor I bought on eBay to use another driver with Mac OS X 10.8.
Since nobody has answered so far, I've stumbled across a page which basically says that you can get an Arduino and program it to return any VID/PID/serial that you want. I still can't find any software-only way to do this.
I can create A OCX in Delphi code to do that
And supply infomation to send/receive data to the USB with other states like:- is it still connected.
Natraly I need a little more detail than that in case that same chip is connected from another product.
example frendly name, device desription.............
Recently, i began developing a driver of an embedded device running linux.
Until now i have only read about linux internals.
Having no prior experience in driver devlopment, i am finding it a tad difficult to land my first step.
I have downloaded the kernel source-code (v2.6.32).
I have read (skimped) Linux Device Drivers (3e)
I read a few related posts here on StackOverflow.
I understand that linux has a "monolithic" approach.
I have built kernel (included existing driver in menuconfig etc.)
I know the basics of kconfig and makefile files so that should not be a problem.
Can someone describe the structure (i.e. the inter-links)
of the various directories in the kernel-source code.
In other words, given a source-code file,
which other files would it refer to for related code
(The "#include"-s provide a partial idea)
Could someone please help me in getting a better idea?
Any help will be greatly appreciated
Thank You.
Given a C file, you have to look at the functions it calls and data structures it uses, rather than worrying about particular files.
There are two basic routes to developing your own device driver:
Take a driver that is similar to yours; strip out the code that isn't applicable to your device, and fill in new code for your device.
Start with the very basic pieces of a device driver, and add pieces a little at a time until your device begins to function.
The files that compose your driver will make more sense as you complete this process. Do consider what belongs in each file, but to some extent, dividing a driver among files is more an art than a science. Smaller drivers often fit into just one or two files.
A bit of design may also be good. Consider what you device does, and what your driver will need to do. Based on that, you should be able to map out what functions a device driver will need to have.
I also believe Linux Device Drivers, Third Edition may help you get on your way to driver development.
Linux files themselves include files based on what they do, what layer they are in, and what layer they access of the call stack. The Big Picture truly informs how each file is related to the next.
I had to fix a kernel driver once. My biggest tip (if you use vim) is to set it up with ctags so you can jump around the kernel source with ctrl-] every time you see a function you don't understand.