Hi Matt, On Tue, 8 Jul 2014 16:51:24 -0700 Matt Roper <matthew.d.roper@xxxxxxxxx> wrote: > Hi Boris. > > I haven't really looked at any of your driver in depth, but from a quick > glance it looks like you're registering a cursor drm_plane (i.e., making > use of the new universal plane infrastructure), but you're also > providing an implementation of the legacy cursor ioctls (cursor_set and > cursor_move). There's some patches working their way through the > pipeline that should make this unnecessary and hopefully simplify your > life a bit: > > http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=c394c2b08e247c32ef292b75fd8b34312465f8ae > http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=b36552b32aa9c69e83a3a20bda56379fb9e52435 > http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662 > http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=fc1d3e44ef7c1db93384150fdbf8948dcf949f15 > > The third patch there is the one that's really important for your work. > When a driver provides a cursor plane via the universal plane interface, > cursor_set and cursor_move are automatically implemented for you by > drm_mode_cursor_universal() in drivers/gpu/drm/drm_crtc.c and your > legacy handlers will never get called. drm_mode_cursor_universal() will > take care of wrapping the bo's into a drm_framebuffer for you. > > When I added the universal cursor stuff, I wanted to make sure that as > soon as a driver starts supporting universal planes it can stop > supporting the legacy ioctls directly; otherwise handling refcounting > when userspace switches back and forth between calling legacy ioctl's > and calling setplane() on a cursor plane would be a nightmare. > > I think those patches are only available in drm-intel-nightly at the > moment and haven't moved on to drm-next and such yet, since i915 is the > only driver that currently has patches to make use of cursors via the > univeral plane interface (probably landing for kernel 3.17). That's great news. I knew there were some work in progress on this topic, but didn't know it was planned for 3.17. I'll move to this solution. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
