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 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
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 o
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 (dec
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 t
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 implemenatta
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 exte
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
==
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
15 matches
Mail list logo
