XMir now on vmwgfx
thellstrom at vmware.com
Fri Dec 20 07:45:01 UTC 2013
Thanks for the reply.
On 12/20/2013 03:25 AM, Daniel van Vugt wrote:
> 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:
> 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?...
> /* DDX code in which mastership won't be dropped */
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).
> 2) The pixel format of the XMir surface appears to be fixed at
> mir_pixel_format_xrgb_8888 right now. See:
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.
> 3) I'm not sure. But the region comes from xmir_window_get_dirty(), here:
OK. I guess I need to dig a bit deeper into this.
> - Daniel
> On 19/12/13 21:08, Thomas Hellstrom wrote:
>> 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
>> 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
>> 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
>> Thomas Hellstrom
More information about the Mir-devel