Sorry I dont understand.
I took DRM logs with command : dmesg | grep -i drm It is right?
My kernel version is :
Linux localhost 4.14.94-gda5deabaa780d #16 SMP PREEMPT Thu Jan 24 16:28:37 +03 2019 aarch64
Just use dmesg… It is almost always a bad idea to run grep over logs when sharing them as a pastebin. It means the people reading them have to guess what is in the gaps and that is tiresome.
Then you should probably add some variant of this patch from v4.9 (this patch adds support for 800x480 monitors with a 32KHz pixel clock… and that is what you seem to have):
https://android.googlesource.com/kernel/hikey-linaro/+/b9f583e4d82aecee4923f37b24c04691fb1badf3
Ok. I dont know this. I run just dmesg : https://paste.ubuntu.com/p/YWbvYPxhGw/
Sorry I dont know. How can I add this patch from v4.9
To start you’d need to be able to rebuild the kernel yourself. Unfortunately I don’t know how this is done for optee_android_manifest builds (I assume something special needs to be done to enable OP-TEE support but I can’t see anything in the scripts - @vchong: any clues?).
For regular AOSP building the kernel is documented here but I’m afraid I don’t know how to adapt it for your circumstance so you might have to work on that:
https://source.android.com/setup/build/devices#960kernel
@danielt I can try to add the patch to the OP-TEE AOSP kernel build, but the commit says “The proper fix upstream calculates if the adjusted mode matches the pixel clock but 4.9 era kernels are missing the required infrastructure to calculate that here. So for now, just extend the whitelist.” Does android-hikey-linaro-4.14 - kernel/hikey-linaro - Git at Google not have the proper fix?
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.
