On Tue, Jul 29, 2014 at 3:03 PM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Tue, 29 Jul 2014 13:19:10 +0200 > Daniel Vetter <dan...@ffwll.ch> wrote: > >> On Tue, Jul 29, 2014 at 12:55:24AM -0700, Jason Ekstrand wrote: >> > I pushed this one. Let's get a follow-up that lets weston actually use the >> > bigger cursors. It would also be good to hack together a little client >> > that attaches a big cursor so we can verify that it's working. I don't >> > think we need to put it in the repo, I'd just like proof that we're >> > actually taking advantage of our new-found big cursors. >> >> Just an aside: With recent kernels intel hw supporst 64x64, 128x128 and >> 256x256. On all generations (down to gen2). > > Ok, so which one of those will we get through drmGetCap()? > > I think it would not be nice, if we receive the values 256x256, > because then Weston will pad *all* cursor images to 256x256, > even if 64x64 would suffice. So possibly quite a waste there, first > memcpy and then full-sized gbm_bo_write for every cursor change. > > If drmGetCap returns 64, 128, or 256, how would we infer all the > valid sizes? All powers-of-two larger than 64x64, included? Is > e.g. 64x256 valid?
I added the drmGetCap cursor support for radeon as our hw only supports fixed size hw cursors and there is other hardware out there with similar limitations. I'm not sure what the best way to handle this would be for hw that supports multiple cursor sizes. I think perhaps the recent KMS overlay/plane changes cover this by exposing cursors as planes. Alex _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
