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
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 cor
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
a
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 tas
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
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 me
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
7 matches
Mail list logo
