This is from our WIP2 Bluetooth branch which is about a year out of date.

I copied files to other location, then created this branch and used WinMerge to merge in all related changes,

Without hopefully undoing any of the other changes

Turns out they are a lot different than other PS3 controllers.

When plugged into USB, it appears like these units do not send
any reports.  They do allow us to do pairing (which is differnt)
than other PS3, as well as set the Bulb LED color, which I now
have it alternating colors every few seconds and also it tries
to pair it with a BT dongle

When connected to Bluetooth, it now is setup to generate reports,
as well as again set the bulb color and rumble.

So far it maps the 3 button bytes into the buttons field and then
simply copies most all of the data down into Axis, starting where
the Trigger button is.

JoystickBT.ino was updated, to know about this controller and as
mentioned above in the USB case it tries to pair and plays with the
color of bulb.

In the BT case it tries to display data.  I did a quick and dirty
change of the Accel/Gyro like stuff which is probably totally wrong.

Pressing some of the buttons will set bulb color and pressing trigger
will set rumble.

PS3 Motion controller - very little mapping of axis

At least with the Tecknet mouse...

There are issues with binding when already trusted... Need to debug, also likewise if it times out and tries to restore the connection, but at least the beginning is getting some values

I put in hopefully the start of Bluetooth Mouse.

However the one mouse I have is not even trying to talk to the dongle, so not have not seen any data to verify that it is correct and to see the actual data returned...

PS4 starting to work, Still some rumble issues.

Also some WIP parts for caching remote name

Some of these changes also came from @mjs513

Needed HID Parser to support Bidirectional Transfers

The HidParser code was setup such that the claim for a report, the caller could say I want to claim the whole thinig and allowed callback functions for processing of in buffer and out buffer.

Allow RawHID to contribute Transfer_t

Since RawHID may need more resources than most, maybe it should contribute the additional structures

The constructor for a RAWHID object allows you to specify the top usage
that it wishes to connect to.  I used this for example to be able to
connect to a Teensy with the RAWHID associated with emulating the
Serial object.

If a HID Input class says that it wants to claim the whole interface, I
reuse the buffer associated with holding the HID descriptor and use it
for output buffers.

This delta, adds an extra keyboard object to handle those keys that are not part of the main keyboard class.  In particular there are separate HID reports for some of the keys, such as Power keys, and multimedia keys.

These reports might be on separate Interface or in cases where the mouse and keyboard are on the same device, the extra reports may be on the Mouse Interface.

So far I have not tried to combine with Keyboard object as might require multiple inheritance which I would like to avoid.

Also I extended the special key mapping table to map several other keys like F1-12, Arrow, Home/end... To special values where the 0x80 bit is set.  I used the same values as used for the Arduino Keyboard library.  I did not use their defines as they used defines like KEY_F1, which already exists in core, but in core it is the scan code from the keyboard and not the end user value.