Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
Hi Jiri, > > For me the task of converting HID reports into input events shouldn't be > > actually the job of the HID core layer. My understanding is that the HID > > core should support multiple transport layers. This is currently > > achieved through the hid_device abstraction and used by the USB and by > > the Bluetooth subsystem. This is the lower interface to HID. On the > > upper interface I like to see a driver like interface. So we can > > register specific drivers that can handle specific use cases or vendor > > specific reports. > > This I completely agree with, and have this on my TODO for quite a long > time. If Li Yu would like to spend some time on it, it certainly would > help. The current "simple HID interrface" is a suitable workaround for > various buggy/broken/nonstandard hardware which is currently not handled > by the HID kernel code properly, but it's definitely not a long-term > solution that should go to mainline. my point is basically that we shouldn't waste any effort on a simple driver while we actually need a generic driver interface. This generic interface might be look simple and stupid in the beginning, but it can easily grow over time. With this interface of course we need the concept of a HID bus. > > For standard keyboard and mouse reports we however should have a > > standard driver that can handle most of them. > > Unfortunately there is a non-trivial bunch of hardware that pretends to be > standard keyboard/mouse, but behaves badly. Last week I had to do > workaround for Logitech S510, which seems to generate usages far above the > logical maximum specified in report descriptor, to give one example. > > So we will probably end up with many small driver for exotic pieces of > hardware being registered to the hid bus. But this is definitely much > better than the current mess of hid quirks. Maybe the report descriptor is broken. I have some Bluetooth HID where they actually byte-swapped values and it totally confused the report descriptor parser. For some devices it might be better to actually patch the report descriptor instead of adding quirks to the HID core. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
On Mon, 5 Mar 2007, Marcel Holtmann wrote: > no, because if I recall correctly these are the boot mode drivers and > actually not used at all in any modern distribution. That's correct. > For me the task of converting HID reports into input events shouldn't be > actually the job of the HID core layer. My understanding is that the HID > core should support multiple transport layers. This is currently > achieved through the hid_device abstraction and used by the USB and by > the Bluetooth subsystem. This is the lower interface to HID. On the > upper interface I like to see a driver like interface. So we can > register specific drivers that can handle specific use cases or vendor > specific reports. This I completely agree with, and have this on my TODO for quite a long time. If Li Yu would like to spend some time on it, it certainly would help. The current "simple HID interrface" is a suitable workaround for various buggy/broken/nonstandard hardware which is currently not handled by the HID kernel code properly, but it's definitely not a long-term solution that should go to mainline. > For standard keyboard and mouse reports we however should have a > standard driver that can handle most of them. Unfortunately there is a non-trivial bunch of hardware that pretends to be standard keyboard/mouse, but behaves badly. Last week I had to do workaround for Logitech S510, which seems to generate usages far above the logical maximum specified in report descriptor, to give one example. So we will probably end up with many small driver for exotic pieces of hardware being registered to the hid bus. But this is definitely much better than the current mess of hid quirks. On Mon, 5 Mar 2007, Dmitry Torokhov wrote: > We are running out if quirks and we can't continue in this fashion so Li > tried to provide mechanism to augment default HID behaviour for sepcific > devices. That's right. We could always extend the quirks so that it's long long, or something like that, but this is also not sustainable in the long term. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
Hi Marcel, On 3/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: Hi Dmitry, > > This also means that the current keyboard and mouse > > input devices will become a HID driver. > > Are you talking about usbmouse and usbkbd? no, because if I recall correctly these are the boot mode drivers and actually not used at all in any modern distribution. For me the task of converting HID reports into input events shouldn't be actually the job of the HID core layer. My understanding is that the HID core should support multiple transport layers. This is currently achieved through the hid_device abstraction and used by the USB and by the Bluetooth subsystem. This is the lower interface to HID. On the upper interface I like to see a driver like interface. So we can register specific drivers that can handle specific use cases or vendor specific reports. For standard keyboard and mouse reports we however should have a standard driver that can handle most of them. For identification we actually do have the bus type, vendor id and product id available. We also can register drivers for specific report ids or usages. I do like the HID simple driver idea, but it is not a simple driver, it should be a generic driver interface. Ah, OK. Then we are in complete agreement ;) -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
Hi Dmitry, > > This also means that the current keyboard and mouse > > input devices will become a HID driver. > > Are you talking about usbmouse and usbkbd? no, because if I recall correctly these are the boot mode drivers and actually not used at all in any modern distribution. For me the task of converting HID reports into input events shouldn't be actually the job of the HID core layer. My understanding is that the HID core should support multiple transport layers. This is currently achieved through the hid_device abstraction and used by the USB and by the Bluetooth subsystem. This is the lower interface to HID. On the upper interface I like to see a driver like interface. So we can register specific drivers that can handle specific use cases or vendor specific reports. For standard keyboard and mouse reports we however should have a standard driver that can handle most of them. For identification we actually do have the bus type, vendor id and product id available. We also can register drivers for specific report ids or usages. I do like the HID simple driver idea, but it is not a simple driver, it should be a generic driver interface. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
On 06/03/07, Li Yu <[EMAIL PROTECTED]> wrote: Dmitry Torokhov wrote: > If we define HID "bus" allowing drivers to bind on VID:PID and provide > default library module for parsing HID reports and providing access to > HID transports (USB/BT) then writing tiny drivers adjusting just a > part of hid_input_event and relying on default implemenattaion where > it makes sense will become a breeze. > > But (You may guess I will say this word :), before the HID bus or other better implementation come , I hope use the extended keys of my keyboard on Linux, and I guess other people also think same with me, so we need something here temporarily, even it do not merge into upstream code tree. And until something better comes along I am happy to use what Li Yu has produced (speaking as an ordinary user). Thanks -- Harold Sargeant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
On Tue, 6 Mar 2007, Li Yu wrote: > > If we define HID "bus" allowing drivers to bind on VID:PID and provide > > default library module for parsing HID reports and providing access to > > HID transports (USB/BT) then writing tiny drivers adjusting just a > > part of hid_input_event and relying on default implemenattaion where > > it makes sense will become a breeze. > But (You may guess I will say this word :), before the HID bus or other > better implementation come , I hope use the extended keys of my keyboard > on Linux, and I guess other people also think same with me, so we need > something here temporarily, even it do not merge into upstream code > tree. > And, I want to know that is somebody works on HID bus, Can I join it? I will probably start working on it one day. Anyway some parts of what Dmitry described are already in the mainline since 2.6.20 - the parser code (and hid_device registration and initialization in general) is already there. Access to transport layers (USB/BT) is partly also there (see hid_open(), hid_close() and hidinput_input_event() callbacks in struct hid_device). So really the only one pending thing which is non-trivial would be creating an interface for registering the device driver for given VID/PID on the HID bus, and solving the fallback mechanism, i.e. assuring that everything works for drivers which are OK with generic hid and hid-input behavior. I will happily accept such patches from you, if you do them. Otherwise I will start to work on it in a future anyway. Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
On Tue, 6 Mar 2007, Robert Marquardt wrote: > I do not know too much about the Linux innards, but my opinion is that > the HID API to userland should be the bare reports. Windows is handling > it that way for a good reason. Far too many HID devices have either > non-informative descriptors (declaring a byte array report) or declaring > a report which does not match the data contained. Parsing a report is > definitely a userland job. Which is exactly what the new hidraw interface is going to provide. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
Jiri Kosina wrote: In addition to that, as I stated in some previous e-mail, I am currently working on new 'hidraw' interface, which will provide more flexibility to userland applications willing to operate on raw HID data, than they currently have with hiddev. I do not know too much about the Linux innards, but my opinion is that the HID API to userland should be the bare reports. Windows is handling it that way for a good reason. Far too many HID devices have either non-informative descriptors (declaring a byte array report) or declaring a report which does not match the data contained. Parsing a report is definitely a userland job. -- -- Code Mercenaries Hard- und Software GmbH Karl-Marx-Str. 147a 12529 Schönefeld OT Grossziethen Germany Tel: x49-3379-2050920 Fax: x49-3379-2050930 HRB 16007 Potsdam Geschäftsführer: Guido Körber, Christian Lucht - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
Dmitry Torokhov wrote: > If we define HID "bus" allowing drivers to bind on VID:PID and provide > default library module for parsing HID reports and providing access to > HID transports (USB/BT) then writing tiny drivers adjusting just a > part of hid_input_event and relying on default implemenattaion where > it makes sense will become a breeze. > > Well, actually, the argument have begun since the version 0.4.0 of HID simple interface. I clearly know its weaknesses, and I believe Dmitry said, the HID bus/tiny driver way is the most ultimatest way very well. But (You may guess I will say this word :), before the HID bus or other better implementation come , I hope use the extended keys of my keyboard on Linux, and I guess other people also think same with me, so we need something here temporarily, even it do not merge into upstream code tree. And, I want to know that is somebody works on HID bus, Can I join it? Good luck. -Li Yu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
On 3/5/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: On Mon, 5 Mar 2007, Li Yu wrote: > Under standard HID device driver development means, we need to write > one interrupt handler for each new HID device to report event to input > subsystem. However, although the most of they can not merge into > mainstream kernel tree, they have only some extended keys, e.g. many > remote controllers. I think it seem break a fly on the wheel, which > write one new interrupt handler for this reason. This paragraph I don't seem to understand. Either the device is claimed by hid-input (*), and then when the device is behaving more-or-less correctly, hid-input handles the usages sent in reports and maps them properly to input events. New mapping can be quite trivially added to hid-input. We are running out if quirks and we can't continue in this fashion so Li tried to provide mechanism to augment default HID behaviour for sepcific devices. However I don't think we want this particular implementation - it firrces sub-drivers to be compiled into HID driver which may grow indefinitely. If we define HID "bus" allowing drivers to bind on VID:PID and provide default library module for parsing HID reports and providing access to HID transports (USB/BT) then writing tiny drivers adjusting just a part of hid_input_event and relying on default implemenattaion where it makes sense will become a breeze. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0
On Mon, 5 Mar 2007, Li Yu wrote: > Under standard HID device driver development means, we need to write > one interrupt handler for each new HID device to report event to input > subsystem. However, although the most of they can not merge into > mainstream kernel tree, they have only some extended keys, e.g. many > remote controllers. I think it seem break a fly on the wheel, which > write one new interrupt handler for this reason. This paragraph I don't seem to understand. Either the device is claimed by hid-input (*), and then when the device is behaving more-or-less correctly, hid-input handles the usages sent in reports and maps them properly to input events. New mapping can be quite trivially added to hid-input. If the HID device is not claimed by hid-input, then userspace can access the hid events through hiddev and perform any actions that are needed. Could you please elaborate a little bit more why your approach using "simple HID interface" is better than for example hiddev+uinput, done completely in userspace? In addition to that, as I stated in some previous e-mail, I am currently working on new 'hidraw' interface, which will provide more flexibility to userland applications willing to operate on raw HID data, than they currently have with hiddev. (*) OK, I would tend to agree that the algorithm which decides whether the given device will be claimed by hid-input driver could be improved to be more HID-specification and HUT compliant. I have this in my TODO, but I guess it doesn't matter too much here. Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
On Mon, 5 Mar 2007, Marcel Holtmann wrote: > actually, I don't think we need a simple driver interface. We need a HID > driver interface in general. For example that you can register a driver > for one or multiple report ID and then it handles input and output for > these report IDs. This also means that the current keyboard and mouse > input devices will become a HID driver. Hi Marcel, sorry, this is not clear to me - what keyboard and mouse devices are you talking here precisely? As not all keyboard and mouse devices are HID, this is probably not what you've meant ... ? Thanks. > In addition to the kernel HID driver we might also when have a new > hidraw (or modified hiddev) interface that allows to handle specific > report ID from a userspace application. Especially when it comes to LED > displays or UPS systems. I have already written some code of hidraw interface, but it's not yet finished due to too many other pending things. Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
On 3/5/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote: This also means that the current keyboard and mouse input devices will become a HID driver. Are you talking about usbmouse and usbkbd? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DOC] The documentation for HID Simple Driver Interface 0.5.0
Hi Li, > == > HID device simple driver interface > == actually, I don't think we need a simple driver interface. We need a HID driver interface in general. For example that you can register a driver for one or multiple report ID and then it handles input and output for these report IDs. This also means that the current keyboard and mouse input devices will become a HID driver. In addition to the kernel HID driver we might also when have a new hidraw (or modified hiddev) interface that allows to handle specific report ID from a userspace application. Especially when it comes to LED displays or UPS systems. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DOC] The documentation for HID Simple Driver Interface 0.5.0
==
HID device simple driver interface
==
Note
If you just begin to study from writing input device driver, please see the
input-programming.txt, I am afraid this is not you want, do not confuse with the
"simple" in this name.
Version
This is used for the version 0.5.0
--
Overview
--
Under standard HID device driver development means, we need to write
one interrupt handler for each new HID device to report event to
input subsystem. However, although the most of they can not merge into
mainstream kernel tree, they have only some extended keys, e.g. many
remote controllers. I think it seem break a fly on the wheel, which
write one new interrupt handler for this reason.
The basic idea is reuse the interrupt handler in hid-core.c. so writing
driver for new simple HID device will be more easier, quickly, and do not
need touch hid core.
In essence, this interface just is some hooks in HID core.
The hid-simple.h include this API. But, defore use this interface, you must
include hid.h first.
What's you will get from this interface.
Use me, you can:
1. Write the driver of USB input device without write code take care of
details of setup and clear usage.
2. A driver use this interface can be as a HID device input filter.
This interface can not support the more drivers handle one device at same time
yet. I can not sure if we really need this feature.
-
Prepare
-
Before use this interface, you must turn on these kernel configuration
items:
CONFIG_HID_SIMPLE : HID simple driver interface
--
Register and unregister
--
1. Register a simple driver.
int hidinput_register_simple_driver(struct hidinput_simple_driver *simple)
Like any driver register function, it register your driver to kernel,
when the chance that match device come, your driver can probe it. At least, you
must fill the member of parameter simple : name.
Return 0 mean register successfully. elsewise mean there have some
failures in register process.
So far, this function only can return 0 and -EINVAL.
When you driver matched one device, it will reregister it into input
subsystem (see the function hidinput_reconnect_core(), if you want).
This function generally is used in HID sublayer.
2. Unregister a simple driver.
void hidinput_unregister_simple_driver(struct hidinput_simple_driver *simple)
Like any driver register function, it clean your driver from kernel, and
in this process, your driver will disconnect any device which it matched.
However,
it do not free your memory of driver structure, that's your task.
This may reregister the device into input subsystem (see the function
hidinput_reconnect_core(), if you want).
This function generally is used in HID sublayer.
3. USB device driver.
You should use follow functions for USB device. the usage of these functions
is
same with aboves.
int hidinput_register_simple_usb_driver(struct hidinput_simple_driver *simple)
void hidinput_unregister_simple_usb_driver(struct hidinput_simple_driver
*simple)
Both functions is used in driver.
--
Usage
--
Each simple driver have one data structure hidinput_simple_driver:
struct hidinput_simple_driver {
/*
* The members for implement only are ignored here,
* please do not depend on them
*/
/* public for HID sublayer. */
int (*match_device)(struct hidinput_simple_driver *drv,
struct matched_device *dev);
/* public for drivers */
struct module *owner;
char *name;
int (*connect)(struct hid_device *, struct hid_input *);
void (*disconnect)(struct hid_device *, struct hid_input *);
void (*setup_usage)(struct hid_field *, struct hid_usage *);
void (*clear_usage)(struct hid_field *, struct hid_usage *);
int (*pre_event)(const struct hid_device *, const struct hid_field *,
const struct hid_usage *, const __s32);
int (*post_event)(const struct hid_device *, const struct hid_field *,
const struct hid_usage *, const __s32);
int (*open)(struct input_dev *dev);
void (*close)(struct input_dev *dev);
void *private;
struct usb_device_id *id_table;
struct usage_page_block *usage_page_table;
};
The data member description:
struct module *owner;
In most cases, set this member to THIS_MODULE is your want to.
char *name;
The name of your driver. you must fill this member before register it.
void *private;
You can save the data that your driver use only here. HID simple driver
core do not take care of this.
struct usb_device_id *id_table;
As same with other USB device driver, this is used by m
