Hey,
On 27 January 2016 at 14:23, Emil Velikov emil.l.velikov@gmail.com wrote:
On 27 January 2016 at 13:31, Daniel Stone daniel@fooishbar.org wrote:
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
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