Please confirm the version of tigervnc-server in use.

tigervnc-1.4.2-3.fc22.s390x
and
tigervnc-1.4.2-3.fc22.ppc64

Do you need me to take some action, or does 'should be fixed in the next compose' mean that a fix is already made and there is nothing for me to do?

Yes, nothing to do for you at the moment, we should already have all the necessary bits rebuilt, so this issue should go away in the next compose. But we want to track it.

moving to Beta tracker, so we will recheck it with the Beta composes

Tim, seems there is a real problem with VNC on big endians, even with the latest tigervnc-1.4.3-2.fc22 the colours are still wrong

Created attachment 1012163 [details]
XFCE desktop over VNC from F-22 ppc64

Can be reproduced by connecting from eg. F-20 client connecting to XFCE desktop running on ppc64 (big endian) F-22 host.

and using tigervnc-server-1.4.2-3.fc22.ppc64

http://ppc.koji.fedoraproject.org/kojifiles/packages/xorg-x11-server/1.17.1/2.fc22/data/logs/ppc64/build.log <- is this the build log for the xorg-x11-server that would have been in the build root for the most recent tigervnc build?

If so, it looks ok: "checking whether byte ordering is bigendian... yes"

That sets the IMAGE_BYTE_ORDER and BITMAP_BIT_ORDER macros that hw/vnc/* uses.

In which case it shifts the investigation to the over-the-wire data: so could you please run tcpdump to capture the RFB traffic when connecting?

tcpdump -U -s0 -w rfb.pcap port 5900

Created attachment 1012297 [details]
f22-beta-tc2-vnc1.jpg

Created attachment 1012299 [details]
f22-beta-tc2-vnc2.jpg

Created attachment 1012300 [details]
f22-beta-tc2-vnc3.jpg

I downgraded to tigervnc-server-1.3.1-11.fc22.ppc64 from a running system and it still shows wrong colors. But, some of the fluxbox themes are partially drawn with correct colors. However, I see also some strange artifacts in some cases. For example the default theme has some fonts mirrored from the right to the left. The green theme has fonts mirrored, but the colors are correct. See the attachments.

(In reply to Tim Waugh from comment #9)
> http://ppc.koji.fedoraproject.org/kojifiles/packages/xorg-x11-server/1.17.1/
> 2.fc22/data/logs/ppc64/build.log <- is this the build log for the
> xorg-x11-server that would have been in the build root for the most recent
> tigervnc build?
> 
> If so, it looks ok: "checking whether byte ordering is bigendian... yes"
> 
> That sets the IMAGE_BYTE_ORDER and BITMAP_BIT_ORDER macros that hw/vnc/*
> uses.

the build is
http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=298677
and has the endianity detected correctly

> In which case it shifts the investigation to the over-the-wire data: so
> could you please run tcpdump to capture the RFB traffic when connecting?
> 
> tcpdump -U -s0 -w rfb.pcap port 5900

Need the TCP capture for further analysis.

Created attachment 1012647 [details]
packet capture for connecting to the XFCe session

You can also access the ppc64 machines we use for testing.

This is an xorg-x11-server bug.

In include/servermd.h:

#if X_BYTE_ORDER == X_LITTLE_ENDIAN
#define IMAGE_BYTE_ORDER        LSBFirst
#define BITMAP_BIT_ORDER        LSBFirst
#elif X_BYTE_ORDER == X_BIG_ENDIAN
#define IMAGE_BYTE_ORDER        MSBFirst
#define BITMAP_BIT_ORDER        MSBFirst
#else
#error "Too weird to live."
#endif

We do know that X_BYTE_ORDER gets defined correctly, from this line in configure.ac:

AC_C_BIGENDIAN(AC_DEFINE(X_BYTE_ORDER, X_BIG_ENDIAN, [byte order]),
               AC_DEFINE(X_BYTE_ORDER, X_LITTLE_ENDIAN, [byte order]))

combined with this line in the build output:

checking whether byte ordering is bigendian... yes

In order words, we definitely have:

#define X_BYTE_ORDER X_BIG_ENDIAN

However, where is X_BIG_ENDIAN defined? Well, that comes from X11/Xarch.h. But is it included whenever servermd.h is? No.

by adjusting servermd.h as follows and rebuilding the problem becomes clear:

#if !defined(X_LITTLE_ENDIAN) || !defined(X_BIG_ENDIAN)
#error Include X11/Xarch.h before servermd.h
#endif

e.g.:

In file included from mibitblt.c:63:0:
../include/servermd.h:56:2: error: #error Include X11/Xarch.h before servermd.h
 #error Include X11/Xarch.h before servermd.h

and, crucially,

In file included from ../../randr/randrstr.h:46:0,
                 from XserverDesktop.h:45,
                 from vncExtInit.h:26,
                 from xvnc.cc:39:
../../include/servermd.h:56:2: error: #error Include X11/Xarch.h before servermd.h
 #error Include X11/Xarch.h before servermd.h

Changing component to xorg-x11-server as the problem seems not to be limited to tigervnc (see the mibitblt.c case above).

I think it makes the most sense to just include Xarch.h from the config headers.  I'm building that change in xorg-x11-server-1.17.1-8, can you rebuild against that and test?

Not sure how to rebuild against that candidate build for ppc64, so I've pulled in the relevant patch and have applied it explicitly in this build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=627087

Thanks Adam, works in my testing.

Ajax, yes, your fix in xorg-x11-server-1.17.1-8 works, please submit an update in bodhi.

Version 1.17.1-9.fc22.ppc64 is included in Fedora 22 ppc64 Beta_RC1, and it works correctly. Closing.