GUD_REQ_SET_BUFFER has one limitation setting Bulk Transfer size

[hnakayam]

From my experience, I believe there is a buffer size limit for GUD_REQ_SET_BUFFER requests.

If I set the USB Bulk transfer size to 9216000 bytes (1920x1200x4) and send it to the Raspberry Pi4 GUD, the GUD_REQ_SET_BUFFER request is accepted, but the next GUD_REQ_GET_STATUS request returns 0x03 (GUD_STATUS_ PROTOCOL_ERROR), while a request for 4147200 bytes (1920x1080x2) is accepted and succeeding GUD_REQ_GET_STATUS returns 0x00 (OK).

I then found the GUD Gadget source code fragment below, in gud_gadget_init() function.

*max_buffer_size = gdg->client.dev->mode_config.max_width * gdg->client.dev->mode_config.max_height * max_cpp; /* f_gud_drm will kmalloc a buffer of this size */ *max_buffer_size = min_t(size_t, *max_buffer_size, KMALLOC_MAX_SIZE);

What is of interest here is KMALLOC_MAX_SIZE, which is said to be around 4 MB in many cases. (I am not very familiar with this).
If so, shouldn't the GUD display driver side need to get this ”max_buffer_size” value via the GUD protocol?

Thanks,

[notro]

The max buffer size is communicated in gud_display_descriptor_req. See gud_gadget_req_get_descriptor() in the gadget.

If the buffer is not big enough to send a display update it is split into smaller updates. See gud_flush_damage() in the host driver.

KMALLOC_MAX_SIZE can be increased by changing the kconfig knob CONFIG_ARCH_FORCE_MAX_ORDER

[hnakayam]

Thank you for quick response.
Now I implement GUD_REQ_GET_DESCRIPTOR query and got below response in case of Raspberry Pi 4.

magic=0x1d50614d, version=0x01, flags=0x00000001
compression=0x01, max_buffer_size=0x00400000
min_width=0, max_width=7680, min_height=0, max_height=7680

So, KMALLOC_MAX_SIZE must be 4194304 bytes (4MB) then split bulk transfer for every 4MB worked very fine.

[notro]

If I remember correctly the PiZ/4 image I've made has max size set to 16MB.

[hnakayam]

This is very interesting point.

In our development process, we once port buildroot version GUD Gadget code into official raspbian OS (2022-01-28 versiom, kernel 5.10) environment. We rebuild rpi-5.10.y kernel https://github.com/raspberrypi/linux/tree/rpi-5.10.y of that release
with GUD gadget built-in, still using the same raspbian userland programs in raspbian SD memory ... then KMALLOC_MAX_SIZE setting must be 4MB.

Then I just tried "buildroot" version SD memory image and boot Raspberry Pi 4 then plug. The Windows driver reports GUD_REQ_GET_DESCRIPTOR query report as following.

magic=0x1d50614d, version=0x01, flags=0x00000001
compression=0x01, max_buffer_size=0x01000000
min_width=0, max_width=7680, min_height=0, max_height=7680

Yes. the "buildroot" version reports max_buffer_size as 16MB. So the driver made BulkTransfer just once for whole framebuffer update.

BulkTransfer Will send starting line 0, 1080 lines (8294400 Bytes), max_buffer_size=16777216
Bulk Transfer SUCCESS, 8294400 bytes written. time=185 msec
BulkTransfer 1080 of 1080 line transfer SUCCESS

We already impliment spliting Bulk transfer but seems no need to split when "buildroot" version Raspberry Pi 4 GUD case. (this is not our final target hardware though...) .

[hnakayam]

In fact, I am now in charge of developing a proprietary Windows 10 USB display driver, also works for GUD devices (at this point).
I can't comment on this development details, but can suggest a general direction on how GUD Windows driver could be developed...

[notro]

Cool, I did look into that but gave up on it when I saw that the driver needed to be signed. I'd be happy to answer any questions you have (by email is also fine).

[hnakayam]

Year, the sign process is very complicated. But if you register Microsoft as developer, you can get signed just for test purpose.

https://learn.microsoft.com/en-us/windows-hardware/drivers/install/how-to-test-sign-a-driver-package

But if you want to release display driver widely, you will be asked to pass Hardware Certification Kit (HCK) to get Microsoft sign. This must be certain amount of works so kind a difficult for independent personal developers.

For one thing, current USB-based Windows display driver must be "user mode" drivers. No new kernel mode driver is required (because of USB). This means that the signature requirement is a bit easier or even not necessary than the kernel driver (I don't know the exact requirements here...) .