Re: [GIT PULL] exynos-drm-next

[Daniel Stone <daniel@fooishbar.org>]

Hi Inki,

On 15 November 2017 at 01:26, Inki Dae <inki.dae@samsung.com> wrote:
> 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
>> On 26 October 2017 at 11:37, Inki Dae <inki.dae@samsung.com> wrote:
>>>    Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
>>>        such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request
>>>        git pull one more time after review.
>>
>> I dropped the ball a bit here, I do think the second pull with IPP is
>> probably a bit late,
>> I think I'd like more assurance that the UAPI for IPP is to be used in
>> some upstream
>> shipping project (forks of mpv not withstanding, unless this fork
>> ships in some distro
>> or product).
>
> I also commented same thing internally to author - Marek - of IPP v2 but I thought existing one is really ugly thing so may be better to change it as soon as possible before other users use this one.
> Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux platform. I hope IPPv2 would be merged as soon as possible in next turn.

This is putting the cart before the horse a little bit. This is the
process for merging new DRM API:

Prepare the kernel and libdrm/etc patches exposing the new API, and
also develop a _real_ user for it. Using IPP as an example, an
acceptable userspace would be VLC, Kodi, Weston, Xorg, or similar.
libdrm sample clients are explicitly not enough for this.

Once this is done, you should get review/ack for all of these. The
kernel code and API should have review for good API (see for example
Daniel Vetter's 'botching up ioctls' documentation) and code, and the
userspace (VLC/Kodi/...) should have review for both code correctness
as well as an explicit check from the userspace side that they feel it
is good API which works for them. If the work just exists in a fork
which has not got real upstream review, this is also not enough.

When all parts have review, you can merge the new kernel API with a
pointer to the userspace review, explicitly stating that they feel it
is acceptable. Once the kernel code has landed in a non-rebasing tree
(one which Dave will be sending as a pull), libdrm code can be merged,
and then the userspace code can finally be merged.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel