Preventing usbhid from claiming device
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
In order for my USB driver's _probe function to be called, I need to prevent usbhid from claiming it first. To do this I wrote a UDEV rule which unbinds the device.
SUBSYSTEM=="usb", DRIVER=="usbhid", ATTRSidVendor=="ffff",
ATTRSidProduct=="ffff", RUN="/bin/sh -c 'echo -n $id:1.0 >
/sys/bus/usb/drivers/usbhid/unbind'"
While this works, what is the standard practice for distributing drivers? Do I have to also package this rule? Is there any way for my own driver to take priority over usbhid?
linux drivers usb packaging
asked Aug 15 at 1:35
Twifty
1,6791632
migrated from unix.stackexchange.com Aug 15 at 11:44
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
add a comment |Â
up vote
1
down vote
favorite
In order for my USB driver's _probe function to be called, I need to prevent usbhid from claiming it first. To do this I wrote a UDEV rule which unbinds the device.
SUBSYSTEM=="usb", DRIVER=="usbhid", ATTRSidVendor=="ffff",
ATTRSidProduct=="ffff", RUN="/bin/sh -c 'echo -n $id:1.0 >
/sys/bus/usb/drivers/usbhid/unbind'"
While this works, what is the standard practice for distributing drivers? Do I have to also package this rule? Is there any way for my own driver to take priority over usbhid?
linux drivers usb packaging
asked Aug 15 at 1:35
Twifty
1,6791632
migrated from unix.stackexchange.com Aug 15 at 11:44
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
Since this is more of a driver programming question, it might be better placed on Stack Overflow, or in a hardware_development.SE if one exists.
– telcoM
Aug 15 at 7:26
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
In order for my USB driver's _probe function to be called, I need to prevent usbhid from claiming it first. To do this I wrote a UDEV rule which unbinds the device.
SUBSYSTEM=="usb", DRIVER=="usbhid", ATTRSidVendor=="ffff",
ATTRSidProduct=="ffff", RUN="/bin/sh -c 'echo -n $id:1.0 >
/sys/bus/usb/drivers/usbhid/unbind'"
While this works, what is the standard practice for distributing drivers? Do I have to also package this rule? Is there any way for my own driver to take priority over usbhid?
linux drivers usb packaging
asked Aug 15 at 1:35
Twifty
1,6791632
In order for my USB driver's _probe function to be called, I need to prevent usbhid from claiming it first. To do this I wrote a UDEV rule which unbinds the device.
SUBSYSTEM=="usb", DRIVER=="usbhid", ATTRSidVendor=="ffff",
ATTRSidProduct=="ffff", RUN="/bin/sh -c 'echo -n $id:1.0 >
/sys/bus/usb/drivers/usbhid/unbind'"
While this works, what is the standard practice for distributing drivers? Do I have to also package this rule? Is there any way for my own driver to take priority over usbhid?
linux drivers usb packaging
linux drivers usb packaging
asked Aug 15 at 1:35
Twifty
1,6791632
asked Aug 15 at 1:35
Twifty
1,6791632
asked Aug 15 at 1:35
Twifty
1,6791632
asked Aug 15 at 1:35
Twifty
1,6791632
asked Aug 15 at 1:35
Twifty
1,6791632
1,6791632
migrated from unix.stackexchange.com Aug 15 at 11:44
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
migrated from unix.stackexchange.com Aug 15 at 11:44
This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
Since this is more of a driver programming question, it might be better placed on Stack Overflow, or in a hardware_development.SE if one exists.
– telcoM
Aug 15 at 7:26
add a comment |Â
Since this is more of a driver programming question, it might be better placed on Stack Overflow, or in a hardware_development.SE if one exists.
– telcoM
Aug 15 at 7:26
Since this is more of a driver programming question, it might be better placed on Stack Overflow, or in a hardware_development.SE if one exists.
– telcoM
Aug 15 at 7:26
Since this is more of a driver programming question, it might be better placed on Stack Overflow, or in a hardware_development.SE if one exists.
– telcoM
Aug 15 at 7:26
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
The kernel selects the drivers for each device based on the MODULE_DEVICE_TABLEs. The HID device table is considered more specific than the generic USB device table, so if your device claims USB HID device class, then your driver should probably include a HID class MODULE_DEVICE_TABLE too.
The matching algorithm favors specific matches over generic class-based ones, so if your device table entry includes some USB or HID device attributes unique to it, your driver should get priority over the generic usbhid driver.
If your idVendor and idProduct identifiers are actually both 0xffff, then I guess you're dealing with a prototype device that does not yet have proper USB vendor/device identifiers. You'll want to fix that.
answered Aug 15 at 7:23
telcoM
1544
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
Have you rundepmodafter installing your module? It updates the/lib/modules/<kernel_version>/modules.*files that are used in module loading decisions.
– telcoM
Aug 15 at 11:06
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
depmoddidn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.
– Twifty
Aug 15 at 11:24
Thinking about this a little more, theinsmodcommand need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.
– Twifty
Aug 15 at 11:43
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The kernel selects the drivers for each device based on the MODULE_DEVICE_TABLEs. The HID device table is considered more specific than the generic USB device table, so if your device claims USB HID device class, then your driver should probably include a HID class MODULE_DEVICE_TABLE too.
The matching algorithm favors specific matches over generic class-based ones, so if your device table entry includes some USB or HID device attributes unique to it, your driver should get priority over the generic usbhid driver.
If your idVendor and idProduct identifiers are actually both 0xffff, then I guess you're dealing with a prototype device that does not yet have proper USB vendor/device identifiers. You'll want to fix that.
answered Aug 15 at 7:23
telcoM
1544
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
Have you rundepmodafter installing your module? It updates the/lib/modules/<kernel_version>/modules.*files that are used in module loading decisions.
– telcoM
Aug 15 at 11:06
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
depmoddidn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.
– Twifty
Aug 15 at 11:24
Thinking about this a little more, theinsmodcommand need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.
– Twifty
Aug 15 at 11:43
add a comment |Â
up vote
0
down vote
The kernel selects the drivers for each device based on the MODULE_DEVICE_TABLEs. The HID device table is considered more specific than the generic USB device table, so if your device claims USB HID device class, then your driver should probably include a HID class MODULE_DEVICE_TABLE too.
The matching algorithm favors specific matches over generic class-based ones, so if your device table entry includes some USB or HID device attributes unique to it, your driver should get priority over the generic usbhid driver.
If your idVendor and idProduct identifiers are actually both 0xffff, then I guess you're dealing with a prototype device that does not yet have proper USB vendor/device identifiers. You'll want to fix that.
answered Aug 15 at 7:23
telcoM
1544
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
Have you rundepmodafter installing your module? It updates the/lib/modules/<kernel_version>/modules.*files that are used in module loading decisions.
– telcoM
Aug 15 at 11:06
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
depmoddidn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.
– Twifty
Aug 15 at 11:24
Thinking about this a little more, theinsmodcommand need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.
– Twifty
Aug 15 at 11:43
add a comment |Â
up vote
0
down vote
up vote
0
down vote
The kernel selects the drivers for each device based on the MODULE_DEVICE_TABLEs. The HID device table is considered more specific than the generic USB device table, so if your device claims USB HID device class, then your driver should probably include a HID class MODULE_DEVICE_TABLE too.
The matching algorithm favors specific matches over generic class-based ones, so if your device table entry includes some USB or HID device attributes unique to it, your driver should get priority over the generic usbhid driver.
If your idVendor and idProduct identifiers are actually both 0xffff, then I guess you're dealing with a prototype device that does not yet have proper USB vendor/device identifiers. You'll want to fix that.
answered Aug 15 at 7:23
telcoM
1544
The kernel selects the drivers for each device based on the MODULE_DEVICE_TABLEs. The HID device table is considered more specific than the generic USB device table, so if your device claims USB HID device class, then your driver should probably include a HID class MODULE_DEVICE_TABLE too.
The matching algorithm favors specific matches over generic class-based ones, so if your device table entry includes some USB or HID device attributes unique to it, your driver should get priority over the generic usbhid driver.
If your idVendor and idProduct identifiers are actually both 0xffff, then I guess you're dealing with a prototype device that does not yet have proper USB vendor/device identifiers. You'll want to fix that.
answered Aug 15 at 7:23
telcoM
1544
answered Aug 15 at 7:23
telcoM
1544
answered Aug 15 at 7:23
telcoM
1544
answered Aug 15 at 7:23
telcoM
1544
1544
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
Have you rundepmodafter installing your module? It updates the/lib/modules/<kernel_version>/modules.*files that are used in module loading decisions.
– telcoM
Aug 15 at 11:06
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
depmoddidn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.
– Twifty
Aug 15 at 11:24
Thinking about this a little more, theinsmodcommand need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.
– Twifty
Aug 15 at 11:43
add a comment |Â
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
Have you rundepmodafter installing your module? It updates the/lib/modules/<kernel_version>/modules.*files that are used in module loading decisions.
– telcoM
Aug 15 at 11:06
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
depmoddidn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.
– Twifty
Aug 15 at 11:24
Thinking about this a little more, theinsmodcommand need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.
– Twifty
Aug 15 at 11:43
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
I've found that to not be the case. My driver specifies the correct, not 0xffff, IDs in the table, but usbhid always grabs it first. I wonder if this is because the driver is not part of the tree (I see a tainted kernel) message in dmesg.
– Twifty
Aug 15 at 10:59
Have you run
depmod after installing your module? It updates the /lib/modules/<kernel_version>/modules.* files that are used in module loading decisions.– telcoM
Aug 15 at 11:06
Have you run
depmod after installing your module? It updates the /lib/modules/<kernel_version>/modules.* files that are used in module loading decisions.– telcoM
Aug 15 at 11:06
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
No I didn't, I'll give that a try.
– Twifty
Aug 15 at 11:10
depmod didn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.– Twifty
Aug 15 at 11:24
depmod didn't make a difference :( I'll try to find the source code for similar drivers (probably my logitech unifying receiver) and see if there any fundamental differences.– Twifty
Aug 15 at 11:24
Thinking about this a little more, the
insmod command need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.– Twifty
Aug 15 at 11:43
Thinking about this a little more, the
insmod command need only be issued when opening my GUI. I could add some logic before that call to detect the device and unbind manually. There wouldn't be a need for the udev rule.– Twifty
Aug 15 at 11:43
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f51858074%2fpreventing-usbhid-from-claiming-device%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Since this is more of a driver programming question, it might be better placed on Stack Overflow, or in a hardware_development.SE if one exists.
– telcoM
Aug 15 at 7:26