GLX apps (including Libreoffice Impress presentation mode) on ARM devices display wrong colors

[Leopoldo Pena]

GLX apps (including Libreoffice Impress presentation mode) on ARM devices display wrong colors

---
On the new BQ M10 tablet.

1- switch to desktop mode (manual, no external peripheral attached)
2- launch libreoffice
3- open impress file
4- colours in images are all messed up on the BQ M10 screen when toggle to presentation view.

[Pat McGowan (pat-mcgowan)]

Yes the colors do not match between editing and presentation modes, in edit mode they are as displayed on desktop.

[Christopher Townsend (townsend)]

I've done some investigating. With a Unity8 desktop system running on amd64 using Vivid plus the overlay PPA, the colors stay correct in Slide Show mode. So at this point, it's most definitely an issue specific to armhf and most likely an issue either in Mir of Xmir where the buffers get switched around somehow.

We will need one of those guys to look at this as that is a little out of my realm of knowledge:)

[Christopher Townsend (townsend)]

We're adding both Mir and Xmir to this as we aren't quite sure where the problem is.

[Daniel van Vugt (vanvugt)]

Confirmed (on krillin at least), in fullscreen presentation mode LibreOffice Impress gets the red/blue channels reversed.

[Daniel van Vugt (vanvugt)]

This might be a GLX problem. Simply running 'glxgears' gets the same colours mixed up.

[Daniel van Vugt (vanvugt)]

xwininfo/xdpyinfo seems to confirm the red and blue channels are reversed for GLX windows:

  visual:
    visual id: 0xb4
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits

versus non-GLX windows:

  visual:
    visual id: 0x28
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff, 0xff00, 0xff0000
    significant bits in color specification: 8 bits

However the problem is not as simple as changing a pixel format. Xmir is running in rooted mode, so we only get to choose one visual for the whole display at start-up. So we need to find a way to force GLX to use the correct visual, or to force XComposite to mix the colours correctly. Because it's really out of Mir's control...

[Daniel van Vugt (vanvugt)]

It's possible that a newer Mesa has fixed this problem already. Because a similar setup (LLVMpipe software rendering in Xmir) on desktop has no discolouration:

Working: xenial with Mesa 11.2.0 (desktop)
Broken: vivid with Mesa 10.5.9 (Ubuntu Phone stable channel)

P.S. If there's any way to tell LibreOffice to not use OpenGL, that might also help.

[Daniel van Vugt (vanvugt)]

Minor success. I've made a test available that you can use to replicate the bug using a desktop:
https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=637f0971b191c9fbdc459f3fdb7ba5bc479b84be

So this shows the problem is triggered by the priority order of supported pixel formats the Android platform returns. Mir's Android platform is returning the correct values in the correct order, but it's different to desktops, and that's enough to trigger this bug in Xorg.

It remains to be seen if the problem is an issue in Xorg that's always been there, or just something that Xmir is failing to initialize correctly.

Mir's Android graphics platform unfortunately does not support the same pixel formats as desktop that would avoid this bug. However adding ShmBuffer support to the Android platform would allow it to support all such pixel formats (and solve other bugs like the corruption issues).

[Adam (ajenkins-wisecat)]

I can confirm this on the new BQ M10 FHD tablet.

[Leopoldo Pena (leopenausa)]

Will this be targeted for OTA12? It is a major showstopper to use my tablet during public lectures.

[Daniel van Vugt (vanvugt)]

I can't yet confirm if this will be fixed in time for OTA-12. We have a lot of bugs and many more severe than this one.

[Leopoldo Pena (leopenausa)]

Alright, thanks. I just dont see the point of shipping impress preinstalled if it cannot be used for presentations.

Thanks again and keep up the good work.

[Daniel van Vugt (vanvugt)]

Spent more time reproducing the problem and looking for a solution today...

I believe the problem is that LibreOffice presentation mode is using OpenGL, which it doesn't use in windowed mode.

In presentation mode on a phone/tablet you are actually using Mesa with software rendering. And Mesa's supported pixel formats are the opposite RGB order to that supported by the Mir Android driver. So the red and blue channels are reversed.

We can't immediately make Mesa use Android's preferred XBGR format.
And we can't immediately make Android use Mesa's preferred XRGB format (until/unless we add ShmBuffer support for Android).

So the only option we have right now is to stop Libreoffice trying to use OpenGL/GLX on a phone. I think you can do that with this workaround and it appears to work for me:

Tools > Options >
LibreOffice > View >
Use hardware acceleration = OFF

[Pat McGowan (pat-mcgowan)]

@chris can we set this config workaround by default in the delivered package

[Christopher Townsend (townsend)]

@Pat,

Ok, I'll see if I can make some config that can be delivered in Puritine.

[Adam (ajenkins-wisecat)]

I can also confirm that the "Use hardware acceleration = OFF" workaround works. However, it also makes most custom animations stop working and makes slide transitions rather clunky. Simple slide design is necessary to make it useable.

As a university professor, I can testify to the need for this to work. Many profs are annoyed by having to take big, heavy laptops to various locations in order to do presentations. The first solution to enable profs to use the same software on desktops, laptops AND tablets for editing and displaying presentations will win a large portion of this market. Ubuntu looks well on its way to achieving this. My thanks to you all.

[Christopher Townsend (townsend)]

