On 27 January 2016 at 13:31, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > Hi, > > On 27 January 2016 at 13:28, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >> On 27 January 2016 at 11:42, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: >>> On 27 January 2016 at 09:38, Daniel Vetter <daniel@xxxxxxxx> 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 ;-) Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
