On Mon, Mar 22, 2021 at 10:20:45AM +0100, Lucas Stach wrote: > Hi Christian, > > Am Montag, dem 22.03.2021 um 09:54 +0100 schrieb Christian Gmeiner: > > Am Sa., 20. März 2021 um 20:11 Uhr schrieb Daniel Vetter <daniel@xxxxxxxx>: > > > > > > On Sat, Mar 20, 2021 at 10:28 AM Christian Gmeiner > > > <christian.gmeiner@xxxxxxxxx> wrote: > > > > > > > > Hi Lucas > > > > > > > > Am Fr., 19. März 2021 um 20:06 Uhr schrieb Lucas Stach <l.stach@xxxxxxxxxxxxxx>: > > > > > > > > > > Vivante TS (tile-status) buffer modifiers. They can be combined with all of > > > > > the Vivante color buffer tiling modifiers, so they are kind of a modifier > > > > > modifier. If a TS modifier is present we have a additional plane for the > > > > > TS buffer and the modifier defines the layout of this TS buffer. > > > > > > > > > > > > > I am unsure why you want to have the TS modifiers in drm_fourcc.h. Can > > > > you share some insight on this? > > > > > > It's the official registry for drm_fourcc codes and drm modifiers. > > > Whether the kernel ever uses it or not doesn't matter. > > > > Fair point.. but I do not see any usage of these TS modifiers in mesa > > - that's why I am asking. > > I have a Mesa series using those modifiers, which I'm currently > rebasing and will be posted shortly. However, the way things work is: > first get the modifier into drm_fourcc.h, then merge any code using the > new modifiers, so I figured it would be fair game to post this patch > before I fully finished reworking the Mesa series. Generally post poth sides, and then _merge_ them in the order you described. Christian has a good point that generally for modifiers that mesa is expected to use, we want to have the mesa code as demonstration that they work. Especially for r/e'ed drivers where there's not authoritative spec. I was just assuming that this has happened already. -Daniel PS: Since this comes up all the time, relevant part of the upstream docs: "The kernel patch can only be merged after all the above requirements are met, but it must be merged to either drm-next or drm-misc-next before the userspace patches land. uAPI always flows from the kernel, doing things the other way round risks divergence of the uAPI definitions and header files." https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
