* 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 <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Modifications made on hrev55413 removed UsageID from array Items,
but also (bug here) broke UsagePage, needed by KeyboardHandler
in order to recognize items as Keyboard ones.
Fixes#17263.
Change-Id: I4b73c69240f31d3c8c2aacf6bab0d270f2053387
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4458
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* 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 <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Lt-Henry