Hi,
On 27 January 2016 at 13:28, Emil Velikov emil.l.velikov@gmail.com wrote:
On 27 January 2016 at 11:42, Daniel Stone daniel@fooishbar.org wrote:
On 27 January 2016 at 09:38, Daniel Vetter daniel@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