On Tue, Feb 14, 2023 at 01:17:45PM +0200, Pekka Paalanen wrote: > 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. Yeah, probably some Windows legacy hangover that refuses to die. Ye olde Intel gen2 desktop chipsets (i845/i865) had a somewhat programmable stride for cursors (still POT, but could exceed the width), but the mobile chipsets (i830/i85x) did not. Unfortunately the mobile lineage won out and we've been stuck with this limitation ever since. -- Ville Syrjälä Intel
