On 27 November 2015 at 02:11, Hyungwon Hwang <human.hwang@xxxxxxxxxxx> wrote: > Dear All, > > On Thu, 26 Nov 2015 16:35:29 +0000 > Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > >> Hi Tobias, >> >> On 22 November 2015 at 18:48, Tobias Jakobi >> <tjakobi@xxxxxxxxxxxxxxxxxxxxx> wrote: >> > Hello, >> > >> > this series mostly touches G2D code. It introduces the following: >> > >> > (1) drmHandleEvent2() is added to enable processing of >> > vendor-specific events. This will be used to expose asynchronous >> > operation of the G2D. The necessary kernel infrastructure is >> > already there since a lot of kernel versions. [This touches libdrm >> > core code!] >> > >> Considering the shortage of input on this can you please respin the >> series without it (and related work mentioned below). This way we can >> pick merge the remaining work now and discuss (ping) about the rest. > > I am confused a little here. Did you mean that adding drmHandleEvent2() > is not necessary, and the related code which uses drmHandleEvent2() must > be re-implemented? > I mean that there has been no interest/collaboration from anyone else. The shortage of userspace, doesn't help much either. Both of these can be hand-waved, somewhat, if this was exynos only change, but it isn't :-( Thus in order to not stall the remaining patches, I'm suggesting that we split this [and other patches that depend on it] into a separate/parallel series. >> >> > (2) The necessary infrastructure to handle G2D events. This includes >> > adding g2d_config_event() and g2d_exec2() to the public API. >> > A test application is provided to ensure that everything works >> > as expected. >> > >> With above in mind the g2d event will need to be split out, although >> g2d_exec2() should be ok (although of limited use), imho. >> >> > (3) A small performance test application which can be used to >> > measure the speed of solid color clear operations. Interesting for >> > benchmarking and plotting colorful graphs (e.g. through >> > Mathematica). >> > >> > (4) g2d_move() which works similar to g2d_copy() but like the C >> > memmove() properly handles overlapping buffer copies. >> > Again a test application is present to check that this >> > indeed does what it should. >> > >> > (5) Various small changes. A framebuffer colorformat fix for the >> > general G2D test application. Moving the currently unused >> > g2d_reset() to the public API. >> I am more of a "add API when it's needed" kind of person, although I >> cannot see anything serious misuse that can arise from g2d_reset(). >> >> > Adding a counterpart to >> > exynos_bo_map() to unmap buffers again. >> > >> The exynos bo map compatibility was broken a few times already so I'm >> wondering if we really want this one. I guess that with the lack of >> any (outside of tizen) user space things cannot go that wrong :-P >> > > Yes. I agree that adding them at this time is not needed and it would > be OK to add them, when the userspace using them comes. > You guys/gals are paving the way for exynos - so it's not my call to decide. I was just pointing out some questionable bits from the past. As I mentioned Tizen, do you plan on cleaning up your libdrm (and other?) patches and sending them over ? In case I haven't mentioned this before - feel free to come and join us on IRC channel #dri-devel (at FreeNode). Many kernel and userspace DRM developers hang out in there and you can poke, collaborate and discuss things in real time :-) This invite includes youself, other exynos DRM developers and everyone else interested. Thanks for the picking up Tobias' work, Hyungwon! Regards Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
