On Mon, Jul 22, 2013 at 08:20:49AM +0010, Christopher James Halse Rogers wrote: > On Mon, 22 Jul, 2013 at 5:53 PM, Chris Wilson > <chris@xxxxxxxxxxxxxxxxxx> wrote: > >With xorgMir this is not going to fly. Make sure the compatibility > >cruft, first of all, exists and is out of line in a header. > > > > Do you mean remove the various #ifdef XMIR bits, or *all* the bits > gated on xorgMir? Some of that's not going to be trivial to hide > away in a header. It looked like it could be done quite simply. The most important part is to avoid the extern xorgMir - as that will be a major nuisance. > > And expose the driving heartbeat of when to refresh the screen > >pixmap from Xmir. > > > I'm not sure what you mean here - Xmir exposes the > on-buffer-available callback, which gets triggered when swap_buffers > has returned the next buffer to render to. This is what I'd think of > as the refresh heartbeat. Is this not what you mean? Yes, that's what it looked like. But I didn't see how that was being coupled into how fast we updated. > If you're rendering as fast as possible, this will be a > once-per-compositor-vblank event. That's what I would expect, so I am just missing the logic between that and us sending updates. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
