Re: [PATCH 00/24] drm_framebuffer boilerplate removal
On Fri, Mar 30, 2018 at 11:00 AM, Daniel Stone wrote: > Hi Alex, > > On 30 March 2018 at 15:47, Alex Deucher wrote: >> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: >>> I intend to remove create_handle when all drivers are converted over >>> to placing BOs directly inside drm_framebuffer. For most drivers >>> there's a relatively easy conversion to using the helpers for >>> basically all framebuffer handling and fbdev emulation as well, though >>> that's a bit further than I was willing to go without hardware to test >>> on ... >> >> Series is: >> Acked-by: Alex Deucher > > Thanks a lot for the review! Are you taking the radeon/amdgpu patches > through your tree? They don't have any dependencies on core code. Sure. I'll grab them now. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/24] drm_framebuffer boilerplate removal
Hi Alex, On 30 March 2018 at 15:47, Alex Deucher wrote: > On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: >> I intend to remove create_handle when all drivers are converted over >> to placing BOs directly inside drm_framebuffer. For most drivers >> there's a relatively easy conversion to using the helpers for >> basically all framebuffer handling and fbdev emulation as well, though >> that's a bit further than I was willing to go without hardware to test >> on ... > > Series is: > Acked-by: Alex Deucher Thanks a lot for the review! Are you taking the radeon/amdgpu patches through your tree? They don't have any dependencies on core code. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/24] drm_framebuffer boilerplate removal
On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: > Hi, > I've been working on a getfb2[0] ioctl, which amongst other things > supports multi-planar framebuffers as well as modifiers. getfb > currently calls the framebuffer's handle_create hook, which doesn't > support multiple planes. > > Thanks to Noralf's recent work, drivers can just store GEM objects > directly in drm_framebuffer. I use this directly in getfb2: we need > direct access to the GEM objects and not a vfunc in order to not hand > out duplicate GEM names for the same object. > > This series converts all drivers except for nouveau, which was a > little too non-trivial for my comfort, to storing GEM objects directly > in drm_framebuffer. For those drivers whose driver_framebuffer struct > was nothing but drm_framebuffer + BO, it deletes the driver-specific > struct. It also makes use of Noralf's generic framebuffer helpers for > create_handle and destroy where possible. > > I don't have the hardware for most of these drivers, so have had to > settle for just staring really hard at the diff. > > I intend to remove create_handle when all drivers are converted over > to placing BOs directly inside drm_framebuffer. For most drivers > there's a relatively easy conversion to using the helpers for > basically all framebuffer handling and fbdev emulation as well, though > that's a bit further than I was willing to go without hardware to test > on ... Series is: Acked-by: Alex Deucher > > Cheers, > Daniel > > [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/24] drm_framebuffer boilerplate removal
Hi, I've been working on a getfb2[0] ioctl, which amongst other things supports multi-planar framebuffers as well as modifiers. getfb currently calls the framebuffer's handle_create hook, which doesn't support multiple planes. Thanks to Noralf's recent work, drivers can just store GEM objects directly in drm_framebuffer. I use this directly in getfb2: we need direct access to the GEM objects and not a vfunc in order to not hand out duplicate GEM names for the same object. This series converts all drivers except for nouveau, which was a little too non-trivial for my comfort, to storing GEM objects directly in drm_framebuffer. For those drivers whose driver_framebuffer struct was nothing but drm_framebuffer + BO, it deletes the driver-specific struct. It also makes use of Noralf's generic framebuffer helpers for create_handle and destroy where possible. I don't have the hardware for most of these drivers, so have had to settle for just staring really hard at the diff. I intend to remove create_handle when all drivers are converted over to placing BOs directly inside drm_framebuffer. For most drivers there's a relatively easy conversion to using the helpers for basically all framebuffer handling and fbdev emulation as well, though that's a bit further than I was willing to go without hardware to test on ... Cheers, Daniel [0]: https://lists.freedesktop.org/archives/dri-devel/2018-March/170512.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
