Yes. I noticed that comment.
Not sure if v4.14 has the machinary @jstultz mentioned in the commit message but either way AFAICT the v4.14 drivers still have a whitelist and that 800x480 displays are not present in the whitelist.
Yes. I noticed that comment.
Not sure if v4.14 has the machinary @jstultz mentioned in the commit message but either way AFAICT the v4.14 drivers still have a whitelist and that 800x480 displays are not present in the whitelist.
@danielt Yes, I figured thereâs no harm adding the patch anyway and so have done it yesterday for @tesmnorth to try.
Sorry for just popping in now. So yes, there is a new âproperâ non-whitelist way to for the drm driver to check modelines, but while it has been implemented for the hikey board, it hasnât yet been done for hikey960 (HISI is doing core hikey960 drm driver upstreaming work now). So we are stuck with the adv white list right now.
And yes, youâre right, the current whitelist in 4.14 is the shorter list then what we had in 4.9. I will try to correct this today in the AOSP code base.
Now, I have no hikey960 to try it. Tomorrow, I will try it and share result of its.
@jstultz https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889473 has been abandoned. Seems like itâs replaced with 3 other patches below. Is that right?
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889696
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889697
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889698
Correct, though Iâm trying to work w/ HiSi to get an even better solution then the fixed whitelist. But that should be an improvement (and Iâve validated it on my 7" touch screen - that I believe is the same type as the original reporters - as well)
Hello again,
Today I tried new patched aosp optee manifest for 7inch screen (800x480). Touchable screen is working. But, gui is mixed like this :
I also tried video=HDMI-A-1:800x480@60
in BoardConfig.mk
. But nothing is changed.
EDIT: Sorry for typing errors
@tesmnorth The ânewâ patched aosp optee manifest was for https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889473. Iâve just replaced it with the 3 newer patches mentioned above, so you should try again.
@vchong I run ./sync-p-hikey960.sh
and ./build-p-hikey960.sh
again then I tried. But, gui is same. Also I tried to change BoardConfig.mk
.
@tesmnorth sorry I donât know what else to do at this point. Perhaps try https://github.com/bsupiot/hikey960-aosp-optee and see if you have better luck.
@danielt (or @jstultz) Youâd indicated above that the driver is continually trying to adopt to 800x480@66 but this mode doesnât seem to be in the whitelist. The only 800x480 mode is mode->hdisplay == 800 && mode->vdisplay == 480 && mode->clock == 32000
. Will adding mode->hdisplay == 800 && mode->vdisplay == 480 && mode->clock == 66000
perhaps be helpful?
@tesmnorth: Just to confirm, this the linksprite/96boards 7inch screen?
The image you have above seems like youâre missing the patch here:
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889696/
Can you double check the source you built and confirm it has that change?
@jstultz my screen is waveshare 7inch touchable screen with 800x480px. My screen is working with hikey620-960 and android 8 correctly.
I double check source I built. There is no change in kirin_drm_overlay_utils.c
. I changed the file according to link you sent. Finally, my screen is working. . Before your last post, I think, kirin_drm_overlay_utils.c
wasnât changed in optee_android_manifest. Thanks @jstultz.
@vchong thank you a lot. Can you check optee_android_manifest for kirin_drm_overlay_utils.c
. Because, I run ./sync-p-hikey960.sh
but there is no change.
NOTE : If you plug USB for adb, screen is closing and reboot. Is it problem?
EDIT about my question in NOTE tag. my screen is powered by USB and also screen uses USB for touching input. Because of that, I connect display to Hikey960 via USB and HDMI cable. So if I want to connect hikey960 via adb, I use another USB Type C cable and plug to hikey960. In this case, display is closing and hikey960 reboots.
I must reiterate that you CANNOT power the display via USB. The USB power is not applied early enough in the boot for the kernel to detect it reliably. The kernel DOES NOT implement hotplug for display.
You MUST power the display from an external source.
Until you get the display output working predictably, forget about the touch sensor. AFTER it works reliably, then we can talk about how to power the display so that you can have both working touch sensor and reliable startup.
Hello there!
I think I have met a very similar problem. I built optee+aosp, android P . and the screen is always trun balck and display disorder.
My touch screen is powered by a DC charger sepatately not by using the usb, and uses usb for touch control, I can ensure there is no matter with my touch screen, because I have check it by plug in the computer and it works well.
It looks like this when it works not so well.
The image you have above seems like youâre missing the patch here:
https://android-review.googlesource.com/c/kernel/hikey-linaro/+/889696/Can you double check the source you built and confirm it has that change?
I double check source I built. There is no change in kirin_drm_overlay_utils.c. I changed the file according to link you sent. Finally, my screen is working. . Before your last post, I think, kirin_drm_overlay_utils.c wasnât changed in optee_android_manifest. Thanks
May be I can also solve it by doing this, but I am quite confused with the patch link, and have no idea on what to do. could someone give any advices? Please see this, thanks a lot.
The console always output these messages :
[23316.313503] hisi_ddr_devfreq ddr_devfreq: set down threshold:400000000
[23413.315175] type=1400 audit(1557913531.519:6674): avc: denied { dac_read_search } for pid=4842 comm=âmainâ capability=2 scontext=u:r:zygote:s0 tcontext=u:r:zygote:s0 tclass=capability permissive=1
[23413.332750] type=1400 audit(1557913652.935:6675): avc: denied { associate } for pid=2685 comm=âBinder:2685_2â name=âglobalAlertâ scontext=u:object_r:proc_net:s0 tcontext=u:object_r:proc:s0 tclass=file1
[24003.853503] hisi_ddr_devfreq ddr_devfreq: ddr bandwdith request: 0 / 28472
[24003.860583] hisi_ddr_devfreq ddr_devfreq: set down threshold:685000000
[24006.520075] hisi_ddr_devfreq ddr_devfreq: ddr bandwdith request: 0 / 28472
[24006.527134] hisi_ddr_devfreq ddr_devfreq: set down threshold:400000000
[24006.686566] hisi_ddr_devfreq ddr_devfreq: ddr bandwdith request: 0 / 28472
[24006.693497] hisi_ddr_devfreq ddr_devfreq: set down threshold:685000000
[24008.888370] hisi_ddr_devfreq ddr_devfreq: ddr bandwdith request: 0 / 28472
[24008.895336] hisi_ddr_devfreq ddr_devfreq: set down threshold:400000000
[24009.350387] hisi_ddr_devfreq ddr_devfreq: ddr bandwdith request: 0 / 28472
[24009.358427] hisi_ddr_devfreq ddr_devfreq: set down threshold:685000000
[24012.284305] hisi_ddr_devfreq ddr_devfreq: ddr bandwdith request: 0 / 28472
[24012.291279] hisi_ddr_devfreq ddr_devfreq: set down threshold:400000000
Is it normal and what these messages mean. Is it related to the screen problems?
The controller on your display isnât handling the input well. The hikey960 doesnât make proper 60 Hz. Its closer to 58 Hz. Some monitors can get confused by this. Try a different resolution and/or refresh rate. Your monitor may be able to handle different input better.
Thanks for your advice!
Is there any commands to change the refresh rate? I just know the command can change the resolution
wm size
These changes need to be done on the kernel commandline.