[git pull] drm fixes
Michel Dänzer
michel at daenzer.net
Wed Mar 23 02:35:19 PDT 2011
On Mit, 2011-03-23 at 19:06 +1000, Dave Airlie wrote:
> 2011/3/23 Michel Dänzer <michel at daenzer.net>:
> > On Mit, 2011-03-23 at 18:16 +1000, Dave Airlie wrote:
> >> 2011/3/23 Michel Dänzer <michel at 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
More information about the dri-devel
mailing list