public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Li Yu <raise.sail@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	yanghong@ccoss.com.cn,
	linux-usb-devel <linux-usb-devel@lists.sourceforge.net>,
	hongzhiyi@ccoss.com.cn, Marcel Holtmann <marcel@holtmann.org>,
	LKML <linux-kernel@vger.kernel.org>, Li Yu <raise.sail@gmail.com>
Subject: Re: [linux-usb-devel] [RFC] HID bus design overview.
Date: Fri, 30 Mar 2007 11:06:28 +0800	[thread overview]
Message-ID: <460C7EB4.9080009@gmail.com> (raw)
In-Reply-To: <d120d5000703281200wd914f51s18437a6a8e4107f6@mail.gmail.com>

Dmitry Torokhov wrote:
> On 3/28/07, Jiri Kosina <jkosina@suse.cz> wrote:
>>
>> The crucial thing here is that all reports but the ones that the driver
>> registered to will be processed in a standard way by the generic hid bus
>> layer, and those reports that the driver registered to will be
>> ignored by
>> the layer, and passed for processing to the driver.
>>
>
> I don't think it is a good idea to register driver for specific
> usages/reports. Quite often you want to adjust processing of a report
> for a specific device. What if there are 2 devices that need such
> quirks? How will you do hotplug and module loading? Emit new uevent
> for every report? Also, what about users and Kconfig? "Driver for
> usage 0x000012345. Say Y if your hardware does not wotk correctly with
> defautl handler for this usage and require special processing"???
>
> Just register based on VID/PID and provide standard
> hid_default_input_event() to drivers so they would call it for reports
> they don't need to do special processing on.
>

    I think the shadow driver can not share inputdev with the related
fundamental driver, so here are two input devices for one hid_device,
how we should process both? It seem we have three choices:

1. Shadow | Fundamental means

    I think this is Jiri said. Fundamental driver handle all common
input events, and Shadow driver handle anther specific input events,
this imply user space process need monitor both input devices at same
time, I do not think this is good idea.

2. Shadow & Fundamental means

    Let Fundamental driver and Shadow driver work at same time! but
shadow also handle specific input event. So, the user may get twice
input events! For example, the keyboard input in console.
Also, I do not like this.

3. Shadow ^ Fundamental means

    Let Shadow driver handle every thing, and fundamental device silent,
even unregister it. I think this is best choice between them, this means
have a bit of complex.

Welcome for your words.

PS: Have we need more than one shadow driver for same fundamental
driver? I do not think so.

Good luck.

- Li Yu





  parent reply	other threads:[~2007-03-30  3:07 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-05  7:32 [DOC] The documentation for HID Simple Driver Interface 0.5.0 Li Yu
2007-03-05 20:44 ` Marcel Holtmann
2007-03-05 20:11   ` Dmitry Torokhov
2007-03-05 22:40     ` Marcel Holtmann
2007-03-06 13:25       ` Dmitry Torokhov
2007-03-06 13:47       ` Jiri Kosina
2007-03-06 18:57         ` Marcel Holtmann
2007-03-05 21:47   ` Jiri Kosina
2007-03-05 22:12 ` [linux-usb-devel] " Jiri Kosina
2007-03-05 22:27   ` Dmitry Torokhov
2007-03-06  1:37     ` Liyu
     [not found]     ` <45ECC5A4.20203@ccoss.com.cn>
2007-03-06  9:40       ` Jiri Kosina
2007-03-06 11:52       ` Harold Sargeant
2007-03-06  7:01   ` Robert Marquardt
2007-03-06  7:37     ` Jiri Kosina
2007-03-19 10:44 ` [RFC] HID bus design overview Li Yu
2007-03-26  8:27   ` [linux-usb-devel] " Marcel Holtmann
2007-03-28  1:58     ` Li Yu
     [not found]     ` <4609CAF2.3040303@ccoss.com.cn>
2007-03-28  7:51       ` Jiri Kosina
2007-03-28 19:00         ` Dmitry Torokhov
2007-03-28 19:13           ` Jiri Kosina
2007-03-30  3:06           ` Li Yu [this message]
2007-03-30  4:33             ` Dmitry Torokhov
2007-03-30  5:37               ` Li Yu
2007-03-30 16:13                 ` Dmitry Torokhov
2007-03-31 22:49               ` Jiri Kosina
2007-04-02  1:47                 ` Li Yu
2007-04-02  4:15                   ` Dmitry Torokhov
2007-04-02  7:07                     ` Li Yu
2007-04-02  7:42                       ` Greg KH
2007-04-02  9:34                       ` Jiri Kosina
2007-04-02 12:40                         ` Dmitry Torokhov
2007-04-02  4:09                 ` Dmitry Torokhov
2007-04-02  9:37                   ` Jiri Kosina
2007-04-02 10:14                     ` Robert Marquardt
2007-04-02 12:21           ` Marcel Holtmann
2007-04-02 12:33             ` Jiri Kosina
2007-04-02 16:47               ` Marcel Holtmann
2007-04-03  1:15                 ` Li Yu
2007-04-03  3:42                   ` Dmitry Torokhov
2007-04-03  8:57                   ` Jiri Kosina
2007-04-04  0:55                     ` Li Yu
2007-04-04 14:54                     ` Marcel Holtmann
2007-04-04 23:01                     ` Adam Kropelin
2007-04-04 23:12                       ` Jiri Kosina
2007-04-04 23:34                         ` Adam Kropelin
2007-04-05  8:36                           ` Jiri Kosina
2007-04-05 14:08                             ` Adam Kropelin
     [not found]                           ` <46189FE3.6050206@gmail.com>
2007-04-09  1:54                             ` [linux-usb-devel] HID bus prototype - 20070408 Li Yu
2007-04-10  9:40                             ` Jiri Kosina
2007-04-10 11:00                               ` [linux-usb-devel] " Li Yu
2007-04-05  1:25                     ` [linux-usb-devel] [RFC] HID bus design overview Li Yu
2007-04-05  3:09                       ` Dmitry Torokhov
2007-04-05  5:28                         ` Li Yu
2007-04-05  6:47                           ` Li Yu
2007-04-06  0:58                         ` Li Yu
2007-03-29  5:37         ` Li Yu
2007-03-29  9:24           ` Jiri Kosina
2007-04-02 12:19           ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2007-04-02 11:57 Nicolas Mailhot
2007-04-03  1:40 ` Li Yu
2007-04-03  3:41   ` Dmitry Torokhov
2007-04-03  9:00   ` Jiri Kosina
2007-04-05 18:10     ` Paul Walmsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=460C7EB4.9080009@gmail.com \
    --to=raise.sail@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hongzhiyi@ccoss.com.cn \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=marcel@holtmann.org \
    --cc=yanghong@ccoss.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox