On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
> On Tue, Mar 25, 2014 at 04:57:04PM +0000, Damien Lespiau wrote:
> > On Tue, Mar 25, 2014 at 04:38:24PM +0000, Chris Wilson wrote:
> > > For the record,
> > >
> > > 16:30 < agd5f> ickle, our GPUs don't have selectable cursor sizes
> > > 16:31 < agd5f> so on the newer ones, xf86-video-modesetting, etc. would
> > > allocate a 64x64 cursor and it would look squashed and funky since the
> > > hw expects 128x128
> > >
> > > Which means I was confused when I thought part of the reasoning was
> > > indeed HiDPI support. (I'm still seem to remember that was part of the
> > > argument for large cursors anyway.)
> > >
> > > > Are you saying the Intel DDX currently derives a different meaning to
> > > > the intented behaviour? in which case it can still be changed to not do
> > > > that?
> > >
> > > I still disagree though. This provides all the information I need to
> > > support variable sized cursors and we can use large cursors today.
> >
> > I'd love the game to be about defining clear semantics more than "by
> > interpreting that value this way, I got what I always wanted" :)
> >
> > We can resolve that today with MAX_CURSOR_WIDTH, MAX_CURSOR_HEIGHT caps
> > as well (if you're alluding at the fact that drm_planes may still be a
> > few decades away).
> >
> > We'll still need to expose the full list of supported cursor sizes for
> > compositors at some point or another, my preferred way would be with a
> > property in the exposed cursor drm_plane.
>
> For the record I'll restate my comment here about the larger problem:
>
> Atm we have no way for userspace to figure out per-plane limits on
> sizes/strides, we only expose a lists of supported pixel formats.
>
> Imo exposing cursor limits is just part of this larger issue, so if we can
> get the current stuff working with some legalese, then I'm ok with that.
> Solving the larger issue is much more work, and it's better to have a few
> more odd cases working than not. For planes I guess we could have a few
> limits:
>
> min/max width height in pixels
> min/max stride
> alignment of stride
>
> And a pile of flags
> - needs pot stride/width/height
> - needs square size
Already new ones:
- stride must match width*bpp
This will be fun if we ever do it ...
-Daniel
>
> That should be enough to cover most single-plane things. For multiplanar I
> guess we might either just need 2nd/3rd set of those or some additional
> stuff expressed in flags (e.g. subsampled strides must be half of the Y
> stride). Or we'll throw our hands in the air for multi-planar for now ;-)
>
> Or we simply do this per-pixel format with one for each framebuffer plane,
> i.e.
>
> struct drm_get_plane_fb_limits {
> uint32_t plane_id; /* in */
> uint32_t fourcc; /* in */
> struct drm_plane_limits limits[MAX_FOURCC_PLANES];
> /* the stuff above for all possible planes of a fourcc code */
> }
>
> Saner drivers could then return the same thing for all fourccs codes in
> their backend.
>
> Just something to ponder.
>
> Adding dri-devel, maybe we can get this discussion started.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
