picofuse

Todo List
Global hw_wifi_init_device (const char *device)
Not implemented yet on Linux - always returns NULL there (see src/picofuse/hw/linux/CMakeLists.txt, which always falls back to hw/stub/wifi.c rather than gating a real backend behind PICOFUSE_WIFI the way hw/pico/CMakeLists.txt does). Needs a real wpa_supplicant control-socket client under picofuse/hw.
Global net_mqtt_publish (net_mqtt_t *mqtt, const char *topic, const void *payload, size_t payload_len, net_mqtt_qos_t qos, bool retain)
Retry a timed-out net_mqtt_qos_1/net_mqtt_qos_2 acknowledgment instead of just failing it - the spec's own answer (resend the PUBLISH with DUP=1, or for net_mqtt_qos_2 past PUBREC, just resend PUBREL) isn't implemented yet.
Global net_mqtt_subscribe (net_mqtt_t *mqtt, const char *topic, net_mqtt_qos_t qos)
Support net_mqtt_qos_2 here and for delivery - receiving a message at that level needs a PUBREC/PUBREL/PUBCOMP exchange plus dedup tracking, which isn't implemented yet; until it is, requesting it fails (see
Module USB
No module actually reads HID input (keystrokes, mouse movement) yet - something like hw_usb_register_hid_device() (working name only; needs a better one, and a real signature - presumably taking a hw_usb_device_t identifying which interface to read) for keyboard and mouse to start with, scoped to boot-protocol interfaces (hw_usb_device_subclass_boot_interface, interface_protocol == hw_usb_device_protocol_keyboard / hw_usb_device_protocol_mouse) so a fixed, known report shape (8 bytes keyboard, 3-4 bytes mouse) can be assumed without a general HID report-descriptor parser. This is NOT a single cross-platform implementation on top of this module - the three platforms need three genuinely different backends:
  • Pico: safe to do directly through TinyUSB's own HID class driver (CFG_TUH_HID, currently left at 0 in tusb_config.h, plus tuh_hid_report_received_cb()) - this process's USB stack is the only consumer of the bus, so there's nothing else to conflict with.
  • Linux: NOT through libusb/this module at all - the kernel's own usbhid driver already owns the interface the instant it's plugged in (confirmed via lsusb -t showing Driver=usbhid), so reading it via libusb would need libusb_detach_kernel_driver(), which steals the device from the rest of the running system (e.g. the real keyboard stops working for the OS itself). The correct mechanism is evdev (/dev/input/eventN), read alongside the OS rather than instead of it - see the already-reserved but unimplemented hid_type_evdev.
  • Darwin: same reasoning as Linux, different API - IOHIDManager/ IOHIDDeviceClient (IOKit's HID Manager) taps into HID collections the kernel's own driver already parsed, without taking exclusive ownership. Needs the user to grant Input Monitoring permission on modern macOS. The Linux/Darwin backends don't need hw_usb_init/PICOFUSE_USB engaged at all, since they observe at the kernel-input layer rather than the raw USB layer this module provides.