Bug 1223618 - Color display abnormally at Beaglebone Black
Summary: Color display abnormally at Beaglebone Black
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: armv7hl
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-21 03:41 UTC by Tong Hui
Modified: 2018-06-08 06:45 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-06-08 06:45:51 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Color display abnormally at Beaglebone Black (1.26 MB, image/jpeg)
2015-05-21 03:41 UTC, Tong Hui
no flags Details
result of journalctl -b _COMM=gdm-x-session (77.25 KB, text/plain)
2015-05-22 16:55 UTC, Zamir SUN
no flags Details
result of journalctl -b _COMM=gdm-x-session -o export (548.85 KB, text/plain)
2015-05-22 16:56 UTC, Zamir SUN
no flags Details
one of my boot log(by press reset on BBB) (70.58 KB, text/plain)
2015-05-22 16:57 UTC, Zamir SUN
no flags Details
picture of waiting screen (1.43 MB, image/jpeg)
2015-05-25 14:26 UTC, Zamir SUN
no flags Details
Photo of vnc via a tablet (1.91 MB, image/jpeg)
2015-11-06 10:26 UTC, Zamir SUN
no flags Details
Boot log on ttyO0 of kernel 4.6 (68.81 KB, text/plain)
2016-04-18 13:07 UTC, Zamir SUN
no flags Details

Description Tong Hui 2015-05-21 03:41:43 UTC
Created attachment 1027958 [details]
Color display abnormally at Beaglebone Black

Description of problem:
All flavor of F22(GNOME, LXDE, XFCE) running in Beaglebone Black I tested color display are abnormally, the whole desktop looks very strange, all blue turns yellow, all red turns blue, and all green turns blue. 

BBB Connects to a display screen normally via onboard miro-HDMI cable. No other USB device attached when I test, and the board powered by onboard mini-USB cable from my computer. I also tested it powered by a DC input, same result.  

Other distribution is OK, I tested Debian 8 ships LxQt.

A photo I took is attached.

Version-Release number of selected component (if applicable):
F22 TC
Beaglebone Black Rev C

How reproducible:
Any time.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Zamir SUN 2015-05-21 04:45:43 UTC
We've tested to set background color of tty by commands like
setterm -background *somecolor*
and all color including blue works well.

Comment 2 Peter Robinson 2015-05-22 00:55:00 UTC
Can you attach the X.org startup logs please

Comment 3 Zamir SUN 2015-05-22 16:55:15 UTC
Created attachment 1028877 [details]
result of journalctl -b _COMM=gdm-x-session

Comment 4 Zamir SUN 2015-05-22 16:56:12 UTC
Created attachment 1028878 [details]
result of journalctl -b _COMM=gdm-x-session -o export

Comment 5 Zamir SUN 2015-05-22 16:57:22 UTC
Created attachment 1028881 [details]
one of my boot log(by press reset on BBB)

Comment 6 Zamir SUN 2015-05-25 14:26:12 UTC
Created attachment 1029488 [details]
picture of waiting screen

Comment 7 Zamir SUN 2015-11-06 09:02:18 UTC
During one of the meetings, we wonder if this is caused by power supply. Today I tried to power the board with a 2A power adapter through the power socket instead of the USB socket, and the display problem is still there.

Comment 8 Zamir SUN 2015-11-06 10:24:44 UTC
Tested Fedora-Xfce-armhfp-23-10-sda.raw.xz

I configured vncserver on as https://ask.fedoraproject.org/en/question/9105/how-can-i-get-vncserver-to-use-xfce/ and vnc into BBB by a tablet, the color is right via vnc (while the color is still wrong via HDMI). So I guess this will be easier to fix than we expected before.

Can anyone change the version to F23 or rawhide?

Comment 9 Zamir SUN 2015-11-06 10:26 UTC
Created attachment 1090565 [details]
Photo of vnc via a tablet

