mir_buffer_usage_software produces incorrect colours / pixel format

[Daniel van Vugt]

Using mir_buffer_usage_software produces the wrong colours.

The documentation says:
/**
 * The order of components in a format enum matches the
 * order of the components as they would be written in an
 * integer representing a pixel value of that format.
 *
 * For example, abgr_8888 corresponds to 0xAABBGGRR, which will
 * end up as R,G,B,A in memory in a little endian system, and
 * as A,B,G,R in memory in a big endian system.
 */
This sounds logical and portable. No byte swapping is ever required in the client.

And my system says I get: mir_pixel_format_abgr_8888

However on screen I don't get the right colours unless I draw 0xAARRGGBB. That's clearly wrong no matter how you interpret the endian-ness.

[Daniel van Vugt (vanvugt)]

Demo: https://code.launchpad.net/~vanvugt/mir/multiwin/+merge/160558

[Daniel van Vugt (vanvugt)]

Using intel graphics on raring by the way.

[Daniel van Vugt (vanvugt)]

I oh see the problem...

void MirSurface::get_cpu_region(MirGraphicsRegion& region_out)
{
    auto buffer = buffer_depository->current_buffer();

    secured_region = buffer->secure_for_cpu_write();
    region_out.width = secured_region->width.as_uint32_t();
    region_out.height = secured_region->height.as_uint32_t();
    region_out.stride = secured_region->stride.as_uint32_t();
    //todo: fix
    region_out.pixel_format = mir_pixel_format_abgr_8888;

    region_out.vaddr = secured_region->vaddr.get();
}

[Daniel van Vugt (vanvugt)]

The problem is that my system really is using ARGB. And the comment in src/client/mir_surface.cpp shows that Mir just doesn't return the correct pixel_format yet :(

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:mir at revision 662, scheduled for release in mir, milestone 0.0.3