On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote: > On Thu, 9 Feb 2023 13:51:05 +0200 > Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx> wrote: > > > Maybe we could refine this so that userspace uses the stride and height > > implied by the caps for allocation, and then use the exact cursor image > > size for AddFB2? And have drivers pick any size between those two they > > can use. The kernel would need the userspace to promise that the > > padding is always zero-initialized, so the driver can simply scan out > > any area of the buffer it needs. > > > > Then we don't need SIZE_HINTS. > > Would there be any problem with this? > > If this works, it would seem the superior solution to me, because > userspace does not need to guess or test for the exact right size. > Simply allocate at the CAP size, pad the cursor image with transparent > pixels, and let the kernel scan out the optimal area. No, the hardware cannot scan out a smaller area because the stride will be wrong. > > And if the kernel needs to do a pixel format conversion, it only needs > to do the optimal minimum amount of work. Involving the CPU (or GPU I suppose but that could involve big extra latencies) in the kernel to massage the pixels around every time seems extremely sub-optimal. Seems like we might as well use a software cursor at that point. -- Ville Syrjälä Intel