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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
==
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
==
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
30 matches
Mail list logo
