I have a kortek touch screen hardware with the following info:
VendorId = 2965
ProductId = 5023
This hardware is driven by hid-multitouch driver by default.
I do not require multitouch functionality as of now.
I want to use the hardware in single touch mode and therefore want to use hid-generic driver.
To stop hid-multitouch from driving this touch screen hardware I commented out the following lines in linux kernel driver code drivers/hid/hid-multitouch.c
/* Generic MT device */
//{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH, HID_ANY_ID, HID_ANY_ID) },
Since the Kortek hardware entry was not specifically listed in this device table so I disabled the driver for generic devices by commenting out the generic device entry.
But this does not work and hid-multitouch still grabs the hardware.
I would like to know what changes do I need to make to disable 'hid-multitouch driver from grabbing this hardware.
Related
I am prototyping a keyboard using a Pi Zero, and I plan to set the Pi Zero up so that it emulates an HID-compliant USB keyboard (for Windows). There are many guides on how to do this, so I do not think this will be an issue. The additional functionality of this keyboard is going to require the ability to configure certain aspects keyboard on the host machine and send those configurations back up to the device.
My understanding is that once I have the pi zero emulating an HID keyboard, I will not have to do any extra work with Windows to get the host to accept the new keyboard device - it will automatically recognize the HID device and use the correct built-in driver. The configuration bit, however, I will have to work on myself. I was planning on writing a Win32 application that calls WinUSB as the other driver that handles transfer for the configurations.
On the MSDN page for selecting a USB driver model, it states that WinUSB is a good option if:
Your device is accessed by a single application.
The question stands thusly:
Does having my device configured as an HID keyboard prohibit me from being able to use WinUSB as a configuration driver? More specifically, does having my keyboard constantly open in an HID filter driver (I believe the HID host is a filter driver) count as the device being used in one application already, where the configuration application would be a second?
I believe this answers my question.
https://social.msdn.microsoft.com/Forums/en-US/9687e8ba-9eb0-4d41-a8ac-973a029e05b2/winusb-sample-to-read-inputs-from-keyboard
only one driver can be installed on the device, either HID or winusb. you could force winusb onto the keyboard but then it would stop looking like a keyboard to the OS.
Ignoring the irking lack of capitalization in this post, this seems to state pretty conclusively that a separate driver needs to be written. How unfortunate.
I have a Freescale imx.6q (arm) based board.
Hardware is configured with devicetree.
It had a change major incompatible change to timings and voltage for an onboard fpga, but these changes are invisible to the kernel.
The EE's tell us we shouldn't load the old fpga firmware for fear of damaging it. I would like to support both hardware from the same code (It is already causing confusion)
The solution I have thought of is this:
There are several new spi temperature sensors on the board. If I can read from one of those devices, I can infer that I need the new firmware.
How can I (in one driver) grab an spi device and then release it?
I suspect that I might be able to do something like this with device tree,
But I don't want to make the device unavailable.
Any ideas or examples of something like this being done?
After reading question i think your concern is how to add software support for more than one hardware.
If that is the case i think we can write two drivers supporting both hardware's with different configuration such as irq, voltage, register set etc.
So i will enable both drivers in Makefile and config file.
So at the time of boot when probe of drivers gets called we can check the hardware id by using spi_read command from driver.
If hardware id matches then driver probe gets successful and driver can be used to interact with hardware.
If spi_read fails then driver probe itself will fail.
I think this will do the trick.
EDIT (answer the question)
To detect use an SPI device from another driver use a reference to the device in the devicetree structure.
Short answer: add a reference to the spi device in your devices dts entry.
Slightly longer answer:
When adding spi to another device driver, you are effectively adding a subdevice, which may want its own driver. I have an FPGA which loads its firmware over (something close enough to be considered) SPI. I started with the idea of just treating the spi device as part of the larger driver, but the more work went into it, the more obvious it was that it is its own device, with a purpose and function that is distinct from the rest of the driver. I separated that code into its own driver.
Now instead of a reference to an SPI device, my driver just has a reference to an FPGA Manager device.
See line 98, 370 of https://github.com/d4ddi0/linux/blob/v4.12evi/arch/arm/boot/dts/imx6q-evi.dts
and
make sure the spi driver is loaded before your driver completes loading
My original answer to my question (for historical purposes):
What I ended up doing was using different devicetree files. The difference is know at initial install time (based on the serial number). The bootloader knows which dts filename to load.
There are multiple FPGA firmware versions and the right one is chosen based on the description in the dts.
This way, I can still update the driver and/or dts without breakage.
This works well in practice even though it does not detect anything at runtime.
One problem still exists, if I take an SD card from a new revision, and put it into an old one, the incorrect firmware will be loaded. To really solve this last problem, we've talked about adding an EEPROM to uniquely identify the hardware revision on future boards.
I have a driver designed in Storport-miniport model. I'm trying to modify the driver to support SATA legacy mode. Here are some questions which I am looking for help:
the I/O Address
In Native mode, the IO address is shown in BAR0 to BAR3. But in legacy mode, the IO address is fixed(0x1f0 for command, 0x3f6 for control in channel-0). In native mode, we used StorPortGetDeviceBase to get the memory-map of the IO address, but it doesn't work with legacy mode since Storport could only handle the IO space announced in PCI space. Therefore, I tried to use MmMapIoSpace to allocate memories. Is this a correct way?
The IRQ
Just like IO Address, IRQ is fix for legacy mode. But the whole thing about IRQ is done by Storport, should I or could I do anything here?
the HwStorInitialize does not called
MSDN says HwStorInitialize should be called if HwStorFindAdapter return true. But in my driver with legacy mode, the HwStorInitialize does not called so the adapter in device manager shows not ready with yellow mark. Did I miss something?
ATAport-minoport
When I was trying to figure out those problems, I found there's another driver mode called ATAport-miniport. Does this mean I should design my driver in the model if my adapter is in legacy mode? Is it possible to implement legacy mode in the same driver as native mode by Storport-miniport?
I'm working on a project where I have a management system that exports PCIe hardware devices to other systems via PCI Express. I have a working management kernel module but need to find a way to ensure that a device I export doesn't have a driver already loaded for it on the management system. Without that, the device will end up with conflicts since the same driver will be accessing it from 2 different systems & obviously cause problems.
For example, assume I have a dual-port Intel 100MBps NIC device installed on the Manager which will show up 2 PCIe Endpoints in the system (eg Fn 0 & 1). The Intel module e1000 will be loaded for both devices. If I want to export port 2 of that device to another system, I would like to "detach" it from the e1000 module.
Does anyone know a clean way of doing this without hacking the kernel or tweaking the e1000's driver's probe function? I can't simply do an rmmod because that will remove the module all-together for both NIC devices. I would like the NIC I'm not exporting to remain functional in the Management system with the e1000 driver still loaded for it.
Essentially, rmmod does this but will remove the driver for all devices probed for & owned by the driver. Any way to tell Linux just "unload module for only this specific device"? On Windows, I guess this would be the equivalent of right-clicking on a device in Device Manager & select "Disable".
You can disable driver for your device by writting following method:
Use sudo -i or before any command write sudo to operate as root user.And follow below procedure:
Goto /sys/bus/pci/<driver_name>/ folder.
Give command echo -n 0000:03:00.1 > unbind
Where 0000:03:00.1 is device you want to detech your driver.
Read this link for getting idea about sysfs for pci bus.
The mechanism responsible for device/driver pairing in Linux driver model is called "bus" (usually controlled through entries in /sys/bus). The problem is, the particular bus driver your device is attached to must support this sort of action (and it is far from trivial supporting this functionality in general case).
Specifically for PCI, if you've got "pci hotplug" enabled, you will be able to kick devices off pci bus by writing numbers to corresponding "hotplug" entries in /sys/bus/pci (you can also reconnect them back by triggering the bus rescan). The problems will start later, as you will have to somehow convince the Linux device subsystem to prefer your driver over the one already registered for the device id in question.
Normally registered drivers are added to some sort of list and then tried out one by one to see if either of them is listing the new or re-enabled device in their "*_device_id" tables. If PCI subsystem prefers to try drivers in "first registered, first tried" order you will have to hack it to achieve your goal.
To unbind a PCI driver from a device, use the unbind file of the driver in sysfs.
From Documentation/ABI/testing/sysfs-bus-pci:
/sys/bus/pci/drivers/.../unbind
Description:
Writing a device location to this file will cause the
driver to attempt to unbind from the device found at
this location. This may be useful when overriding default
bindings. The format for the location is: DDDD:BB:DD.F.
That is Domain:Bus:Device.Function and is the same as
found in /sys/bus/pci/devices/. For example:
# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
you can disable a particular pci device by resetting enable value for the corresponding device
Eg:
echo 0 > /sys/bus/pci/devices/0000:00:1a.2/enable
I wonder if anyone can help at all, a bit of a specialist problem this.
I have an application that needs to read and analyse a number of USB devices (not simultaneously, they are each run in seperate tests and could in theory be run on different machines).
Each of the USB devices is based on the USB HID class, and are manufactured by different companies, none of these USB devices are designed to be run on PC, but are meant for a different platform, however for the purposes of testing the devices the client has requested that the test application is run from a PC.
Some of the devices will start up, be recognised by windows which will initialise and start them correctly using the generic HID class driver built into windows, the devices will then start sending correct data packets of the data to be tested.
Some of the devices will start up, be recognised by windows which will try to start them but fail to fully to initialise them leaving them in a half initialised state. This is fine, as I can use my beagle protocol analyser to capture the initialisation packets from the genuine platform and then use the LibUSBDotNet library to replicate the remaining packets in the initialisation sequence and get them to start sending the packets correctly.
The problem I have is with one particular device (though there are some more I haven't tested yet so it's quite possible one of those may also exhibit the same problem). The issue is the the Windows HID class driver recognises the device and trys to initialise and start it, this works after a fashion and the device starts sending data.
The problem is that the data being sent is different to that which is sent to the genuine platform (containing only a subset of the full data). It's as though windows has initialised the device into a different mode.
When I capture the initialisation packets from both the PC and the genuine platform using my USB protocol analyser I see that Windows is sending some slightly different initialisation packets. Using LibUSBDotNet to resend the correct packets once Windows has already started the device seems to have no effect.
My problem is that I need to stop windows from trying to initialise the device using the standard HID class driver, I've tried removing the driver in Device Manager but it still initialises it (and the driver is magically reassigned in device manager). I've done some investigation and there are possible alternatives:
Create a specific driver which windows will assign to the particular VID/PID of the device but that does nothing, then I can use LibUSBDotNet to send the correct initialisation sequence to the device from within my own code.
Use something like WinUSB to create a proper driver for the device (or possibly to create a "dead" driver like 1.
Will a driver with a specific VID/PID defined be used by windows in preference to it's inbuilt USB HID class driver? If not then I would be wasting my time going down this route?
Note, my mac initialises the problem device correctly, and I've asked the question of the client whether the application can be developed for Mac and their answer was frustrating Windows only.
I've no experience in writing proper Windows drivers, though I have experience in talking to USB at a relatively low level (so that part doesn't worry too much). Can anyone suggest a good course of action (before I potentially waste weeks investigating how to write drivers for the PC only to find my selected course of action can't deliver what I required).
Any help or suggest much appreciated.
Thanks,
Rich
Added after trying suggestions below:
I tried using the LibUsbDotNet inf wizard to create the necessary files and install them and this appeared to work - certainly the device was now appearing in Device Manager as a libusb-win32 device - not HID device and the associated driver was libusb driver. Even after doing this the device still seems to become initialised and start sending the wrong type of data packets although now those packets are no longer handled by the class driver and are just lost.
I also came across Zadig which has a similar inf creation wizard for WinUSB and this had exactly the same result.
A colleague has suggested that it might not be windows itself that is switching the device into this mode, rather the device identifying that it is connected to a windows machine and switching itself into this mode. I suspect this is the case, in which case I am stuck - time to have another conversation with the client.
Many thanks for the help.
You're using libusb-win32 as a filter driver; that is, the HidUsb device driver is assigned and loaded for your device, but then the libusb-win32 driver is loaded on top and gives you unobstructed access to the hardware.
If you don't want a HidUsb (or any other class driver) to perform any communication "on your behalf", simply associate libusb-win32 as a device driver with your hardware. For this, you'd have to create an .INF file associating it with the VID/PID/Revision of each USB device. If I recall correctly, libusb-win32 even comes with a utility to generate such .INF files.
If you install this .INF file e.g. with PnpUtil.exe (available on Vista or higher), you might still run into issues where, although you're a better match than the generic HID driver, the HID driver is still selected.
The generic HID driver matches devices by their Compatible IDs (i.e. by a USB interface class) while you'd be matching by Hardware IDs (which have higher priority). However, Windows might give priority to other aspects, such as your driver being unsigned. Read: How Windows Selects Drivers
Luckily, even in that scenario, signing drivers with a self-generated certificate (use CertUtil.exe, MakeCat.exe and SignTool.exe) is not too difficult.