On Tue, 14 Feb 2023 12:27:45 +0200 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > 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. In another email of yours you said that hardware requires stride to be equivalent to the width. So it's not that hardware supports only specific strides, it must equal to width. That's really unfortunate and surprising. > > > > 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. I meant drivers that already do that anyway, because they cannot scan out ARGB8888 on the cursor plane. Thanks, pq
Attachment:
pgpa03wWiaikb.pgp
Description: OpenPGP digital signature
