History log of /haiku/src/add-ons/kernel/drivers/input/hid_shared/KeyboardProtocolHandler.cpp
Revision Date Author Comments
# 1a7cf570 26-Oct-2023 Jérôme Duval <jerome.duval@gmail.com>

usb_hid: the report value for an array is an index starting at the logical minimum

to be tested, related to bug #18641

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


# 4f18dc04 31-Oct-2022 Zelenoviy <zelenoviy@gmail.com>

usb_hid: Fix MaxReportSize computation

While calculating buffer size for IN reports, only "Input" report type
should been taken in account. Complex HID devices, such as "Gaming"
keyboards and mice, often have "Feature"-reports declared (with size way
bigger than "typical" kbd IN report) for vendor-specific device
configurations.

But "Feature"-reports are sent over control channel only and can't
appear on interrupt channel.

Should fix #14919, #17937, #17699

Change-Id: I4b9eb51938ca4aba2bc34247d00ae164eb2c19fc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5771
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>


# 6a9aea9d 15-Dec-2021 Lt-Henry <quiqueiii@gmail.com>

input: implemented B_GET_DEVICE_NAME ioctl on both usb and i2c input devices

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


# 6c88202d 03-Dec-2021 Lt-Henry <quiqueiii@gmail.com>

hid_shared: factorize more code between USB and HID

* Removed i2c keyboard handler, as it was just a hid shared handler duplicate with kdl stuff removed
* I've created a new macro def for the kdl code, splitting generic kdl code from specific usb one
* I2C custom KDL code can be added in the future (I don't know if it is already possible)

I am not very happy with this solution, but imho it is better than having two keyboard handlers. In fact, they were already out of sync from last patch series

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


# f6f9c751 22-Oct-2021 John Scipione <jscipione@gmail.com>

Remove trailing whitespace from hid_shared

Introduced in https://review.haiku-os.org/c/haiku/+/4403

366e9a62e9ee4446bfd2017320c20dd0796d9a1a => hrev55413

This is a whitespace only change, no functional changes.


# 366e9a62 28-Aug-2021 Lt-Henry <quiqueiii@gmail.com>

hid: Fixed report parsing bug. Support for keyboards using bitmap reports

* I've added support to multiple min-max ranges to array reports too.
* All possible usages are stored in an array (Vector<uint32>). Perhaps, this can be squashed into an array of ranges.
* Usage array is stored in HIDReport class, so there is only one copy of it.
* HIDReportItem no longer has UsageMinimum()/UsageMaximum() as this no longer works. Instead, a Usage() member has been introduces.
* HIDReportItems of type variable, have a Usage ID assigned to them. HIDReportItems of type array have a zero usage ID as it has no sense.
* Having a variable typed HIDReportItem to store a range of usages ID doesn't seem a good idea to me because Data() method would have to return the values of all usages... or perhaps ask for a specific usage value with something like Data(0x03). This will require changes in hid stack and overcomplicate things.
* A bitmap keyboard is a worst-case scenario: Near a hundred of usages (uint32) are stored and the same quantity of HIDReportItems are created (this is already happening on Haiku). It doesn't seem a resource drama to me.
* Keyboard Handler has room for improvement, but I would like to left that for another patch series.

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


# 1029af17 01-Sep-2021 Augustin Cavalier <waddlesplash@gmail.com>

Add missing includes following previous commit.

All these files were making use of headers included indirectly
through AutoLock.h that are now no longer following the previous commit.


# 2b4bf3ee 04-Apr-2020 Jérôme Duval <jerome.duval@gmail.com>

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>