I am trying to figure out if hid.dll is a part of KMDF or UMDF or none.
I generally use it in my C# program like this :
[DllImport("hid.dll", SetLastError = true)]
internal static extern Boolean HidD_GetInputReport
(SafeFileHandle HiddevObject,
Byte[] lpReportbuff,
Int32 ReportbuffLen);
I wanted to use a similiar one for Linux.What considerations i have to use.
The application where i am using it is for interacting with a sensor device.
HID.dll is a user mode library that provides support routines to obtain information about a Hid collection. HID.dll communicates with HIDClass driver, HIDClass.sys is a windows kernel mode driver for HIDclass device setup class. With HID.dll you dont have to write your own device driver for HID class device.
what sensor devices are you working on?
Related
I'm wondering if it's possible to get the name of a driver from the device that it created. Let's say I have a symbolic link that points to a device, \.\RTF64 -> \Device\RTF64. Is there any way to get the driver name (.sys) using just this information. Either I have to use some undocumented functions exported by ntdll.dll or write a driver which retrieves the information I want. Is it even possible to do?.
I've looked trough various functions exported by ntdll.dll but have not found anything yet.
In user mode you can use SetupDi* functions to enumerate all the devices and interfaces then use SetupDiGetDeviceInterfaceDetail to get the device path.
Then use something like SetupDiGetDriverInfoDetail to get details about the driver.
Edit: As mentioned in the comments it only works if the driver registered an interface for the device object, which is not possible in some cases (control device objects)
I have a USB device (actually, a digital camera) that talks the MSC protocol, i.e. it appears as a disk device and can be talked to with SCSI commands. When it's connected to a Mac, the IOBlockStorageDriver takes over and mounts the volume.
Now, my goal is to prevent this from happening, in hopes that I can then talk to the device thru the SCSI interface functions for SCSITaskDeviceInterface, provided in <IOKit/scsi/SCSITaskLib.h>.
Is that possible? The SCSI Architecture Model Device Interface Guide states that the SCSITaskDeviceInterface is only available for types other than $00, $05, $07 and $0E (the MSC device is type 00), but I wonder if that's only because these types are taken over by the Mass Storage driver and therefore are not available. But if I prevent the Mass Storage driver to take over, will these types, such as 00, become available via SCSITaskDeviceInterface?
If that's possible, what must the kext code do to achieve this? E.g, which class should it subclass and which functions must it implement so that it prevents the mass storage driver from taking over while keeping the device visibile as a SCSI device in the io registry?
If that's not possible, could I then instead use the kext to provide a way to offer SCSI-cmd passthrough somehow? I would like to be able to send custom CDBs to this kext from userland, and it should then route them through the SCSI layer to the USB device. Is that possible? Assuming the kext has received a CDB string, how would it locate the SCSI functions for passing the data onward to the USB layer?
I've so far based my unsuccessful tests on Apple's VendorSpecificType00 sample project, which shows how to inject a kext that adds handling custom properties for a SCSI device.
For now, let's ignore upcoming kext deprecations by recent macOS versions (I want to get this working on High Sierra first).
I am using a i.Mx6 Sabre Lite board running Linux Kernel 3.14.18 and board is supposed to act as a USB Device (USB Gadget). One Vendor specific interface need to be added into CDC/NCM Configuration. CDC/NCM Configuration by default has two standard interfaces - Communication & Data. I have added third interface (Vendor specific) to CDC/NCM Configuration. This interface has two Bulk (IN & OUT) Endpoints. I can verify this newly added interface once board is connected to PC using "lsusb".
Problem:
I cannot see the newly added interface getting exposed to user-space on i.Mx Board or PC, like standard NCM interfaces can be seen as usb0 (Ethernet device) on i.Mx Board as well as on PC and I can PING to/from board using usb0.
If I have to hookup this newly added interface with some g_"driver" (just like standard NCM interfaces are hooked to g_ether); then what is the best choice for BULK I/O?
How to make this newly added vendor specific interface available to i.MX6 user space so as to do read/write on it from Linux Application? I came to know about GadgetFS; but any example would be
Hope someone must have tried similar thing in Linux-USB and can guide.
A vendor-specific interface does not use a standard protocol, so it is not possible to use one of the standard drivers. (And bulk is not a protocol, it is a mechanism to implement your own protocol.)
To access such an interface, you have to use the low-level functions from something like libusb.
I am trying to understand the working of wireless in linux. I started with wpa_supplicant, hostapd applications with the help of their documentation and source code.Understood the flow and basic functionalities of :
wpa_supplicant,nl80211(driver interface)
libnl library(socket communication between user space and kernel using netlink protocol)
cfg80211(kernel interface used for communicating with the driver from userspace with the help of nl80211 implementation in user space),mac80211(software media access control layer)
driver(loadable driver ex:ath6kl - atheros driver).
I understood the above software flow and in my exploration I came to know that for providing freedom for developers MAC layer is implemented in software(popular implementation mac80211).
Is this true in all the cases ? If so what are pros and cons of softMAC and hardMAC ? Do cfg80211 interface in kernel directly communicates with the driver ? who and how communication with mac80211 happens ?
Thanks in advance.
The term 'SoftMAC' refers to a wireless network interface device (WNIC) which does not implement the MAC layer in hardware, rather it expects the drivers to implement the MAC layer.
'HardMAC' (also called 'FullMAC') describes a WNIC which implements the MAC layer in hardware.
The advantages of SoftMAC are:
Potentially lower hardware costs
Possibility to upgrade to newer standards by updating the driver only
Possibility to correct faults in the MAC implementation by updating the driver only
An additional advantage (in the Linux kernel at least) is that many different drivers for different types of WNIC can all share the same MAC implementation, provided by the kernel itself.
Despite the advantages, not all WNICs use SoftMAC. The main advantages of HardMAC is that since the MAC functions are implemented in hardware, they contribute less CPU load.
mac80211 is the framework within the Linux kernel for implementing SoftMAC drivers. It implements the cfg80211 callbacks which would otherwise have to be implemented by the driver itself, and also implements the MAC layer functions. As such it goes between cfg80211 and the SoftMAC drivers.
HardMAC drivers have to implement the cfg80211 interfaces fully themselves.
Also to add :-
Hardmac drivers helps in better as compared to SoftMAC, power save and quick connection/disconnection recovery due to MLME implemented in HW. Better power save is because HW/FW need not to wake up host on disconnection and still can connect and recover .
I am new in Linux and i want to know the internals of drivers and how it is interacting with hardware, so my question is that How the application is interacting with hardware means when the core part will come in picture and what it will do?
When the controller of that driver will come and how it will handle the request generated by the application.
And what is Firmware and when it comes into picture in Linux?
For eg: if i am using usb device like
$ cat /dev/usb0.1
then which is the core of usb(usb_storage.c) and
which is the controller(usb_hub.c)
and how they are related to each other.
Thanks in advance..
Basically linux kernel driver provide interface such as device file node then application can use standard read()/write()/ioctl() to pass parameter to operate hardware. Provide interface in /proc or /sys can be facilities to do that too. Detail implementation how to handle request depends on respective hardware spec.