XMir now on vmwgfx
Christopher James Halse Rogers
raof at ubuntu.com
Fri Dec 20 07:59:04 UTC 2013
On Fri, 2013-12-20 at 08:45 +0100, Thomas Hellstrom wrote:
> Thanks for the reply.
> On 12/20/2013 03:25 AM, Daniel van Vugt wrote:
> > Thomas,
> > Excellent work, thanks.
> > The two people best placed to answer your questions are now on
> > vacation, but I shall try;
> > 1) There is no explicit message that DRM mastership has been dropped.
> > Mir will just block in the page flip while the (Mir) server is no
> > longer consuming buffers:
> > https://urldefense.proofpoint.com/v1/url?u=https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-window.c%23L149&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=OZU2uhMnuCLeFGemU2b1KMBMAOfsNVVUYP8oK4asWXQ%3D%0A&s=b5554ffe56b763b91618a403405d0a7f02c321e648c7095e828fba712ec8a6c5
> > But that happens after the drop of mastership so there's still a
> > potential race between the server dropping it, and the DDX rendering.
> > Worst case is that the DDX could render 2 frames before filling the
> > queue and then no more will be requested until the server resumes. Is
> > it more than 2 extraneous frames you're seeing? Or is two still a
> > problem for the DDX? Do we need something like this?...
> > mir_drm_lock();
> > /* DDX code in which mastership won't be dropped */
> > mir_drm_unlock();
> Actually, it's more an issue of DRM security: Is a client allowed to use
> DRM after its master has dropped? The vmwgfx kernel module blocks any
> such attempts (but I'm not sure that is the right solution).
All the hardware DRM drivers support rendering while not-master; master
is only required for modesetting, IIRC (which XMir doesn't do). Mir will
switch to handing out rendernodes at some point, as our clients don't
need flink, and you can always render to a rendernode; they don't *have*
> In the XMir
> case, that should be OK, as long as XMir itself is allowed to block like
> that, and I guess if it would otherwise block in the Mir pageflip that
> should be OK. Bare X would typically not block since it's
> single-threaded and that would stop it from becoming master again.
> Blocking might however be an issue for X clients with critical timing
> like Xv video players, that would need to start dropping frames.
> I think, if anything, one should consider using enterVT / leaveVT as a
> notification that master has been reclaimed / is about to be dropped.
> Drivers can then take appropriate action (drop Xv frames, software
> rendering, block DRI, much of what's done under bare X).
We could indeed hook up that notification if drivers want it.
> > 2) The pixel format of the XMir surface appears to be fixed at
> > mir_pixel_format_xrgb_8888 right now. See:
> > https://urldefense.proofpoint.com/v1/url?u=https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-output.c%23L311&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=OZU2uhMnuCLeFGemU2b1KMBMAOfsNVVUYP8oK4asWXQ%3D%0A&s=be4e70174e7d611985b4e17c6d63f0b1ce1ecfab9c62c9fb660ce4b3bc482f9f
> Hmm, yes, I was more referring to what might happen in the future and
> the semantics of the XMir interface.
> If there is a way for the DDX to obtain the format of the copy buffer,
> the DDX could run in whatever color-depth it prefers and just do a
> format-conversion blit when copying to Mir.
I intend (at some point ☺) to choose the Mir format based upon the X
visual format; xrgb8888 is just enough to cover all the standard
usecases we cared about!
Would that be sufficient, or would you additionally want to access to
the buffer format?
> > 3) I'm not sure. But the region comes from xmir_window_get_dirty(), here:
> > https://urldefense.proofpoint.com/v1/url?u=https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-window.c%23L169&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=OZU2uhMnuCLeFGemU2b1KMBMAOfsNVVUYP8oK4asWXQ%3D%0A&s=7b37a437c950b51cdd2b4c5950f98d72273471abcbb426b7a8b42c536a66e538
> OK. I guess I need to dig a bit deeper into this.
It's in the source window coordinates; you'll need to translate back by
xmir_window_get_drawable_region when you copy to the Mir buffer.
Once translated back it's guaranteed to fit inside the associated Mir
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Mir-devel