Sept 08 commit (OMX_COLOR_Format32bitARGB8888) flips colors w/ HDMI output

[321liftoff]

Commit 793d107342ff2f88a1976c014c7ead5044b45376 Sept 08 "Add support for OMX_COLOR_Format32bitARGB8888 in image_decode, image_resize, image_encode." flips (on the horizontal axis) the color square test pattern shown on boot, such that the colors in each corner are changed as indicated below:

Upper-left: red -> blue Bottom-left: blue -> red Upper-right: yellow-> light blue? Bottom-right: light blue? -> yellow

I also notice that my TV upon power-up of the RPi displays "720p" with the pre-Sept6 *start.elf files, but displays "1360 x 768" after this commit. This "display of the resolution" is an indicator the TV shows when changing sources on the TV, or when a source is powered on. This may show that the resolution that the RPi is outputting changed with this commit.

I also notice that with the pre-Sept6 *start.elf files, there is a blank margin surrounding the white text (10%? on top and bottom and 5%? on left and right) during the first stages of boot, as if the whole screen has been resized . After the commit, there is no blank margin; the RPi logo is in the very upper-left.

Because I may be the only one pointing out this issue, it may be a characteristic specific to my TV, but as the RPi becomes more popular this issue may become more wide-spread. Unfortunately, I don't have any other TVs with HDMI to test.

Steps to replicate: (1) Install Raspbian 9/18 image onto SD card (2) Boot RPi and notice the color square test pattern is FLIPPED (3) Replace start.elf files in /boot directory with start.elf files prior to Sept 08 commit (4) Boot RPi and notice the color square test pattern is CORRECT (5) Replace start.elf files in /boot directory with start.elf files immediately after Sept 08 commit (6) Boot RPi and notice the color square test pattern is FLIPPED

[popcornmix]

I don't understand why no one else is seeing this. Do you have anything in config.txt/cmdline.txt? Are you forcing a 32bpp framebuffer?

I've looked at the code that changed on 793d107 and I don't believe any of it is even running when the splash screen is displayed. (It just affects openMAX components).

[321liftoff]

Thanks for taking the time to reply, seeing that no one else has this issue. I'm not changing anything in the Raspbian 9/18 image, so the config.txt/cmdline.txt is whatever the defaults are. I looked briefly at the config.txt and it has a bunch of lines commented out. I don't know how to force a 32bpp framebuffer (Idon't even know what that is), so I guess I'm not forcing it. Were the steps I took to find when the change in color occurred valid?

Some additional tests I thought of: (1) Try RPi with another TV with 9/18 Raspbian image to see if it's my RPi or TV (2) Obtain *start.elf binary files relevant to the 9/18 Raspbian image, without the commit in it, and see if it's the right color

I'm open to trying others if it would help. Don't know if it's possible for you to help with (2) above.

[321liftoff]

I tried the 9/18 Raspbian image on my SD card with my RPi and a different TV. The RPi logo appeared red and the resolution was 1360x768. Based on this, it seems that my Westinghouse SK-32H590D TV is interpreting the HDMI signal from the updated software differently than most other TVs (if not all?).

I really don't want to buy a new TV, so do you have any other options?

[popcornmix]

Have you tried config_hdmi_boost=7 in config.txt ?

[321liftoff]

No, I haven't tried to edit the config.txt. I see on the Wiki (http://elinux.org/RPi_config.txt) a bunch of options, so I will give some of those a try and report back.

[321liftoff]

Bear with me as I show you some data. I found out some interesting things, and maybe you can help me make heads or tails of it.

My edid is the following:

Parsing edid.dat...
HDMI:EDID version 1.3, 1 extensions, screen size 71x40 cm
HDMI:EDID features - videodef 0x80 !standby !suspend active off; colour encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred format is native; does not support GTF
HDMI:EDID found monitor range descriptor tag 0xfd
HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0
HDMI:EDID monitor range: vertical is 49-76 Hz, horizontal is 15-49 kHz, max pixel clock is 80 MHz
HDMI:EDID monitor range does not support GTF
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is SK-32H590D
HDMI:EDID found unknown detail timing format: 1366x768p hfp:48 hs:32 hbp:66 vfp:3 vs:5 vbp:32 pixel clock:73 MHz
HDMI:EDID found unknown detail timing format: 1360x768p hfp:48 hs:32 hbp:80 vfp:2 vs:5 vbp:15 pixel clock:72 MHz
HDMI:EDID established timing I/II bytes are A1 08 00
HDMI:EDID found DMT format: code 4, 640x480p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 9, 800x600p @ 60 Hz in established timing I/II
HDMI:EDID found DMT format: code 16, 1024x768p @ 60 Hz in established timing I/II
HDMI:EDID standard timings block x 8: 0x81C0 0101 0101 0101 0101 0101 0101 0101
HDMI:EDID found DMT format: code 85, 1280x720p @ 60 Hz (16:9) in standard timing 0
HDMI:EDID parsing v3 CEA extension 0
HDMI:EDID monitor support - underscan IT formats:no, basic audio:yes, yuv444:yes, yuv422:yes, #native DTD:1
HDMI:EDID found preferred CEA detail timing format: 1280x720p @ 60 Hz (4)
HDMI:EDID found CEA detail timing format: 1920x1080i @ 60 Hz (5)
HDMI:EDID found CEA detail timing format: 720x480p @ 60 Hz (2)
HDMI:EDID found CEA detail timing format: 720x480p @ 60 Hz (2)
HDMI:EDID found CEA format: code 4, 1280x720p @ 60Hz (native)
HDMI:EDID found CEA format: code 5, 1920x1080i @ 60Hz
HDMI:EDID found CEA format: code 3, 720x480p @ 60Hz
HDMI:EDID found CEA format: code 2, 720x480p @ 60Hz
HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48 kHz, sample size: 16|20|24 bits
HDMI:EDID found HDMI VSDB length 5
HDMI:EDID HDMI VSDB has physical address 1.0.0.0
HDMI:EDID HDMI VSDB has no extension fields
HDMI:EDID adding mandatory support for CEA (1) 640x480p @ 60Hz
HDMI:EDID filtering formats with pixel clock > 162 MHz or h. blanking > 1023
HDMI:EDID best score mode initialised to CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 18432)
HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 61864)
HDMI:EDID best score mode is now CEA (2) 720x480p @ 60 Hz with pixel clock 27 MHz (score 4066472)
HDMI:EDID CEA mode (3) 720x480p @ 60 Hz with pixel clock 27 MHz has a score of 66472
HDMI:EDID best score mode is now CEA (4) 1280x720p @ 60 Hz with pixel clock 74 MHz (score 5190888)
HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 18432
HDMI:EDID CEA mode (5) 1920x1080i @ 60 Hz with pixel clock 74 MHz has a score of 4773832
HDMI:EDID DMT mode (9) 800x600p @ 60 Hz with pixel clock 40 MHz has a score of 28800
HDMI:EDID DMT mode (16) 1024x768p @ 60 Hz with pixel clock 65 MHz has a score of 47185
HDMI:EDID DMT mode (85) 1280x720p @ 60 Hz with pixel clock 74 MHz has a score of 80296
HDMI:EDID preferred mode remained as CEA (4) 1280x720p @ 60 Hz with pixel clock 74 MHz
HDMI:EDID has HDMI support and audio support
edid_parser exited with code 0

Also, my CEA is the following:

Group CEA has 5 modes:
       mode 1: 640x480 @ 60Hz, progressive
       mode 2: 720x480 @ 60Hz, progressive
       mode 3: 720x480 @ 60Hz, progressive
  (native) mode 4: 1280x720 @ 60Hz, progressive
       mode 5: 1920x1080 @ 60Hz, interlaced

The above data is the same for the 8/16 image and the 9/18 images of Raspbian Wheezy.

The DMT and current states are different between the two images (using default config.txt, which has no active paramters)

Raspbian 8/16 image:

Group DMT has 4 modes:
       mode 4: 640x480 @ 60Hz, progressive
       mode 9: 800x600 @ 60Hz, progressive
       mode 16: 1024x768 @ 60Hz, progressive
       mode 85: 1280x720 @ 60Hz, progressive

state: HPD high|HDMI mode|composite off (0x12000a), 1280x720 @ 60Hz, progressive

Raspbian 9/18 image:

Group DMT has 6 modes:
       mode 4: 640x480 @ 60Hz, progressive
       mode 9: 800x600 @ 60Hz, progressive
       mode 16: 1024x768 @ 60Hz, progressive
       mode 39: 1360x768 @ 60Hz, progressive
       mode 81: 1366x768 @ 60Hz, progressive
       mode 85: 1280x720 @ 60Hz, progressive

state: HPD high|DVI mode|HDCP off|composite off (0x120016), 1366x768 @ 60Hz, progressive

Note in the 9/18 info the additional two DMT modes and the HDCP parameter in the state. Also, note the difference in the resolutions. So, I added hdmi_group=1 and hdmi_mode=4 in the config.txt of the 9/18 image to be the same as the 8/16, which does result in the colors being correct and shows the following state:

state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1280x720 @ 60Hz, progressive

So, I'm wondering if this data helps point to something that changed in the firmware that causes my TV to have two distinct responses. I'm wondering if this part of the EDID is the culprit:

HDMI:EDID found unknown detail timing format: 1366x768p hfp:48 hs:32 hbp:66 vfp:3 vs:5 vbp:32 pixel clock:73 MHz
HDMI:EDID found unknown detail timing format: 1360x768p hfp:48 hs:32 hbp:80 vfp:2 vs:5 vbp:15 pixel clock:72 MHz

Since the newer verions of the firmware is using 1366x768, and there is unknown timing with those resolutions, that may be an issue? Why are the newer firmwares picking 1366x768, which doesn't work while the older one is picking 1280x720, which does work?

The Xbian 0.8 image has the following differences to the EDID:

