Customising support for USB drivers at compile-time

[SteveSpencer]

While looking at the code listing and map for a built kernel, I realised that there are many code-blocks in it that are not necessary for my particular case. This particularly applies to USB functionality.

Having also run into a couple of cases where the USB device discovery/configuration needed some minor tweaking, a few things occurred to me.

Firstly, in usbdevice.cpp CUSBDevice::Initialize, there are some special cases where retrieval of the default configuration descriptor has to be adjusted for certain devices (known for specific VID/PID combinations).

Secondly, in usbdevicefactory.cpp CUSBDeviceFactory::GetDevice, there are again, special cases matching interfaces, where, again, they are for specific VID/PID combinations.

Finally, again in usbdevicefactory.cpp CUSBDeviceFactory::GetDevice, there are device constructors being called for specific VID/PIDS.

It occurred to me that for the first and third situations, these could be dealt with using relatively simple data structures.
A data structure containing a vid, pid, configuration index, potentially an interface name, and a 'factory' function would mean that usbdevice.cpp and usbdevicefactory.cpp no longer need to be modified when adding in USB support for new devices.

I believe something along these lines this is being done for various CDC serial devices, which could be adapted into this system.

In addition, it would be possible in many cases, where it is known in advance that support for particular USB devices is NOT needed (for example, USB Midi, or gamepad devices), then by omitting rows from the table (via preprocessor definitions, eg OMIT_USB_MIDI), the built image would be smaller (at the cost of USB initialisation generating additional messages if unsupported devices are connected).

My suggestion would be to have a default table in lib/usb, which is NOT part of the libusb target, but is intended to be copied and modified in the app (and obviously, added as a Make dependency for kernel.img).

I would be interested to see what everyone else thinks about this, particularly as it would mean not just a rewrite of the relevant code, but it would also be a breaking change, meanin extra work modiying sample, app and addon Makefiles to make it all work.

[rsta2]

I could image to add the following system options as #ifndef's to usbdevicefactory.cpp (all not defined by default):

USB_EXCLUDE_AUDIO
USB_EXCLUDE_BLUETOOTH
USB_EXCLUDE_GAMEPAD
USB_EXCLUDE_HUB
USB_EXCLUDE_KEYB
USB_EXCLUDE_MIDI
USB_EXCLUDE_MOUSE
USB_EXCLUDE_NETWORK
USB_EXCLUDE_PRINTER
USB_EXCLUDE_SERIAL
USB_EXCLUDE_STORAGE
USB_EXCLUDE_TOUCHSCREEN

USB_EXCLUDE_NETWORK would also be used in usbdevice.cpp. But please don't make it too complicated. Someone (normally me ;) has to test this all, when a new release is prepared, and this is already not a small effort.

[SteveSpencer]

By default, I would not have ANY defined, it is up to the individual developer to decide what can be safely excluded.
I don't think it should be too complicated; the existing functions are remodelled to make use of a table, and helper functions.

I imagined that the table (and the helper functions) would be in a separate source file, so that the factory doesn't need to know too much about the types of devices it is helping to create.

The system options you suggest are the type of thing I imagined, and it would be simple to make it finer grained if needed, later (to exclude specific touchscreen devices, for example). I do not think anyone would want to eliminate USB hubs though, except in very special cases.

When do you plan to update master (48th step?) next ? I know that it will have the MQTT client fix, support for the 2GB Pi5 (and newer firmware), as well as the backlight and RealTek drivers.

I will obviously want to do a lot of testing on this, and make sure that the various samples that I can test work, and I would not want to delay your plans.

[rsta2]

That's the default state, that I meant. I'm fine with the current implementation of the USB device factory. I understand, that it can be necessary to exclude a number of USB function drivers. I think my suggested solution is less error prone and that's why I would prefer it. Usually I prefer the simple solution and try to keep Circle small. There is currently no planned release date for (maybe) Step48, because there were not much features added so far since Step47.

[rsta2]

I added the EXCLUDE_USB_* ifndefs on the develop branch.