i2c_hid: driver for i2c-hid devices

This is getting more common in tablets and laptops. It replaces PS/2 for
the internal keyboard and pointing devices. This is simpler and cheaper
than using up USB ports, and also simpler than the old and quirky PS/2
protocol.

The HID spec is the same no matter what transport is used (it is also
applicable for Bluetooth). Ideally we could create a separate HID bus
manager that would handle all these devices in a generic way, but that
is a lot of work nad extra complications for uncertain gains.

For now, just move the common files to a shared directory where both
drivers can use them. As a result the files are compiled twice, which is
what we want, because currently they hardcode some device paths that
need to be different for each driver.

Change-Id: I0327f6864dd0a4372b708f7b7ecf299aa86a6ea9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2466
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

usb_hid: fix STALL handling

It is not allowed to do synchronous calls to the usb bus manager
while in a usb callback routine. This causes the usb stack to get
very confused.

This code now uses the async interface to clear the STALL, and will
try to continue normal operations after that request has been handled.

Fix sponsered by http://www.izcorp.com

Move the quirky device detection out of the HIDDevice constructor and into the
usb_hid_device_added hook so that we can actually detect non-HID devices at all.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42002 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed the way how devices are enumerated and protocol handlers are added to
handle the different device classes. Handlers are now added based on the
application collections that the HID descriptor describes instead of by
enumerating the different report items inside the reports. This means that a
device is now logically treated as a mouse when it comes with an application
collection that designates it as a mouse, instead of when there is a report
that contains an X and a Y axis. This resolves the conflicts that gamepads
and joysticks were added as mice due to them containing such elements. This
therefore fixes #4499 and opens up the way to properly handle other device
types like joysticks (#7429), gamepads, tablets (#7354, #5989 and #7481) and
so on. I'll work on gamepads/joysticks next and see where we stand for tablets
later.
* Added a few enumeration functions to HIDCollection to support the above.
* Fix the root collection handling. A device doesn't describe a single root
collection and then adds everything as a child. Instead it just has multiple
collections on level 0. We account for that now by always creating an empty
logical collection as the root collection where all the collections of the
descriptor get added.
* Rename the {Mouse|Keyboard}Device.{cpp|h} to
{Mouse|Keyboard}ProtocolHandler.{cpp|h} as that more clearly describes their
purpose. These classes are protocol handlers, i.e. they handle the ioctl based
mouse and keyboard protocol between the driver and the input_server add-ons.
* Change a lot of stuff to use references instead of pointers where it makes
sense (not necessarily complete yet).

I've tested this successfully on a keyboard with extended keys, a combo device
with a keyboard with extended keys and a mouse, a mouse and a gamepad (that now
doesn't do anything anymore) and found no regressions. However, since there are
a lot of very varied ways how to describe such functions with HID, it's not too
unlikely that some more curiously described devices will now stop working. These
have to be handled case by case and their usages have to be added to the added
to the appropriate handlers (or new handlers have to be written). Please test
and create bug reports (preferrably including the report descriptor that is
written out to /tmp).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41794 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Implemented the debugger mode for the USB keyboard driver.
* Made the USB keyboard driver safe to be used from more than one team - only
the first one will be able to retrieve any keys. Before, since there was no
locking, internal structures would have been messed up in that case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36283 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Use const where appropriate.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36279 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prepared driver for the implementation of the debugger mode: there is now a
uint32 cookie that is saved per file handle and passed to the ProtocolHandler
objects.
* Beware that the output of the driver no longer shows the handler as pointer,
but the internal device cookie.
* Added handling of KB_SET_DEBUG_READER to the KeyboardDevice class (it just
doesn't do anything with that).
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36274 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Completely rework the USB HID driver to make use of the HID framework
introduced earlier.
* Reworked the previous device classes to make them ProtocolHandlers handling
their respective input_server <-> driver protocol.
* Implement setting report item data and building/sending reports based on that.
* Remove the old HID parsing code.

This enables us to use all HID devices as we now parse and use the HID
descriptors/reports. Non-boot-porotocol devices should therefore work.

The next step will be to implement a generic input/output framework in userland
that can communicate with a generic protocol handler in usb_hid. This will then
enable applications to make use of all the non-mapped HID stuff directly.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31790 a95241bf-73f2-0310-859d-f6bbb57e9c96

* When a device closes, delete the transfer semaphore, so that threads blocking
on it are unblocked and get an error.
* Make fOpen volatile to prevent unwanted caching effects when checking it from
different threads. (?)
* Check IsOpen() in the KeyboardDevice class in more acquire_sem_etc() return
cases, analogous to the MouseDevice class.

I am still getting a problem when relaunching input_server with the input_server
add-on thread that ioctl()s on a USB keyboard fd, which should have never fired
because it's a fake device from a KVM. After the first input_server instance is
gone, this thread keeps on busy looping in acquire_sem_etc()->switch_sem() from
within the ioctl() of the KeyboardDevice usb_hid driver. Still on it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28350 a95241bf-73f2-0310-859d-f6bbb57e9c96

Rewriting the usb_hid driver. It has now gotten a driver part and a device part
structured into the HIDDevice base class and KeyboardDevice and MouseDevice
subclasses. This can be extended easily to support more device types like game
controllers, joysticks and other HID devices. The parsing code remains untouched
while the interpretation code has been integrated into the device classes.
The driver should work much the same way as before including the boot protocol
only keyboard limitation. On the other hand composite devices that combine
multiple devices should now work, as long as they expose those devices as two
seperate interfaces.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25657 a95241bf-73f2-0310-859d-f6bbb57e9c96

usb_hid: fix STALL handling

It is not allowed to do synchronous calls to the usb bus manager
while in a usb callback routine. This causes the usb stack to get
very confused.

This code now uses the async interface to clear the STALL, and will
try to continue normal operations after that request has been handled.

Fix sponsered by http://www.izcorp.com

Move the quirky device detection out of the HIDDevice constructor and into the
usb_hid_device_added hook so that we can actually detect non-HID devices at all.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42002 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed the way how devices are enumerated and protocol handlers are added to
handle the different device classes. Handlers are now added based on the
application collections that the HID descriptor describes instead of by
enumerating the different report items inside the reports. This means that a
device is now logically treated as a mouse when it comes with an application
collection that designates it as a mouse, instead of when there is a report
that contains an X and a Y axis. This resolves the conflicts that gamepads
and joysticks were added as mice due to them containing such elements. This
therefore fixes #4499 and opens up the way to properly handle other device
types like joysticks (#7429), gamepads, tablets (#7354, #5989 and #7481) and
so on. I'll work on gamepads/joysticks next and see where we stand for tablets
later.
* Added a few enumeration functions to HIDCollection to support the above.
* Fix the root collection handling. A device doesn't describe a single root
collection and then adds everything as a child. Instead it just has multiple
collections on level 0. We account for that now by always creating an empty
logical collection as the root collection where all the collections of the
descriptor get added.
* Rename the {Mouse|Keyboard}Device.{cpp|h} to
{Mouse|Keyboard}ProtocolHandler.{cpp|h} as that more clearly describes their
purpose. These classes are protocol handlers, i.e. they handle the ioctl based
mouse and keyboard protocol between the driver and the input_server add-ons.
* Change a lot of stuff to use references instead of pointers where it makes
sense (not necessarily complete yet).

I've tested this successfully on a keyboard with extended keys, a combo device
with a keyboard with extended keys and a mouse, a mouse and a gamepad (that now
doesn't do anything anymore) and found no regressions. However, since there are
a lot of very varied ways how to describe such functions with HID, it's not too
unlikely that some more curiously described devices will now stop working. These
have to be handled case by case and their usages have to be added to the added
to the appropriate handlers (or new handlers have to be written). Please test
and create bug reports (preferrably including the report descriptor that is
written out to /tmp).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41794 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Implemented the debugger mode for the USB keyboard driver.
* Made the USB keyboard driver safe to be used from more than one team - only
the first one will be able to retrieve any keys. Before, since there was no
locking, internal structures would have been messed up in that case.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36283 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Use const where appropriate.
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36279 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prepared driver for the implementation of the debugger mode: there is now a
uint32 cookie that is saved per file handle and passed to the ProtocolHandler
objects.
* Beware that the output of the driver no longer shows the handler as pointer,
but the internal device cookie.
* Added handling of KB_SET_DEBUG_READER to the KeyboardDevice class (it just
doesn't do anything with that).
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36274 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Completely rework the USB HID driver to make use of the HID framework
introduced earlier.
* Reworked the previous device classes to make them ProtocolHandlers handling
their respective input_server <-> driver protocol.
* Implement setting report item data and building/sending reports based on that.
* Remove the old HID parsing code.

This enables us to use all HID devices as we now parse and use the HID
descriptors/reports. Non-boot-porotocol devices should therefore work.

The next step will be to implement a generic input/output framework in userland
that can communicate with a generic protocol handler in usb_hid. This will then
enable applications to make use of all the non-mapped HID stuff directly.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31790 a95241bf-73f2-0310-859d-f6bbb57e9c96

* When a device closes, delete the transfer semaphore, so that threads blocking
on it are unblocked and get an error.
* Make fOpen volatile to prevent unwanted caching effects when checking it from
different threads. (?)
* Check IsOpen() in the KeyboardDevice class in more acquire_sem_etc() return
cases, analogous to the MouseDevice class.

I am still getting a problem when relaunching input_server with the input_server
add-on thread that ioctl()s on a USB keyboard fd, which should have never fired
because it's a fake device from a KVM. After the first input_server instance is
gone, this thread keeps on busy looping in acquire_sem_etc()->switch_sem() from
within the ioctl() of the KeyboardDevice usb_hid driver. Still on it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28350 a95241bf-73f2-0310-859d-f6bbb57e9c96

Rewriting the usb_hid driver. It has now gotten a driver part and a device part
structured into the HIDDevice base class and KeyboardDevice and MouseDevice
subclasses. This can be extended easily to support more device types like game
controllers, joysticks and other HID devices. The parsing code remains untouched
while the interpretation code has been integrated into the device classes.
The driver should work much the same way as before including the boot protocol
only keyboard limitation. On the other hand composite devices that combine
multiple devices should now work, as long as they expose those devices as two
seperate interfaces.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25657 a95241bf-73f2-0310-859d-f6bbb57e9c96