Enabling fuzzy format match...
Parsing edid.dat...
...
HDMI:EDID monitor name is SK-32H590D
HDMI:EDID failed to find a matching detail format for 1366x768p hfp:48 hs:32 hbp:66 vfp:3 vs:5 vbp:32 pixel clock:73 MHz
HDMI:EDID calculated refresh rate is 60 Hz
HDMI:EDID guessing the format to be 1366x768p @60 Hz
HDMI:EDID found preferred DMT detail timing format: 1366x768p @ 60 Hz (81)
HDMI:EDID failed to find a matching detail format for 1360x768p hfp:48 hs:32 hbp:80 vfp:2 vs:5 vbp:15 pixel clock:72 MHz
HDMI:EDID calculated refresh rate is 60 Hz
HDMI:EDID guessing the format to be 1360x768p @60 Hz
HDMI:EDID found DMT detail timing format: 1360x768p @ 60 Hz (39)  
...
HDMI:EDID DMT mode (16) 1024x768p @ 60 Hz with pixel clock 65 MHz has a score of 94370
HDMI:EDID best score mode is now DMT (39) 1360x768p @ 60 Hz with pixel clock 85 MHz (score 4625336)
HDMI:EDID best score mode is now DMT (81) 1366x768p @ 60 Hz with pixel clock 85 MHz (score 5125890)
HDMI:EDID DMT mode (85) 1280x720p @ 60 Hz with pixel clock 74 MHz has a score of 135592
HDMI:EDID preferred mode remained as DMT (81) 1366x768p @ 60 Hz with pixel clock 85 MHz
HDMI:EDID has HDMI support and audio support
edid_parser exited with code 0

And the state for Xbian 0.8 image is:

state: HPD high|HDMI mode|HDCP off|composite off (0x12001a), 1366x768 @ 60Hz, progressive 

I hope the data is useful; I tried to be throrough. This is all new to me, so any assistance would be greatly appreaciated!

[popcornmix]

Does: avoid_edid_fuzzy_match=1 in config.txt make the new firmware work as desired?

[321liftoff]

Yes, "avoid_edid_fuzzy_match=1" has the same effect as hdmi_group=1 & hdmi_mode=4, which is 720p and correct colors. Does this point to a bug, or is will I just have to use the "avoid_edid_fuzzy_match=1" setting with this TV?

[popcornmix]

It's difficult. Your display says it's favoured mode is: HDMI:EDID found unknown detail timing format: 1366x768p hfp:48 hs:32 hbp:66 vfp:3 vs:5 vbp:32 pixel clock:73 MHz which isn't a standard mode. We pick (using fuzzy match) this mode: 1366x768p hfp:70 hs:143 hbp:213 vfp:3 vs:3 vbp:24 pixel clock:85.5MHz

but your monitor doesn't like it. Now we added this because there are lots of displays that report non standard modes where picking the closest standard mode does work correctly.

I think for now, stick with avoid_fuzzy_match=1, and we'll add your monitor to the list of "doesn't like fuzzy matching". I'll see if the HDMI guy has any better suggestions for a future update.

[321liftoff]

Did Commit 793d107 introduce the fuzzy matching? Did I correctly identify the commit that started my issues?

A suggestion is to change the parameter to be "enable_fuzzy_match=1", where if nothing is in config.txt, it would not use fuzzy match since it seems like fuzzy match works sometimes. Since I don't have a TV that works "normally", I don't know what is gained by having fuzzy matching on by default.

In the meantime, I'll use avoid_fuzzy_match=1, seems to be working great. Thanks for you help and for explaining what is happening!

[popcornmix]

Can you also try: hdmi_ignore_edid=0xa5000080 hdmi_group=2 hdmi_mode=86 This should be the reduced blanking versions of 1366x768 which may be a better match.

[321liftoff]

Unfortunately, those settings result in a 640x480 resolution.

[popcornmix]

Might be worth trying: hdmi_ignore_edid=0xa5000080 hdmi_group=2 hdmi_mode=86 with newer firmware. The ignore_edid now allows any mode to be driven.

[321liftoff]

Thanks for the comment. I tried the settings with "Linux raspbmc 3.6.11 #1 PREEMPT Sat Dec 29 00:16:57 UTC 2012 armv6l GNU/Linux" (I waited for a Raspbmc update to ensure I got the latest firmware you were talking about).

Group 2 Mode 86 goes to 640x480, so I guess my tv doesn't like it. tvservice -s result below:

state 0x120016 [DVI RGB full 4:3], 640x480 @ 60Hz, progressive

Group 2 Mode 39 works:

state 0x120006 [DVI RGB full 16:9], 1360x768 @ 60Hz, progressive

Group 2 Mode 81 is the blueberry mode and my TV reports 1360x768 (not 1366x768) when using it:

state 0x120006 [DVI RGB full 16:9], 1366x768 @ 60Hz, progressive

Group 2 Mode 85 works and is the result when "avoid_edid_fuzzy_match=1" is used:

state 0x12001a [HDMI DMT (85) RGB full 16:9], 1280x720 @ 60Hz, progressive result when Group 2 Mode 85 is forced: state 0x120016 [DVI RGB full 16:9], 1280x720 @ 60Hz, progressive

Let me know if other testing will help.