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
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
