-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sept 08 commit (OMX_COLOR_Format32bitARGB8888) flips colors w/ HDMI output #101
Comments
I don't understand why no one else is seeing this. 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). |
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: I'm open to trying others if it would help. Don't know if it's possible for you to help with (2) above. |
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? |
Have you tried config_hdmi_boost=7 in config.txt ? |
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. |
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:
Also, my CEA is the following:
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:
Raspbian 9/18 image:
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'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:
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:
And the state for Xbian 0.8 image is:
I hope the data is useful; I tried to be throrough. This is all new to me, so any assistance would be greatly appreaciated! |
Does: |
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? |
It's difficult. Your display says it's favoured mode is: 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". |
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! |
Can you also try: |
Unfortunately, those settings result in a 640x480 resolution. |
Might be worth trying: |
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:
Group 2 Mode 39 works:
Group 2 Mode 81 is the blueberry mode and my TV reports 1360x768 (not 1366x768) when using it:
Group 2 Mode 85 works and is the result when "avoid_edid_fuzzy_match=1" is used:
Let me know if other testing will help. |
Commit 793d107 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
The text was updated successfully, but these errors were encountered: