Problems with printk logs and my driver

Problems with printk logs and my driver

[Eric Curtin]

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:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        32
  idVendor           0x04ca Lite-On Technology Corp.
  idProduct          0x008d
  bcdDevice            0.39
  iManufacturer           1 Lite-On Technology Corp.
  iProduct                2 HP Wireless Keyboard Kit
--
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      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-kernel@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_urb(kbd->led);
    usb_free_coherent(dev, 8, kbd->new, kbd->new_dma);
@@ -274,6 +281,7 @@ static void usb_kbd_free_mem(struct usb_device
*dev, struct usb_kbd *kbd)
 static int usb_kbd_probe(struct usb_interface *iface,
             const struct usb_device_id *id)
 {
+   printk(KERN_EMERG "usb_kbd_probe");
    struct usb_device *dev = interface_to_usbdev(iface);
    struct usb_host_interface *interface;
    struct usb_endpoint_descriptor *endpoint;
@@ -381,6 +389,7 @@ fail1:

 static void usb_kbd_disconnect(struct usb_interface *intf)
 {
+   printk(KERN_EMERG "usb_kbd_disconnect");
    struct usb_kbd *kbd = usb_get_intfdata (intf);

    usb_set_intfdata(intf, NULL);

Re: Problems with printk logs and my driver

[Alan Stern]

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-kernel@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

Re: Problems with printk logs and my driver

[Jiri Kosina]

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

Re: Problems with printk logs and my driver

[Alan Stern]

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

Re: Problems with printk logs and my driver

[Felipe Tonello]

On Thu, Sep 24, 2015 at 9:51 PM, Alan Stern <stern@rowland.harvard.edu> 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

Re: Problems with printk logs and my driver

[Jiri Kosina]

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

Re: Problems with printk logs and my driver

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

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'.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: Problems with printk logs and my driver

[Eric Curtin]

On 25 September 2015 at 16:45, Austin S Hemmelgarn <ahferroin7@gmail.com> 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.

Re: Problems with printk logs and my driver

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 4387 bytes --]

On 2015-09-29 18:11, Eric Curtin wrote:
> On 25 September 2015 at 16:45, Austin S Hemmelgarn <ahferroin7@gmail.com> 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).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: Problems with printk logs and my driver

[Eric Curtin]

On 30 September 2015 at 13:07, Austin S Hemmelgarn <ahferroin7@gmail.com> wrote:
> On 2015-09-29 18:11, Eric Curtin wrote:
>>
>> On 25 September 2015 at 16:45, Austin S Hemmelgarn <ahferroin7@gmail.com>
>> 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
@@ -827,9 +827,9 @@
 #define USB_DEVICE_ID_SAITEK_RAT7      0x0cd7
 #define USB_DEVICE_ID_SAITEK_MMO7      0x0cd0

-#define USB_VENDOR_ID_SAMSUNG          0x0419
+#define USB_VENDOR_ID_SAMSUNG          0x04ca
 #define USB_DEVICE_ID_SAMSUNG_IR_REMOTE        0x0001
-#define USB_DEVICE_ID_SAMSUNG_WIRELESS_KBD_MOUSE       0x0600
+#define USB_DEVICE_ID_SAMSUNG_WIRELESS_KBD_MOUSE       0x008d

 #define USB_VENDOR_ID_SEMICO                   0x1a2c
 #define USB_DEVICE_ID_SEMICO_USB_KEYKOARD      0x0023

Re: Problems with printk logs and my driver

[Alan Stern]

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

Re: Problems with printk logs and my driver

[Eric Curtin]

On 4 October 2015 at 16:28, Alan Stern <stern@rowland.harvard.edu> 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.