On Thu, Mar 23, 2017 at 6:16 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi, > > On 8 March 2017 at 05:31, Ben Widawsky <b...@bwidawsk.net> wrote: > > Unlike stride, there was no previous offset getter, so it can be right > > on the first try. > > > > v2: Return EINVAL when plane is greater than total planes to make it > > match the similar APIs. > > Avoid leak after fromPlanar (Daniel) > > Make sure when getting offsets we consider dumb images (Daniel) > > > > v3: Use Jason's recommendation for handling the non-planar case. > > > > v4: Return int64_t so we can get real errors > > I really wish I'd caught this earlier. :( > > Returning int64_t is annoying because the relevant interface demands > we need uint32_t, so we need to do casts in users. Given that the > offset is useless without the handle/fd, and we have real error values > for those (0 for handle, -1 for fd) which don't require casts, I'd > much rather this was just a uint32_t returning 0 on failure. > > Oh well. If it's too late to change then fine, but if we could change > it, it would make life a little easier. > I'm ok with changing it given that we know there are zero users and it's been in-tree for all of a week. The only problem is that 0 is a perfectly valid offset. I think we could use (uint32_t)-1 and that would probably be safe.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev