Re: [git pull] drm fixes

Michel Dänzer
2011-03-23T09:35:57Z

On Mit, 2011-03-23 at 19:06 +1000, Dave Airlie wrote:
> 2011/3/23 Michel Dänzer <michel@daenzer.net>:
> > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
> >> 2011/3/23 Michel Dänzer <michel@daenzer.net>:
> >> > On Mit, 2011-03-23 at 04:18 +0000, Dave Airlie wrote:
> >> >>
> >> >> One radeon, 2 core fixes, and an interface update to allow for > 2 crtcs
> >> >> in vblank.
> >> >
> >> > [...]
> >> >
> >> >> Ilija Hadzic (1):
> >> >> drm/kernel: vblank wait on crtc > 1
> >> >
> >> > This patch was still being debated yesterday, are you deliberately
> >> > pushing it regardless? Once it hits mainline, it'll be pretty much set
> >> > in stone.
> >>
> >> From what I can see it was the userspace patches being debated, this
> >> one seemed fine and the interface looked okay to me.
> >
> > The author ignored my suggestions to make the patch smaller and simpler,
> > more maintainable and more future-proof all at once.
>
> It was already small and I'm not sure merging the flags made it more
> maintainable.

Having two holes between _DRM_VBLANK_FLAGS_MASK,
_DRM_VBLANK_HIGH_CRTC_MASK and _DRM_VBLANK_TYPES_MASK can unnecessarily
complicate future extensions.

> Its always being a slightly painful ioctl, and hopefully any future
> changes add a new ioctl esp if we want 64-bit values.

Is there really a problem with assuming that if the 32-bit value went
backwards, the upper 32 bits have incremented by 1? 1 << 32 refreshes is
about 2 years, so I can't really see any ambiguity there. For hardware
that doesn't have 64 bit frame counters (does any have that yet?),
something like that needs to be done at some level anyway.

Anyway, that's another discussion...

--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer