Re: Problems with printk logs and my driver

[Eric Curtin]

On 30 September 2015 at 13:07, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> wrote:
> On 2015-09-29 18:11, Eric Curtin wrote:
>>
>> On 25 September 2015 at 16:45, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/