Re: Problems with printk logs and my driver
On 4 October 2015 at 16:28, Alan Stern wrote: > On Sun, 4 Oct 2015, Eric Curtin wrote: > >> Ok so for the fun of it, I changed the VENDOR_ID and DEVICE_ID of my >> keyboard to use the driver for this samsung Wireless keyboard and >> mouse, crazy I know since I have a different piece of hardware, but I >> wanted to see what happens or at least does it change driver. When I >> reboot to this kernel, my keyboard still uses the usbhid driver. Why >> does this happen? > > Because the Samsung wireless keyboard and mouse also use the usbhid > driver. Besides, the choice of driver depends just as much on the > bInterfaceClass, -Subclass, and -Protocol as on the vendor and product > IDs. > > Basically, nothing needs to use usbkbd. Anything that driver can > handle will also work with usbhid. The only reason for keeping usbkbd > as a separate driver is because it is smaller than usbhid, so it's > better suited to some embedded applications with limited memory. > > Alan Stern > After looking at this again today, I cannot reproduce the problem anymore. I took out the battery on this keyboard and put it back in and the issue is now not reproducible. Pity, I was hoping to get to the bottom of this one. It works in X but not in console mode. I tried another one and it had the same result, it's a more standard usb keyboard. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On Sun, 4 Oct 2015, Eric Curtin wrote: > Ok so for the fun of it, I changed the VENDOR_ID and DEVICE_ID of my > keyboard to use the driver for this samsung Wireless keyboard and > mouse, crazy I know since I have a different piece of hardware, but I > wanted to see what happens or at least does it change driver. When I > reboot to this kernel, my keyboard still uses the usbhid driver. Why > does this happen? Because the Samsung wireless keyboard and mouse also use the usbhid driver. Besides, the choice of driver depends just as much on the bInterfaceClass, -Subclass, and -Protocol as on the vendor and product IDs. Basically, nothing needs to use usbkbd. Anything that driver can handle will also work with usbhid. The only reason for keeping usbkbd as a separate driver is because it is smaller than usbhid, so it's better suited to some embedded applications with limited memory. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On 30 September 2015 at 13:07, Austin S Hemmelgarn wrote: > On 2015-09-29 18:11, Eric Curtin wrote: >> >> On 25 September 2015 at 16:45, Austin S Hemmelgarn >> wrote: >>> >>> On 2015-09-25 08:02, Jiri Kosina wrote: On Fri, 25 Sep 2015, Felipe Tonello wrote: > Maybe a better description on Kconfig and/or comments on source code > it's enough. I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless. >>> For some reason there seem to be a lot of people who go to configure >>> there >>> own kernel and don't read the help text (I understand if you've been >>> building your own Linux kernel's for years and actually understand what a >>> Kconfig option is really asking, but most people who I've heard of doing >>> this have never built a kernel before in their life). >>> >>> On the other hand, can anyone think of any real reason to use this >>> outside >>> of embedded systems? I know there are a lot of distros that build this >>> and >>> the USB HIDBP mouse support as modules, but I have yet to hear/find any >>> reports of hardware that _only_ works with this driver and not the >>> generic >>> HID driver. If this is the case, it might make sense to make this depend >>> on >>> EXPERT or at least remove the bit about 'simple keyboards'. >>> >> >> As regards renaming usbkbd.c, @Austin there are some reasons why you would >> not read the Kconfig. As a beginner, I didn't even configure this part or >> read the help text as I used the configuration that comes with Fedora, I >> don't know if that's a valid excuse or not though. I'll leave you guys >> decide, you're the experts! >> >> As regards the issue with my capslock led I'm still looking into it. >> > Personally, I would not ever advocate not reading the help text for an > option (although in some cases it's pretty un-helpful, especially for some > staging drivers). > > Your case is one of the common ones, and it's not a bad place to start, but > you have to keep in mind that most distro's turn on a huge amount of stuff > that more than 90% of people aren't ever going to need (for example, I'm > pretty sure Ubuntu still builds a module for SLIP, which has been an > essentially dead technology for more than a decade now). For anyone starting > from a distro's kconfig, I'd suggest at least: > a. Turn off CONFIG_EXPERT unless you intend to actually try and understand > the options it enables (most distro's turn this on for some of the fine > tuning features it enables, most regular people don't actually need it). > b. Go through using menuconfig, and turn off stuff under the drivers menu > that you know you will never need (and take the time to use stuff like lspci > and lsusb to figure out what actually need). > c. Read the help text before trying to change anything, and if you don't > understand it after that, look it up online, and even then be careful > changing it. > d. If you intend on actually using it with a particular distro, don't turn > off too much outside of the drivers menu, other stuff can cause things to > fail in unusual ways, and you often won't get a great amount of help from > the distro maintainers when using a custom kernel. > > The real problem is when people just read the option name and think they > understand it when they don't really (or just don't think about the > implications), and then wonder why something stops working suddenly (like > one guy I know who was building a kernel for a server, and thought he could > just disable everything under the 'Graphics' menu, then wondered why he > didn't get console output on his monitor). > Ok so for the fun of it, I changed the VENDOR_ID and DEVICE_ID of my keyboard to use the driver for this samsung Wireless keyboard and mouse, crazy I know since I have a different piece of hardware, but I wanted to see what happens or at least does it change driver. When I reboot to this kernel, my keyboard still uses the usbhid driver. Why does this happen? diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index f769208..350a6f8 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @
Re: Problems with printk logs and my driver
On 2015-09-29 18:11, Eric Curtin wrote: On 25 September 2015 at 16:45, Austin S Hemmelgarn wrote: On 2015-09-25 08:02, Jiri Kosina wrote: On Fri, 25 Sep 2015, Felipe Tonello wrote: Maybe a better description on Kconfig and/or comments on source code it's enough. I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless. For some reason there seem to be a lot of people who go to configure there own kernel and don't read the help text (I understand if you've been building your own Linux kernel's for years and actually understand what a Kconfig option is really asking, but most people who I've heard of doing this have never built a kernel before in their life). On the other hand, can anyone think of any real reason to use this outside of embedded systems? I know there are a lot of distros that build this and the USB HIDBP mouse support as modules, but I have yet to hear/find any reports of hardware that _only_ works with this driver and not the generic HID driver. If this is the case, it might make sense to make this depend on EXPERT or at least remove the bit about 'simple keyboards'. As regards renaming usbkbd.c, @Austin there are some reasons why you would not read the Kconfig. As a beginner, I didn't even configure this part or read the help text as I used the configuration that comes with Fedora, I don't know if that's a valid excuse or not though. I'll leave you guys decide, you're the experts! As regards the issue with my capslock led I'm still looking into it. Personally, I would not ever advocate not reading the help text for an option (although in some cases it's pretty un-helpful, especially for some staging drivers). Your case is one of the common ones, and it's not a bad place to start, but you have to keep in mind that most distro's turn on a huge amount of stuff that more than 90% of people aren't ever going to need (for example, I'm pretty sure Ubuntu still builds a module for SLIP, which has been an essentially dead technology for more than a decade now). For anyone starting from a distro's kconfig, I'd suggest at least: a. Turn off CONFIG_EXPERT unless you intend to actually try and understand the options it enables (most distro's turn this on for some of the fine tuning features it enables, most regular people don't actually need it). b. Go through using menuconfig, and turn off stuff under the drivers menu that you know you will never need (and take the time to use stuff like lspci and lsusb to figure out what actually need). c. Read the help text before trying to change anything, and if you don't understand it after that, look it up online, and even then be careful changing it. d. If you intend on actually using it with a particular distro, don't turn off too much outside of the drivers menu, other stuff can cause things to fail in unusual ways, and you often won't get a great amount of help from the distro maintainers when using a custom kernel. The real problem is when people just read the option name and think they understand it when they don't really (or just don't think about the implications), and then wonder why something stops working suddenly (like one guy I know who was building a kernel for a server, and thought he could just disable everything under the 'Graphics' menu, then wondered why he didn't get console output on his monitor). smime.p7s Description: S/MIME Cryptographic Signature
Re: Problems with printk logs and my driver
On 25 September 2015 at 16:45, Austin S Hemmelgarn wrote: > On 2015-09-25 08:02, Jiri Kosina wrote: >> >> On Fri, 25 Sep 2015, Felipe Tonello wrote: >> >>> Maybe a better description on Kconfig and/or comments on source code >>> it's enough. >> >> >> I personally find the current Kconfig description: >> >> === >> config USB_KBD >> tristate "USB HIDBP Keyboard (simple Boot) support" >> depends on USB && INPUT >> ---help--- >>Say Y here only if you are absolutely sure that you don't want >>to use the generic HID driver for your USB keyboard and prefer >>to use the keyboard in its limited Boot Protocol mode instead. >> >>This is almost certainly not what you want. This is mostly >>useful for embedded applications or simple keyboards. >> >>To compile this driver as a module, choose M here: the >>module will be called usbkbd. >> >>If even remotely unsure, say N. >> === >> >> shouldn't leave anyone dounting, but people are getting confused again and >> again nevertheless. >> > For some reason there seem to be a lot of people who go to configure there > own kernel and don't read the help text (I understand if you've been > building your own Linux kernel's for years and actually understand what a > Kconfig option is really asking, but most people who I've heard of doing > this have never built a kernel before in their life). > > On the other hand, can anyone think of any real reason to use this outside > of embedded systems? I know there are a lot of distros that build this and > the USB HIDBP mouse support as modules, but I have yet to hear/find any > reports of hardware that _only_ works with this driver and not the generic > HID driver. If this is the case, it might make sense to make this depend on > EXPERT or at least remove the bit about 'simple keyboards'. > As regards renaming usbkbd.c, @Austin there are some reasons why you would not read the Kconfig. As a beginner, I didn't even configure this part or read the help text as I used the configuration that comes with Fedora, I don't know if that's a valid excuse or not though. I'll leave you guys decide, you're the experts! As regards the issue with my capslock led I'm still looking into it. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On 2015-09-25 08:02, Jiri Kosina wrote: On Fri, 25 Sep 2015, Felipe Tonello wrote: Maybe a better description on Kconfig and/or comments on source code it's enough. I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless. For some reason there seem to be a lot of people who go to configure there own kernel and don't read the help text (I understand if you've been building your own Linux kernel's for years and actually understand what a Kconfig option is really asking, but most people who I've heard of doing this have never built a kernel before in their life). On the other hand, can anyone think of any real reason to use this outside of embedded systems? I know there are a lot of distros that build this and the USB HIDBP mouse support as modules, but I have yet to hear/find any reports of hardware that _only_ works with this driver and not the generic HID driver. If this is the case, it might make sense to make this depend on EXPERT or at least remove the bit about 'simple keyboards'. smime.p7s Description: S/MIME Cryptographic Signature
Re: Problems with printk logs and my driver
On Fri, 25 Sep 2015, Felipe Tonello wrote: > Maybe a better description on Kconfig and/or comments on source code > it's enough. I personally find the current Kconfig description: === config USB_KBD tristate "USB HIDBP Keyboard (simple Boot) support" depends on USB && INPUT ---help--- Say Y here only if you are absolutely sure that you don't want to use the generic HID driver for your USB keyboard and prefer to use the keyboard in its limited Boot Protocol mode instead. This is almost certainly not what you want. This is mostly useful for embedded applications or simple keyboards. To compile this driver as a module, choose M here: the module will be called usbkbd. If even remotely unsure, say N. === shouldn't leave anyone dounting, but people are getting confused again and again nevertheless. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On Thu, Sep 24, 2015 at 9:51 PM, Alan Stern wrote: > On Thu, 24 Sep 2015, Jiri Kosina wrote: > >> On Wed, 23 Sep 2015, Alan Stern wrote: >> >> > Your mistake was thinking that the driver for your keyboard is usbkbd. >> > It isn't. It's usbhid, as you can see in the "lsusb -t" output above. >> >> As Eric is absolutely not the first person ever who got confused by this >> (and I can certainly understand the reasons for this confusion), I've been >> thinking for quite some time already about renaming this driver (and >> usbmouse as well). We'd probably want to make obvious from the name that >> this isn't regular usb keyboard driver. >> >> Any opinions on usbkbd-simple or usbkbd-dummy? The most accurate would of >> course be usbkbd-boot, but that might be equally confusing. > > I prefer -simple over -dummy. Even better would be usbkbd-alt. > >> The drawback I can see in renaming the driver is various embedded folks >> having he name hardcoded in their scripts. > > Yes, that's a real problem. Similar considerations apply to .config > files, if you also change the Kconfig symbol name. Maybe a better description on Kconfig and/or comments on source code it's enough. Because breaking that compatibility just because of a name doesn't sound really appealing. I had previously denied patches for breaking compatibility by making things correct. Felipe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On Thu, 24 Sep 2015, Jiri Kosina wrote: > On Wed, 23 Sep 2015, Alan Stern wrote: > > > Your mistake was thinking that the driver for your keyboard is usbkbd. > > It isn't. It's usbhid, as you can see in the "lsusb -t" output above. > > As Eric is absolutely not the first person ever who got confused by this > (and I can certainly understand the reasons for this confusion), I've been > thinking for quite some time already about renaming this driver (and > usbmouse as well). We'd probably want to make obvious from the name that > this isn't regular usb keyboard driver. > > Any opinions on usbkbd-simple or usbkbd-dummy? The most accurate would of > course be usbkbd-boot, but that might be equally confusing. I prefer -simple over -dummy. Even better would be usbkbd-alt. > The drawback I can see in renaming the driver is various embedded folks > having he name hardcoded in their scripts. Yes, that's a real problem. Similar considerations apply to .config files, if you also change the Kconfig symbol name. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On Wed, 23 Sep 2015, Alan Stern wrote: > Your mistake was thinking that the driver for your keyboard is usbkbd. > It isn't. It's usbhid, as you can see in the "lsusb -t" output above. As Eric is absolutely not the first person ever who got confused by this (and I can certainly understand the reasons for this confusion), I've been thinking for quite some time already about renaming this driver (and usbmouse as well). We'd probably want to make obvious from the name that this isn't regular usb keyboard driver. Any opinions on usbkbd-simple or usbkbd-dummy? The most accurate would of course be usbkbd-boot, but that might be equally confusing. The drawback I can see in renaming the driver is various embedded folks having he name hardcoded in their scripts. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with printk logs and my driver
On Thu, 24 Sep 2015, Eric Curtin wrote: > Hi Guys, > > Just wondering what I am doing wrong. I can't see my logs. I figured > out what driver is used for my keyboard and started adding logging: > > [curtine@localhost ~]$ sudo lsusb -v | grep eyboard -B 13 > Bus 001 Device 003: ID 04ca:008d Lite-On Technology Corp. ... > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M > |__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M > |__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M > |__ Port 7: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M > |__ Port 7: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M ... > So, first I added a little logging and then some more, but I can't see > any of it (see patch at bottom of email, I used KERN_EMERG, it's just > temporary logging). > > I'm think I'm doing most things right, this is how I compile my code I > wrote a little script (I'm on fedora): ... > I reboot, load new kernel, blah blah. When I type keys I don't see my > logs in dmesg, I don't see them in /var/log/messages either, I don't > see them in /home/curtine/log.log either when I do a: > > sudo killall klogd > sudo /sbin/klogd -f /home/curtine/log.log > > What am I doing wrong here? You made a very simple mistake. See below. > Also, as regards etiquette on these mailing lists, is it ok to > regularly cc linux-ker...@vger.kernel.org? It's okay. But there's no need to do it if your topic is limited to a single subsystem. > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c > index 9a332e6..2038d94 100644 > --- a/drivers/hid/usbhid/usbkbd.c > +++ b/drivers/hid/usbhid/usbkbd.c > @@ -112,6 +112,7 @@ struct usb_kbd { > > static void usb_kbd_irq(struct urb *urb) > { > + printk(KERN_EMERG "usb_kbd_irq"); > struct usb_kbd *kbd = urb->context; > int i; > ... Your mistake was thinking that the driver for your keyboard is usbkbd. It isn't. It's usbhid, as you can see in the "lsusb -t" output above. Even though the source code for usbkbd is located in the usbhid directory, they are separate drivers. Look at the Kconfig file in drivers/hid/usbhid and you'll see. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problems with printk logs and my driver
Hi Guys, Just wondering what I am doing wrong. I can't see my logs. I figured out what driver is used for my keyboard and started adding logging: [curtine@localhost ~]$ sudo lsusb -v | grep eyboard -B 13 Bus 001 Device 003: ID 04ca:008d Lite-On Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize032 idVendor 0x04ca Lite-On Technology Corp. idProduct 0x008d bcdDevice0.39 iManufacturer 1 Lite-On Technology Corp. iProduct2 HP Wireless Keyboard Kit -- iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard [curtine@localhost ~]$ sudo lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M |__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 7: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 7: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 9: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 9: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M So, first I added a little logging and then some more, but I can't see any of it (see patch at bottom of email, I used KERN_EMERG, it's just temporary logging). I'm think I'm doing most things right, this is how I compile my code I wrote a little script (I'm on fedora): #!/bin/sh find /boot -name '*4.3*' | xargs sudo rm -rf find /lib/modules -name '*4.3*' | xargs sudo rm -rf set -e cd $HOME/git/linux # make -j5 oldconfig printf "completed 1\n" make -j5 bzImage printf "completed 2\n" make -j5 modules printf "completed 3\n" sudo make -j5 modules_install printf "completed 4\n" sudo make -j5 install I reboot, load new kernel, blah blah. When I type keys I don't see my logs in dmesg, I don't see them in /var/log/messages either, I don't see them in /home/curtine/log.log either when I do a: sudo killall klogd sudo /sbin/klogd -f /home/curtine/log.log What am I doing wrong here? Also, as regards etiquette on these mailing lists, is it ok to regularly cc linux-ker...@vger.kernel.org? diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c index 9a332e6..2038d94 100644 --- a/drivers/hid/usbhid/usbkbd.c +++ b/drivers/hid/usbhid/usbkbd.c @@ -112,6 +112,7 @@ struct usb_kbd { static void usb_kbd_irq(struct urb *urb) { + printk(KERN_EMERG "usb_kbd_irq"); struct usb_kbd *kbd = urb->context; int i; @@ -166,6 +167,7 @@ resubmit: static int usb_kbd_event(struct input_dev *dev, unsigned int type, unsigned int code, int value) { + printk(KERN_EMERG "usb_kbd_event"); unsigned long flags; struct usb_kbd *kbd = input_get_drvdata(dev); @@ -202,6 +204,7 @@ static int usb_kbd_event(struct input_dev *dev, unsigned int type, static void usb_kbd_led(struct urb *urb) { + printk(KERN_EMERG "usb_kbd_led"); unsigned long flags; struct usb_kbd *kbd = urb->context; @@ -230,6 +233,7 @@ static void usb_kbd_led(struct urb *urb) static int usb_kbd_open(struct input_dev *dev) { + printk(KERN_EMERG "usb_kbd_open"); struct usb_kbd *kbd = input_get_drvdata(dev); kbd->irq->dev = kbd->usbdev; @@ -241,6 +245,7 @@ static int usb_kbd_open(struct input_dev *dev) static void usb_kbd_close(struct input_dev *dev) { + printk(KERN_EMERG "usb_kbd_close"); struct usb_kbd *kbd = input_get_drvdata(dev); usb_kill_urb(kbd->irq); @@ -248,6 +253,7 @@ static void usb_kbd_close(struct input_dev *dev) static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd) { + printk(KERN_EMERG "usb_kbd_alloc_mem"); if (!(kbd->irq = usb_alloc_urb(0, GFP_KERNEL))) return -1; if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL))) @@ -264,6 +270,7 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd) static void usb_kbd_free_mem(struct usb_device *dev, struct usb_kbd *kbd) { + printk(KERN_EMERG "usb_kbd_free_mem"); usb_free_urb(kbd->irq); usb_free