Re: [PATCH libdrm] Synchronize drm/drm_fourcc.h with Linux’ version

[Daniel Stone]

Hey,

On 27 January 2016 at 14:23, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 27 January 2016 at 13:31, Daniel Stone <daniel at fooishbar.org> wrote:
>> On 27 January 2016 at 13:28, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 27 January 2016 at 11:42, Daniel Stone <daniel at fooishbar.org> wrote:
>>>> On 27 January 2016 at 09:38, Daniel Vetter <daniel at ffwll.ch> wrote:
>>>>> On Tue, Jan 26, 2016 at 09:04:18PM +0000, Emil Velikov wrote:
>>>>>> I've been procrastinating^Wwaiting on some upstream changes to land
>>>>>> and with those in place I'll update the Makefile to import things
>>>>>> properly.
>>>>>
>>>>> Yeah, we should have some scripts in libdrm that runs make
>>>>> headers_install, copies over the latest generated uapi headers for drm and
>>>>> then creates a commit with the sha1 it was generated from. Maybe even a
>>>>> rule that the sha1 has to be from Dave's drm-next.
>>>>
>>>> Yeah, it's certainly doable, once some kernel-internal details are
>>>> shuffled out of uapi/drm/drm_mode.h.
>>> What do you have in mind - DRM_MODE_PICTURE_ASPECT_* ? I'm thinking
>>> more that we should bring back DRM_MODE_OBJECT_* as it breaks libdrm
>>> and maybe other userspace.
>>>
>>> Feel free to let me know here or in the patch I just sent (didn't
>>> realise and I Cc'd your collabora email).
>>
>> More the *_FLAGS enums:
>> 12:26 PM <danvet> daniels, what kind of kernel internals in
>> include/uapi/drm/drm_mode.h?
>> 12:26 PM <daniels> danvet: DRM_MODE_FB_DIRTY_FLAGS,
>> DRM_MODE_CURSOR_FLAGS, DRM_MODE_PAGE_FLIP_FLAGS, DRM_MODE_ATOMIC_FLAGS
>> 12:27 PM <daniels> danvet: not strictly kernel-internal per se, but
>> does encourage userspace to do stupid validation on a potentially
>> outdated (or too-new; either way the result is incorrect) set of flags
>> 12:27 PM <danvet> hm well, don't mind those too much really
>> 12:27 PM <danvet> better than keeping them separate at least
>> 12:28 PM <daniels> why not just move them into the kernel and leave
>> userspace to work it out for itself?
>> 12:29 PM <daniels> i can't see the space for userspace using them at
>> all; if you're needing to test for specific flags, then do that, but
>> the only case for exposing the _FLAGS mask is to validate that you're
>> not passing 'unsupported' flags (not 'flags i don't know about', since
>> just use individual flags yourself for that, but 'flags the kernel
>> doesn't know about'), which is a) pointless, and b) likely to be
>> incorrect
>>
> Silly me should have checked the logs first.
>
> While I agree with your points I'm slightly worried that some of these
> are already part of the API. So as long as a volunteer goes through
> the history and checks that we don't break existing apps (libdrm,
> mesa, ddxen, xserver, wayland and other compositors, dvdhrm's kmscon
> and others?) I would love to see them do ;-)

Well, not in libdrm Mesa, the X server or Intel driver, Weston,
Mutter, or Chromium ... haven't checked kmscon, Enlightenment or other
DDXes, but I'd be shocked if they did use it; if you're generating the
pageflip flags in the first place yourself, why would you then need to
filter them against a bitmask .,.. ?

Cheers,
Daniel