- libSceBluetoothHid: the host still has no device backend or event worker. Registration retains only lifecycle state and never delivers the recovered 104-byte callback events. Custom worker scheduling throws; device ioctl failures and resource exhaustion are not modeled.
- sceBluetoothHidGetDeviceName and sceBluetoothHidGetDeviceInfo: output pointers are forwarded to device ioctls without accessing the buffers. Their output sizes and layouts remain unresolved. Report APIs use 64-bit device handles; device-info and disconnect APIs use 32-bit device IDs.
- sceBluetoothHidParamInitialize follows firmware 13.42's module as BunnyFl ran it natively (comment; not a console, and neither the kernel side of
/dev/btnor the event thread's work is covered): it writes its second argument at offset 0 of the 16-byte block, clears the 32-bit word at offset 8, leaves bytes 12 to 15 and returns 0, and a null block returns0x81540001. SharpProspero types that argument as a 64-bit value; it is the address of aBluetoothHidThreadParam, sincesceBluetoothHidRegisterCallbackreads the event thread's priority and affinity through it. - sceBluetoothHidThreadParamInitialize: the success value, range checks of the priority or affinity mask, bytes 20 to 23 and calls before
sceBluetoothHidInitare not covered by the run it follows (BunnyFl's native x86-64 run of firmware 13.42's module, not a console; comment). The run covers (700, 0x3f), stored as the 32-bit priority at offset 0 and the 64-bit mask at 8 with a 32-bit 0 at 16 and bytes 4 to 7 kept, and a null block, refused with0x81540001. Here any values are stored unchecked, bytes 20 to 23 are kept,sceBluetoothHidInitis not needed, and 0 is returned, assceBluetoothHidParamInitializereturns in that run and SharpProspero gives for every call on success. - sceBluetoothHidDebugGetVersion: returns a constant without reading arguments, so the supplied implementation does not establish whether the public prototype has unused parameters.