Subject: XMir now on vmwgfx

From: Thomas Hellstrom <[email-masked]>
Date: Thu, 19 Dec 2013 14:08:10 +0100

Hi!

I just pushed a branch "hosted" to xf86-video-vmware that enables XMir
(and also XWayland). It will probably not be part of next release which
might happen very soon, but probably with the next release. I'm not sure
what X support on Mir will look like in the end, but all XMir - specific
code is confined to a single file, so it should be easy to change if needed.

Performance seems OK, given that the vmwgfx driver fakes pageflipping
with multiple fullscreen copies. This also means that performance of
XMir compared to bare Xorg might look a bit bad.

A couple of outstanding issues:

1) When Mir VT switches, I guess it drops DRM master. Still, from what I
can tell, the XMir driver is not informed, and may attempt to continue
to render using the drm file-descriptor. Is there a way to inform the
driver about this?
2) I'd like to have a way to get the pixel format of the XMir copy
buffer. I guess it's whatever GBM gives Mir for a given depth, but is it
safe
to assume that the depth of the XMir copy buffer is identical to the
depth of the source window drawable?
3) Is the region given as the second argument to xmir_window_proc
relative to the source window drawable or relative to the underlying pixmap?

Thanks,
Thomas Hellstrom

---

From: Thomas Hellstrom <[email-masked]>
Date: Thu, 19 Dec 2013 14:11:44 +0100

> relative to the source window drawable or relative to the underlying pixmap?

Oh, and I forgot. If anyone wants to try it out, it needs kernel 3.13
(currently in RC), and
a mesa with XA version 2 or later.

/Thomas

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 20 Dec 2013 10:25:44 +0800

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://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-window.c#L149
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();

2) The pixel format of the XMir surface appears to be fixed at 
mir_pixel_format_xrgb_8888 right now. See:
https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-output.c#L311

3) I'm not sure. But the region comes from xmir_window_get_dirty(), here:
https://github.com/RAOF/xserver/blob/vladmir-upstreaming/hw/xfree86/xmir/xmir-window.c#L169

- Daniel

---

From: Thomas Hellstrom <[email-masked]>
Date: Fri, 20 Dec 2013 08:45:01 +0100

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;
>
> 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
>
> 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();

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). 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).

> 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.

> 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.

Thanks,
Thomas

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Fri, 20 Dec 2013 15:59:04 +0800

On Fri, 2013-12-20 at 08:45 +0100, Thomas Hellstrom wrote:
> 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.

>  In the XMir

We could indeed hook up that notification if drivers want it.

> 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?

> 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
buffer.

Chris

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Fri, 20 Dec 2013 16:17:02 +0800

> need flink, and you can always render to a rendernode; they don't *have*

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

---

From: Thomas Hellstrom <[email-masked]>
Date: Fri, 20 Dec 2013 09:28:59 +0100

> need flink, and you can always render to a rendernode; they don't *have*

Yes, rendernodes is a different thing, but the question is whether the
hardware DRM drivers *support* it or whether that's a security bug;
rendering as an authenticated client is OK, but when the master that
authenticated has dropped (or died) and there is another master, I'd say
that's a security violation, but that's not a Mir problem but a DRM problem.

> We could indeed hook up that notification if drivers want it.

Yes, I think that could be useful.

> Would that be sufficient, or would you additionally want to access to

For vmwgfx, we can always obtain the buffer format from the kernel,
since we're using typed surfaces as shareable objects, but thinking of
a generic solution I think there should be an xmir function to get the
format. Perhaps just a convenience function that uses the drawable depth?

Another thing that springs to my mind is that it would be good to be
able to cache the copy buffer handle to avoid two kernel calls for each
xmir_copy_to_mir() window. We can't do that right now because we can't
guarantee that an fd is not reused for a new copy buffer if the old one
is destroyed.

Thanks,
Thomas

---

From: Thomas Hellstrom <[email-masked]>
Date: Fri, 20 Dec 2013 09:31:40 +0100

> support, you don't have to add it for our benefit)
Yes, adding rendernodes is in our to-do list.

/Thomas