Given that it has been reported that turning hardware acceleration off causes other regressed behaviors, then I think forcing it off in some config setting in Puritine is probably not the right thing to do.

I'm really not sure what the right thing to do is though...

[Pat McGowan (pat-mcgowan)]

Seems one of the options from comment #13 is needed

[Daniel van Vugt (vanvugt)]

I'm also continuing to search for additional options today not mentioned in comment #13

[Leopoldo Pena (leopenausa)]

This is precisely my scenario. I'm a University professor and I would love
to give my lectures going around only with my Ubuntu tablet and not my
laptop.

On Thu, Jun 9, 2016 at 8:15 AM, Adam <email address hidden> wrote:

> I can also confirm that the "Use hardware acceleration = OFF" workaround
> works. However, it also makes most custom animations stop working and
> makes slide transitions rather clunky. Simple slide design is necessary
> to make it useable.
>
> As a university professor, I can testify to the need for this to work.
> Many profs are annoyed by having to take big, heavy laptops to various
> locations in order to do presentations. The first solution to enable
> profs to use the same software on desktops, laptops AND tablets for
> editing and displaying presentations will win a large portion of this
> market. Ubuntu looks well on its way to achieving this. My thanks to you
> all.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1573470
>
> Title:
> BQ M10 tablet. Libreoffice Impress presentation mode displays wrong
> colors
>
> Status in Canonical System Image:
> Confirmed
> Status in Mir:
> Invalid
> Status in Puritine:
> New
> Status in mir package in Ubuntu:
> Invalid
> Status in puritine package in Ubuntu:
> Invalid
> Status in xorg-server package in Ubuntu:
> Triaged
>
> Bug description:
> On the new BQ M10 tablet.
>
> 1- switch to desktop mode (manual, no external peripheral attached)
> 2- launch libreoffice
> 3- open impress file
> 4- colours in images are all messed up on the BQ M10 screen when toggle
> to presentation view.
>
> Can anyone confirm?
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1573470/+subscriptions
>

[Daniel van Vugt (vanvugt)]

I've just about exhausted all possibilities of fixing or working around this in Xorg/Xmir. Even when I remove all the Composite and GLX logic that adds the incorrect xRGB visuals, we still end up with backwards colours rendered by Mesa.

It seems quite difficult to drop the offending xrgb/argb pixel formats from the Mesa source code, and also difficult to top the Xorg codebase from assuming xrgb/argb is always available.

The only way forward I see right now is for us to redesign the Mir Android platform to use ShmBuffer for software buffers. As ShmBuffer easily supports the xrgb/argb pixel formats and then the colours will always be correct for the legacy logic of Xorg and Mesa.

[Daniel van Vugt (vanvugt)]

Good news! Maybe...

In comment #13 I said "We can't immediately make Mesa use Android's preferred XBGR format."

Turns out though that the imminent new Mesa 12 release adds the missing GBM_FORMAT_XBGR8888 that Android prefers:
   https://cgit.freedesktop.org/mesa/mesa/tree/src/gbm/backends/dri/gbm_dri.c?h=12.0#n542

It only appears in the Mesa 12 source code and not Mesa 11 (except by accident of our own making where the colours will appear backwards -> bug 1473901).

So it would appear that Mesa accepting the unsupported pixel format was a Mir bug 1473901. But that shouldn't matter starting in Mesa 12.x because upstream Mesa *seems* to support little endian GBM_FORMAT_XBGR8888 properly (which to Android is the same thing as big endian HAL_PIXEL_FORMAT_RGBX_8888).

Assuming it works and is not a mistake, Mesa 12.x will finally speak the same pixel format as Android, which might solve this bug.

[Daniel van Vugt (vanvugt)]

It's no mistake either:

https://lists.freedesktop.org/archives/mesa-dev/2016-April/113657.html

The change in Mesa 12.0 is specifically designed to support Android pixel formats. :)

[Daniel van Vugt (vanvugt)]

Upgrading to Mesa 12 unfortunately has not solved this bug.

I suspect however the idea will still work, and most likely that aforementioned enhancement in Mesa 12 is just unfinished and/or untested.

[Daniel van Vugt (vanvugt)]

Software clients using GBM_FORMAT_XBGR8888 display correctly now:

  mir_demo_client_multiwin -p2

It's only LLVMpipe/swrast that renders GBM_FORMAT_XBGR8888 backwards. Looks like maybe support for that format is missing in Mesa's LLVMpipe/swrast code?

[Daniel van Vugt (vanvugt)]

Just to clarify - it looks like the core of this bug is in Mesa. LLVMpipe doesn't yet understand the Android RGBX format (which is the same thing as GBM_FORMAT_XBGR8888 that was added in Mesa 12.0).

So ideally we should fix Mesa. We could also fix Mir (add ShmBuffer support to the android platform) but that's less likely to happen.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jaap Dekker (jm-dekker)]

I use Citix receiver to connect to my desktop at the office (Windows 7 / Office 2013) in libertine. Same problem as in Impress presentation mode. Colors are mixed up.

[Daniel van Vugt (vanvugt)]

Possibly also related ?

+ data.format = GBM_FORMAT_ARGB8888; /* TODO: Use mir surface format */

https://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git/plain/debian/patches/egl-platform-mir.patch?h=ubuntu