XMir now on vmwgfx

[Daniel van Vugt]

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


On 19/12/13 21:08, Thomas Hellstrom wrote:
> 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
>