Mir on vmwgfx

[Thomas Hellstrom]

On 11/05/2013 08:42 AM, Daniel van Vugt wrote:
> Thanks Thomas, nice work.
>
> Would you be able to log the individual problems separately here; ?
> https://bugs.launchpad.net/mir/+filebug
>

Sure, will do that.
/Thomas


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