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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
