Mir on vmwgfx

[Daniel van Vugt]

Thanks Thomas, nice work.

Would you be able to log the individual problems separately here; ?
https://bugs.launchpad.net/mir/+filebug


On 05/11/13 15:22, Thomas Hellstrom wrote:
> Hi!
>
> I'm new to this list and I'm trying to get Mir running in a VMware
> virtual machine on top of the vmwgfx driver stack.
> The idea is to first get "mir_demo_server_basic" running with demo
> clients and then move on to Xmir, patching up our drivers as necessary.
>
> So far, I've encountered a couple of issues that might need attention
> from MIR developers:
>
> 1) function mggh::DRMHelper::is_appropriate_device() in
> gbm_display_helpers.c checks whether a drm device has any children
> except itself. This is not true for vmwgfx, and the server will fail to
> start thinking that our drm device is not appropriate. Why the child
> requirement?
>
> 2) Once I get the basic server to start, the cursor disappears as soon
> as I move the mouse. This boils down to Mir thinking that the cursor is
> outside of the current mode bounding box. At Mir server startup, there
> is no KMS setup configured, hence
> DisplayConfigurationOutput::current_mode_index will be set to max (or
> -1) in mgg::RealKMSDisplayConfiguration::add_or_update_output().
> The value of DisplayConfigurationOutput::current_mode_index then doesn't
> seem to change even when Mir sets a display configuration, and when the
> mode bounding box is calculated, an out of bounds array access is
> performed.
>
> 3) Minor thing: The "Virtual" connector type is not recognized by Mir.
> (actually it's not in xf86drmMode.h either, I'll see if I can fix that
> up), but it's in the kernel user-space api file "drm_mode.h" and is
> right after the "eDP" connector type. Should be added in
> connector_type_name() in real_kms_output.cpp
>
> 4) vmwgfx does not yet implement the drm "Prime" mechanism for sharing
> of dma buffers, which Mir relies on. I'm about to implement that.
> However, it seems like Mir is using dma buffers in an illegal way:
> 1) Mir creates a GBM bufffer.
> 2) Mir uses Prime to export a dma_buf handle which it shares with its
> clients.
> 3) The client imports the dma_buf handle and uses drm to turn it into a
> drm buffer handle.
> 4) The buffer handle is typecast to a "dumb" buffer handle, and then
> mmap'ed. in struct GBMMemoryRegion : mcl::MemoryRegion.
>
> It's illegal to typecast a GBM buffer to a dumb buffer in this way. It
> accidently happens to work on the major driver because deep inside, both
> a GBM buffer and a dumb buffer is represented by a GEM buffer object.
> With vmwgfx that's not the case either for a GBM buffer or a dumb
> buffer, and they are different objects.
>
> In fact, currently the only way to mmap() a GBM buffer (unless it's a
> cursor buffer) is to export a dma_buf and use it's mmap() operation. But
> that is not implemented by any of the major drivers since it's not
> really desired. The reason is that a GBM buffer is completely opaque and
> may not even reside in mappable memory. Hence any attempt to map it may
> result in coherence issues and, in some cases, extremely costly
> operations. This results in awkward driver code that attempts to guess
> the usage-patterns of applications that mix mmap'ed cpu-access and
> accelerated access to the same object.
>
> The correct way to do this is to have the client import the buffer to
> the appropriate API, and use texsubImage like operations (or perhaps
> readPixels / writePixels) to access the buffer from the CPU.
>
> IMHO, I think this is something that needs to be addressed as soon as
> possible.
>
> Thanks,
> Thomas
>