XMir now on vmwgfx

[Christopher James Halse Rogers]

On Fri, 2013-12-20 at 15:59 +0800, Christopher James Halse Rogers wrote:
> On Fri, 2013-12-20 at 08:45 +0100, Thomas Hellstrom wrote:
> > Hi,
> > 
> > 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*
> associated masters.

(Rendernodes if supported; if you're not planning on adding rendernode
support, you don't have to add it for our benefit)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131220/9e8567e9/attachment-0001.pgp>