Hi

I'm a little embarrassed to say that I'm running SUSE 10.3
still... I don't like to update while I'm in the middle of
a project and I haven't had a chance to update yet.

When I downloaded and installed QT4.4 I noticed
some of the images had inverted colourmaps when I built
my own software.

Now I am trying to finish a program in QT3 and it seems that
when reading certain data from a file I get some bizarre
values that seem to correspond to an endianness problem.
This would explain the earlier image colour problem.

According to QT I am running a big endian system. (See
documentation for QApplication::qSysInfo() to read it).
I am no expert on PPC but I read it is endian
selectable so I don't know if big endian is the correct
answer.

I don't know how it would be possible that QT could read the
wrong endianness from the OS yet all included software
has no problems... is it possible SUSE reports the "wrong"
endianness ?

thanks!

koan

Depending on the chip, it's endian-selectable. The architecture supports both ways but implementation of little-endian is sort of optional, and you need to build your kernel to support it anyway (at least, to let you select which way). If it doesn't support running in little-endian mode there are a few instructions which help in portability of data (load and automatically byteswap, and save and byteswap kind of things).

Generally, you'll run it big-endian for a lot of reasons, and the Linux kernel defaults to this.
No. This is probably just a library problem - perhaps some data from a Windows BMP is just being read out verbatim (it will be swapped because it's an x86, little-endian format. It may also be in the wrong colour order anyway (ARGB or BGRA instead of RGBA).

What exactly are you doing and what's the exact result?

_________________
Matt Sealey

Ah thanks, I wasn't sure how selectable endianness works.

I had problems with 2 different sets of sources so I thought that it could be an endianness issue. One was some code to read a WAV file - I had copied an example *aimed* at developers for embedded systems so I had expected it to be portable but when I looked more closely it wasn't! I never imagined example code to be so bad.

The other problem is with QT4.4 which seems to read some images with wrong colours - nothing to do with colourspaces.

So now it just seems to be the QT problem so it's less likely to be endianness.

You needn't worry about it at all.
Well, most WAV data is stored little-endian for obvious Windows-related reasons. All you need to do is read in the file, though, and if you want to read a 16-bit sample and convert it to big-endian data, use lhbrx (you may need a little inline assembler or a macro) to copy it into a register. It will automatically byteswap the data for you. lwbrx will do the same for a 32-bit word, and there are store instructions which will store it back with byte swap if you're modifying data.
Do you have example code here? We run Qt4.4 in some demos and it seems to load images fine. What kind of images are you loading, and to what kind of class are you displaying them?

_________________
Matt Sealey

I didn't know anything about WAV until I had that problem. Now I know a *lot* more ;)

I can enjoy the luxury of C++ or C so I'm not going to use assembler to swap bytes; besides I want my code to be portable.
Just build something using a QFileDialog; the icons for navigating are red when they should be blue. I first noticed this when I loaded an XPM into a QIcon and then used the global setWindowIcon(). The icon in my about dialog was weird.

It can still be portable; just wrap it in a macro. The portability you crave needn't come at the expense of performance. If you need to do realtime processing of audio data or so, then you do not want to waste time byteswapping manually. It uses more registers and of course takes far more instructions (at least 2 logical ops and a couple of shifts)
That's a more complicated issue than endianness, since XPM is an ASCII text format and should be parsed the same way on x86 and PowerPC :)

_________________
Matt Sealey

You could just use swab() from glibc or libfreevec, which exist just for this purpose :D

I"m only playing back a PCM WAV file so I think it's OK to use a high level programming language in order to write easy to understand code.
Well it's not actually; as I said, when I build QT I can see the problem in the icons used by a QFileDialog. I don't know what format they are using, those icon files were not created by me.
I didn't know about that, thanks. I can see how you can do 16 bit BE/LE conversion but not 32 bit, have I missed something ?