Fix FTDI/libFTDI SPI drivers: batch writes, macOS support, bug fixes

[nurikk]

Summary

• Stable FTDI device identification: The output field now accepts ftdi_usb_open_string identifiers (e.g. s:0x0403:0x6014:usb_c) in addition to numeric bus:device addresses. This fixes the issue where the FTDI device location changes on every reboot, breaking the connection. String identifiers use the device's serial number which is stable across reboots.
• FTDI provider routing fix: ProviderSpi now correctly routes string identifiers with s:, i:, or d: prefixes to the FTDI provider instead of falling through to ProviderSpiGeneric.
• Enhanced device discovery: Discovery now reports serial numbers and device descriptions, and returns stable string identifiers as the default value when a serial number is available.
• Batch USB writes: Both ProviderSpiFtdi (Windows) and ProviderSpiLibFtdi (Linux/macOS) now assemble the full MPSSE command (CS low + write command + data payload + CS high) into a single buffer and perform one USB write, instead of 3-4 fragmented writes per frame. Reduces USB round-trip overhead and eliminates partial-frame failure modes.
• macOS libftdi support: Added #ifdef __APPLE__ to load libftdi1.dylib / libftdi1.1.dylib instead of .so variants.
• Bug fixes:
  • Input validation on writeBytes size parameter (0 and >65536 rejected)
  • Bounds check in FTDI device discovery loop (std::min with array size)
  • Corrected error message for ftdi_write_data_set_chunksize (was copy-paste of "ftdi_usb_reset")
  • Fixed "initilize" → "initialize" typo
  • Removed ~12 unused includes from ProviderSpiLibFtdi.cpp

Problem

FTDI USB devices get assigned a dynamic bus:device address on each boot. HyperHDR stored this address (e.g. 1794 = bus 7, device 2) in the config and used ftdi_usb_open_bus_addr() exclusively. After a reboot, the address changes (e.g. to 1797 = bus 7, device 5) and HyperHDR can't find the device.

Solution

• Added ftdi_usb_open_string() support to ProviderSpiLibFtdi — if output is a number, uses the existing bus:addr path (backward compatible); if it's a string, uses ftdi_usb_open_string() which supports formats like:
  • s:<vendor>:<product>:<serial> — open by serial number (recommended, stable)
  • i:<vendor>:<product> — open by vendor/product ID
  • d:<device_node> — open by device path
• Added ftdi_usb_get_strings() to discovery so it reports serial numbers
• Fixed ProviderSpi::init() to route string identifiers to the FTDI provider

Tested on

• LG webOS TV (rooted, aarch64) with libftdi1 — verified with sk9822 LEDs via FTDI adapter (serial: usb_c)
• FTDI device discovery working (reports serial numbers and stable identifiers)
• Stable across reboots — config s:0x0403:0x6014:usb_c works regardless of USB enumeration order
• Windows with ftd2xx driver (not tested, changes are symmetric with libftdi)
• macOS libftdi dylib loading (not tested on hardware)

Test plan

• Verify SPI LED output on Windows with ftd2xx driver
• Verify SPI LED output on Linux with libftdi driver
• Verify libftdi library loads correctly on macOS
• Verify FTDI device discovery lists correct devices with serial numbers
• Confirm backward compatibility with numeric bus:device addresses
• Confirm no regressions with existing SPI LED configurations

[awawa-dev]

Is there any reason to justify allocating the large buffer memory a second time? At this stage, the data buffer is quite large already as it contains the over-sampled bitstream for the Neopixel protocol.

[nurikk]

Good point. The per-frame allocation has now been removed in fab82f7: both the D2XX and libFTDI providers keep an instance-owned command buffer and reuse its capacity. Allocation now happens only on the first frame or if a later frame requires more capacity.

The second buffer is still needed to coalesce CS-low, the MPSSE header, the oversampled payload, and CS-high into one contiguous FTDI write. For a concrete 240-pixel RGBW SK6812 setup:

• oversampled LED buffer: 240 * 4 channels * 4 SPI bytes + 4 latch bytes = 3,844 bytes
• framed FTDI command buffer: 3,844 + 9 = 3,853 bytes
• both buffers together: 7,697 bytes, or about 7.52 KiB

So the memory footprint itself is negligible; the worthwhile part was removing allocator churn on every frame while retaining the single batched write.

[nurikk]

Also confirmed with the updated webOS build on real hardware: FTDI output to the 240-pixel RGBW SK6812 strip is working.

For clarity, this is not static storage: it is a provider-instance std::vector that dynamically allocates on the first frame (or when a larger frame appears) and then reuses that capacity. The reusable framed buffer is 3,853 bytes (~3.76 KiB) for this setup; including the existing oversampled LED buffer, both buffers total 7,697 bytes (~7.52 KiB).

The extra contiguous buffer lets us submit CS-low + MPSSE command header + payload + CS-high through one FTDI API write. The USB stack may still packetize it physically, but we avoid multiple driver submissions per frame.