Hide Forgot
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:
We've tested to set background color of tty by commands like setterm -background *somecolor* and all color including blue works well.
Can you attach the X.org startup logs please
Created attachment 1028877 [details] result of journalctl -b _COMM=gdm-x-session
Created attachment 1028878 [details] result of journalctl -b _COMM=gdm-x-session -o export
Created attachment 1028881 [details] one of my boot log(by press reset on BBB)
Created attachment 1029488 [details] picture of waiting screen
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.
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?
Created attachment 1090565 [details] Photo of vnc via a tablet
(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
(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?
This problem still exists on Fedora 24 as of Fedora-Xfce-armhfp-24-20160411.n.1-sda.raw.xz.
(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
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
Created attachment 1148207 [details] Boot log on ttyO0 of kernel 4.6
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.
*********** 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.
Move to Rawhide based on comment#16 for future reference.
(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
Due to BBB cannot running into X, so that I cannot test it anymore.
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