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

Daniel Stone daniel at fooishbar.org
Wed Jan 27 05:31:54 PST 2016


Hi,

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

Cheers,
Daniel


More information about the dri-devel mailing list