Comment 10 Peter Robinson 2015-11-06 11:21:09 UTC
(In reply to Zamir SUN from comment #9)
> Created attachment 1090565 [details]
> Photo of vnc via a tablet

Is this a problem via VNC or HDMI?

Setting it to the right component

Comment 11 Zamir SUN 2015-11-06 11:29:04 UTC
(In reply to Peter Robinson from comment #10)
> (In reply to Zamir SUN from comment #9)
> > Created attachment 1090565 [details]
> > Photo of vnc via a tablet
> 
> Is this a problem via VNC or HDMI?
> 
> Setting it to the right component

Color is wrong if I connect the monitor via HDMI.
Color is right (as the attachement today) via VNC.

Any info I can gather for you?

Comment 12 Zamir SUN 2016-04-17 23:57:20 UTC
This problem still exists on Fedora 24 as of Fedora-Xfce-armhfp-24-20160411.n.1-sda.raw.xz.

Comment 13 Peter Robinson 2016-04-18 09:38:51 UTC
(In reply to Zamir SUN from comment #12)
> This problem still exists on Fedora 24 as of
> Fedora-Xfce-armhfp-24-20160411.n.1-sda.raw.xz.

can you test a 4.6 kernel, like rc3 linked below, from F25 as there was a bunch of fixes that landed upstream for the display there.

http://koji.fedoraproject.org/koji/buildinfo?buildID=753397

Comment 14 Zamir SUN 2016-04-18 13:04:32 UTC
Tested kernel 4.6. The result is FAILED.

Hardware:
BBB Rev. C, HDMI monitor connected, powered by standalone power (powere via mini USB also tested, and the result is the same)

Steps:
1. Flash the Fedora-Xfce-armhfp-24-20160411.n.1-sda.raw.xz image to mSD
2. Boot and finish the configure wizard.
3. install the kernel 4.6 packages
 	kernel-4.6.0-0.rc3.git0.1.fc25.armv7hl.rpm
	kernel-core-4.6.0-0.rc3.git0.1.fc25.armv7hl.rpm
	kernel-headers-4.6.0-0.rc3.git0.1.fc25.armv7hl.rpm
	kernel-modules-4.6.0-0.rc3.git0.1.fc25.armv7hl.rpm
	kernel-modules-extra-4.6.0-0.rc3.git0.1.fc25.armv7hl.rpm
(by default the image contains only the five kernel packages, so I just install the five versioned 4.6)
4. Reboot using the new kernel.
5. Check the monitor to see the color

Actual results:
The color is still not right.

And there is some traceback on ttyO0.[   23.338836] [<c0933a5c>] (_raw_spin_lock_irqsave) from [<bf290090>] (crypto_transfer_request+0x24/0x84 [crypto_engine])
[   23.350146] [<bf290090>] (crypto_transfer_request [crypto_engine]) from [<c05163f4>] (__test_skcipher+0x2d0/0x868)
[   23.360960] [<c05163f4>] (__test_skcipher) from [<c0518df8>] (test_skcipher+0x2c/0xb8)
[   23.369228] [<c0518df8>] (test_skcipher) from [<c0518f10>] (alg_test_skcipher+0x8c/0xa8)
[   23.377681] [<c0518f10>] (alg_test_skcipher) from [<c0517d3c>] (alg_test+0x28c/0x344)
[   23.385862] [<c0517d3c>] (alg_test) from [<c0515900>] (cryptomgr_test+0x2c/0x4c)
[   23.393603] [<c0515900>] (cryptomgr_test) from [<c026e5a8>] (kthread+0xe0/0xf0)
[   23.401250] [<c026e5a8>] (kthread) from [<c020fbd8>] (ret_from_fork+0x14/0x3c)
[   23.408796] Code: e1a03000 e10f0000 f10c0080 f5d3f000 (e1931f9f) 
[   23.415161] ---[ end trace 7221bd700f0b4454 ]---

 Besides, there are flooding message as the following
[  181.934974] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost
[  181.942850] tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000020): FIFO underfow

The actual tty output is attached

Comment 15 Zamir SUN 2016-04-18 13:07 UTC
Created attachment 1148207 [details]
Boot log on ttyO0 of kernel 4.6

Comment 16 Peter Robinson 2016-08-31 13:03:52 UTC
This is actually a hardware problem

http://www.spinics.net/lists/dri-devel/msg116413.html

To quote:
"The red and blue components are reversed between 24 and 16 bit modes
on am335x LCDC output pins. To get 24 RGB format the wires red and
blue wires has to be crossed and this in turn causes 16 colors output
to be in BGR format. With straight wiring the 16 color is RGB and 24
bit is BGR. These patches try to deal with the issue in reasonable
manner."

I won't explicitly pull this fix in and it doesn't look like they're going to enable it by default upstream. We'll have to wait and see what actually lands upstream.

Comment 17 Laura Abbott 2016-09-23 19:33:46 UTC
*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

Comment 18 Zamir SUN 2016-10-14 14:24:35 UTC
Move to Rawhide based on comment#16 for future reference.

Comment 19 Peter Robinson 2016-10-14 14:45:07 UTC
(In reply to Zamir SUN from comment #18)
> Move to Rawhide based on comment#16 for future reference.

actually this should be fixed in 4.9, it's a HW bug and the workaround should land in 4.9

Comment 20 Tong Hui 2017-06-24 10:19:50 UTC
Due to BBB cannot running into X, so that I cannot test it anymore.

Comment 21 Zamir SUN 2018-06-08 06:45:51 UTC
As of 4.17.0-1.fc29.armv7hl, there is only 226MB free memory when running the minimal image. So I don't think I will still try to run desktop on it. Since Tonghui is not able to test it as well, I am closing this as EOL.

[root@bbb ~]# uname -r
4.17.0-1.fc29.armv7hl
[root@bbb ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:            489         111         226           0         151         367
Swap:           243           0         243


Note You need to log in before you can comment on or make changes to this bug.