gujjwal00
commented
2 years ago Hi @exikyut thanks for reporting this. I am happy to help in getting AVNC work on your device. I too like to keep my old devices alive for as long as possible (I still have a Pentium Dual Core system alive on Ubuntu 16.04).
AVNC uses really simple shaders (just 3 lines in total), so they might not be the issue here. Unfortunately, debugging graphics issues is really difficult without access the the actual device.
According to the 1st blog post you linked, the validation message you highlighted and the screen being blank might be two different issues. Can you please post the complete logs from the device? Maybe something else is broken?
TIL AVNC is as fast as it is because it uses native TurboVNC and OpenGL :) - with the flip side of that coin being that I don't think there's a non-GL alternative "slow path" (which makes a lot of sense; the reasonable alternative is obviously "just use a different client").
AVNC uses native LibVNCClient as VNC library and OpenGL for rendering, but another major factor is libjpeg-turbo which enables Tight encoding and provides SIMD-accellerated JPEG decoding. I can't praise it enough :1st_place_medal: !
I have been thinking about adding OpenGL ES 1 rendering as an alternative, but I don't know how much effort/time it will take.
I'm not entirely sure if adding "Supports Android 4.1!" to the feature matrix is actually a respectable achievement smile but I do remain a tiny bit curious about how straightforward it might be demonstrate a tentative proof of concept. (Maybe leave some breadcrumbs - a git revision and some modification instructions - for the next motivated person to work off of, perhaps.)
Yes, I don't want to lower the minimum API, because its not worth the effort in my opinion. But I can create a separate branch to hold these patches and release "experimental" APKs on GitHub if you want (assuming we can fix this issue).
exikyut
Hi,
I just came across an old TF201, and given how surprisingly (and sadly) unusable the ancient Android version it's running is, getting a decent VNC client installed is one of the more relevant things that would make this device remotely useful. I found an old version of RealVNC (it's headscratchingly similar to the latest version in terms of features and UI - huh, ok), but that client was never fast, so I wondered how hard it would be to get AVNC working.
Surprisingly, dragging the build down to API 16 was actually quite trivial; mostly editing some XML and stubbing out just a couple of unavailable API calls.
Unfortunately once I got past that stage I've now found that while I can connect and drag the mouse around, I can't see anything; just a black square where the remote desktop should be.
On the one hand, "noooo! a GPU bug!"
On the other hand, at least there's something in the log (?).
Googling the error message finds the tiniest handful of links. https://jausoft.com/blog/2011/10/04/bug-hunting-on-android/ is the most interesting; it mentions that
I'm completely out of my depth here, but googling "uniform sampler2d" tegra found me https://forums.developer.nvidia.com/t/sampler2d-in-vertexshader/29120, where someone official-looking says that "Tegra does not support vertex texture fetch" - not sure if that's what's relevant here (wow graphics is a rabbithole).
Unsure if https://stackoverflow.com/questions/6801832/android-textures-gl-states-do-not-match-with-shaders has anything interesting in it
https://blog.techlab-xe.net/tegra2%E3%81%A7%E3%81%AE%E4%B8%8D%E5%85%B7%E5%90%88/ is in Japanese but despite Google Translate doing a surprisingly good job at it, I don't think there's anything too interesting in here
https://4pda.to/forum/index.php?showtopic=418429&st=1800 mentions the same error but is sadly in Russian and the quality of the translation (plus my unfamiliarity with the subject matter) leaves me somewhat unmotivated to try and figure out if there is anything useful here
TIL AVNC is as fast as it is because it uses native TurboVNC and OpenGL :) - with the flip side of that coin being that I don't think there's a non-GL alternative "slow path" (which makes a lot of sense; the reasonable alternative is obviously "just use a different client").
I'm not entirely sure if adding "Supports Android 4.1!" to the feature matrix is actually a respectable achievement :smile: but I do remain a tiny bit curious about how straightforward it might be demonstrate a tentative proof of concept. (Maybe leave some breadcrumbs - a git revision and some modification instructions - for the next motivated person to work off of, perhaps.)
Perhaps there's a "uses GL but disables acceleration" startpoint I could work off of?