prenex

PS.: The display itself works on a PC and I will try if it works with a raspbian running on a raspberry pi 3b or not. I do not have or plan to have those hw/sw in the first place as armbian was great so far for everything. Quite a stable system so far.

Hello everybody. I am trying to build an DIY headset from scratch and I originally planning to use some armbian OS for its SBC at its heart of the device (like an orange pi, or something maybe a bit stronger who knows - I happily accept recommendations). For the headset it is necessary to have proper opengl support with hardware rendering capabilities and also good to have video acceleration maybe so I think the legacy kernel fits the purpose best. PROBLEM: I tried to plug in the HDMI display - it does not work. Details: The display is seemingly not working when attached to the HDMI port. I see some led flashing so I think some handshaking is in progress, but it never finishes it. It works on a regular PC and have very high DPI density and high resolution. I have found that I might need to fuss-around a bit with fex / bin trickery, but I am unsure. I have also heard that mainline kernels have "better support" for custom resolutions and stuff like that, but I am unsure if hardware GPU / GLES2 acceleration would work properly for it. This is the display I am trying to use: https://www.aliexpress.com/item/5-5inch-2560-1440-2K-LCD-Screen-3D-VR-Headset-Glass-Virtual-Reality-HDMI-to-MIPI/32813542714.html?spm=2114.search0104.3.22.53a94c17uvnHzK&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10151_10065_10068_10344_5012917_10342_10343_10340_10341_10696_5012717_10084_10083_10618_10304_10307_10820_10821_5012817_5013017_10302_10059_100031_10103_10624_10623_10622_10621_10620,searchweb201603_51,ppcSwitch_5&algo_expid=3b6cb23a-4bae-406a-b19d-9a3865f2a47d-3&algo_pvid=3b6cb23a-4bae-406a-b19d-9a3865f2a47d&priceBeautifyAB=0 Also currently I am just using my "Orange Pi PC plus" at home for my experiments. I am not sure however if there is a better SBC for building the headset. What I need is support for the LCD above through HDMI and some processing power to render 3D graphics. Positioning and mapping will be offloaded to custom electronics so the SBC mostly will only render to the screen of the smart helmet if things go as I am planning so the Opi could be actually enough for my performance needs maybe. What I am unsure about: - Do I need to configure something in software for this HDMI LCD to work with armbian? - Or did I ran into my orange pi not having enough hardware capabilities to support this LCD throuh HDMI (not supporting some HDMI protocols maybe or whatever?) - Do I need to compile my own armbian kernel to modify configuration of the hdmi resolutions? - Or can I edit some bin/fex/whatever files? - Where are things documented or written about this topic if there is any such? - Do any of you advice a better device than my orange pi? - Can anyone explain what happens and how HDMI works under the hood or how to understand it? To be honest I originally thought it is some easy plug&play stuff, but now I see there are "timings", config values, different versions of the HDMI protocol ad stuff like that I am not completely understanding yet. Best regards, prenex

It seems mesa-egl got "reinstalled" right nearby the still present "mali-egl". I could instruct gl4es to use the latter - See here: https://github.com/ptitSeb/gl4es/issues/65 (useful info up there is also that lsof and ldd are useful tools to debug what drivers and devices are in use) I guess it is also safe (or maybe advised?) to remove mesa-egl by mv-ing it out somewhere else, but I did not do it yet. I guess it can only add performance because then things are not finding the bad one accidentally. Aside this, the retrorangepi install script mostly seem to have did its job, but I will do further testing...

Thank you for your input that indeed ES still works. I tried to figure it out whether it is software or hw by looking at CPU usage which was 80% with GLES and 220% with opengl even with glxgears. At least knowing that GLES still works is a good thing as maybe the system can be saved without a reinstall... In the meantime I've tried recompiling gl4es. I have even deleted the stuff that cmake creates beause I thought it will be that the cmake cached something but no change after a clean, make, make install... Also there is this other weird issue with the gamepad now by complaining that /dev/input/js0 is not readable without sudo. I see it is in the "input" group and /dev/mali is in "video". I will try to look after permissions and groups. Maybe it is a good idea to add my user to these groups or something... I have tried to ask on some other forum for details about what the script might have done here (I have found this forum in the contact part of the retrorangepi website): http://orangepi.club/showthread.php?tid=2536 ^^Also from that original conversation it seems like installing the retrorangepi version of retropie on an armbian AFTERWARDS normal install is not really supported or maybe not even really tried by them. But they should have made this clear I guess. I did not do all the things they mention on that topic, just the Retropie-Setup.sh so of course I did not change drivers myself... I don't get what they mean by: "Basically, you need to install the framebuffer Mali drivers (matching the kernel module - version r3p0) in another path (/usr/local/lib) to avoid conflicts with existing X11 Mali lib (included in Armbian image)" I did not do anything like this but maybe the script did try and overwrote the one included in the armbian image? edit: $ groups p dialout sudo audio video plugdev systemd-journal netdev ssh bluetooth ^^so I seem to have the "video" group, but not the "input" group. I guess that is why the gamepad did not work, but then this is not why the gl is failing...

Also it seems that "antimicro" can only use my gamepads now if I start it with "sudo antimicro". Seems like the setup script is messing with a lot of things... other people have other issues like here: https://askubuntu.com/questions/930802/antimicro-not-detecting-controller-input-after-install-retropi At least in my case it works with sudo. Also maybe it is a permission thing for the other too who knows... Sadly at the github link there is no "issues" button. I do not know if it is because it is a fork of an other repo or they configured it not to appear. By default there used to be (even on my own github things there is "issues" menu). :-(

Besides fixing the source of the issue - which is surely not armbians fault and totally retropie / retrorangepi related - in the retrorangepi version of the retropie-setup install script, I would still love to recover from the problem and in that I guess not only retropie-related information are helpful, but generic one to tell where to look in these kind of cases - that is what I meant above :-). So alongside the problem in the script now there is a second problem to try recovering from this without a complete reinstall and it would be great to find some help in it. :-) Btw Armbian is awsome and I really like it so far. I haven't really seen bugs related to the core system myself. Thank you, I did not know that! So this can even mean that gl4es still works but for some random reason everything became much slower??? Do you know are there any paths I should look to know if hardware es2 driver files are in place? I know about glmark2-es2 and made a test, but I had no earlier data to compare if this is good or not: $ glmark2-es2 ======================================================= glmark2 2014.03+git20150611.fa71af2d ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-400 MP GL_VERSION: OpenGL ES 2.0 ======================================================= [build] use-vbo=false: FPS: 112 FrameTime: 8.929 ms [build] use-vbo=true: FPS: 129 FrameTime: 7.752 ms [texture] texture-filter=nearest: FPS: 130 FrameTime: 7.692 ms [texture] texture-filter=linear: FPS: 122 FrameTime: 8.197 ms [texture] texture-filter=mipmap: FPS: 115 FrameTime: 8.696 ms [shading] shading=gouraud: FPS: 109 FrameTime: 9.174 ms [shading] shading=blinn-phong-inf: FPS: 115 FrameTime: 8.696 ms [shading] shading=phong: FPS: 87 FrameTime: 11.494 ms [shading] shading=cel: FPS: 68 FrameTime: 14.706 ms [bump] bump-render=high-poly: FPS: 73 FrameTime: 13.699 ms [bump] bump-render=normals: FPS: 123 FrameTime: 8.130 ms [bump] bump-render=height: FPS: 107 FrameTime: 9.346 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 26 FrameTime: 38.462 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 16 FrameTime: 62.500 ms [pulsar] light=false:quads=5:texture=false: FPS: 128 FrameTime: 7.812 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 13 FrameTime: 76.923 ms [desktop] effect=shadow:windows=4: FPS: 43 FrameTime: 23.256 ms Error: Requested MapBuffer VBO update method but GL_OES_mapbuffer is not supported! [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 26 FrameTime: 38.462 ms Error: Requested MapBuffer VBO update method but GL_OES_mapbuffer is not supported! [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: Unsupported [ideas] speed=duration: FPS: 95 FrameTime: 10.526 ms [jellyfish] <default>: FPS: 34 FrameTime: 29.412 ms Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0 [terrain] <default>: Unsupported [shadow] <default>: FPS: 21 FrameTime: 47.619 ms [refract] <default>: FPS: 16 FrameTime: 62.500 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 128 FrameTime: 7.812 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 51 FrameTime: 19.608 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 123 FrameTime: 8.130 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 71 FrameTime: 14.085 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 37 FrameTime: 27.027 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 72 FrameTime: 13.889 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 72 FrameTime: 13.889 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 69 FrameTime: 14.493 ms ======================================================= glmark2 Score: 77 ======================================================= I don't know what the score should be with not working gles2 and a working one in a fresh install. I hope this shows it being hardware accelerated in case of GLES2, but I am quite unsure as the shown things are quite simple in glmark2 - and unlike a game scene so I cannot compare. Can anyone say if I run with software GLES2 only now according to this result? I only use glshim and/or gl4es. The latter worked well for tuxracer for me, but it is complete lag now. glshim or gl4es does not seem to replace anything in the said directories, just delegate the calls to gles calls. That is why I try to find out if GLES2 is also slow now for some reason or not. Maybe the script changed the ES to use software rendering, but I am not sure, because I cannot compare the above test to any earlier results on my machine. I will surely do that too because they need to know about this issue from someone even if I can recover my case I guess.

Thank you for the suggestion, however I would just prefer to get back the original MALI driver that came with the Legacy kernel system to work once again as before. I don't know what retropie did, but I just want MALI GPU on legacy kernel to work as before and would be happy to have some help knowing where to look. In this way I don't think it is that much retropie-related or is it? $ ls -lat /usr/lib/arm-linux-gnueabihf/dri total 100412 drwxr-xr-x 77 root root 69632 Jul 8 10:02 .. drwxr-xr-x 2 root root 4096 Jul 6 21:05 . -rw-r--r-- 12 root root 7782376 Jun 14 17:52 etnaviv_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 imx-drm_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 kgsl_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 kms_swrast_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 msm_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 nouveau_dri.so -rw-r--r-- 3 root root 3109528 Jun 14 17:52 nouveau_vieux_dri.so -rw-r--r-- 3 root root 3109528 Jun 14 17:52 r200_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 r300_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 r600_dri.so -rw-r--r-- 3 root root 3109528 Jun 14 17:52 radeon_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 radeonsi_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 swrast_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 vc4_dri.so -rw-r--r-- 12 root root 7782376 Jun 14 17:52 virtio_gpu_dri.so -rw-r--r-- 1 root root 13888 Aug 31 2017 dummy_drv_video.so Should I see a mali_something_dri.so here or at some other place originally with a clean armbian legacy kernel install for orangepi pc plus? This is one of the place according to the log message where gl4es tries to find the MALI driver. I will try to recompile glshim and gl4es in a way that cmake configure runs again as maybe just the drivers place has changed. I would love to know where to look for the libraries to tell if they got removed or moved or whatever. At least to know what is their name so that I can do a "find" to search for them...

https://github.com/retr0rangepi/RetroPie-Setup ^^After manually running this setup program, gl4es and glshim does not seem to work anymore... Before this installment everything worked for me and I used both glshim and gl4es to play games like tuxracer. Both gl4es and glshim are build from source and already installed. See error messages below. gl4es: LIBGL:loaded: libEGL.so LIBGL: Using GLES 2.0 backend MESA-LOADER: failed to retrieve device information libEGL warning: DRI2: failed to open mali_drm (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri) LIBGL: Hardware Limited NPOT detected and used LIBGL: Extension GL_EXT_blend_minmax detected and used LIBGL: FBO are in core, and so used LIBGL: PointSprite are in core, and so used LIBGL: CubeMap are in core, and so used LIBGL: BlendColor is in core, and so used LIBGL: Blend Substract is in core, and so used LIBGL: Blend Function and Equation Separation is in core, and so used LIBGL: Texture Mirrored Repeat is in core, and so used LIBGL: Extension GL_OES_mapbuffer detected LIBGL: Extension GL_OES_element_index_uint detected and used LIBGL: Extension GL_OES_packed_depth_stencil detected and used LIBGL: Extension GL_OES_depth24 detected and used LIBGL: Extension GL_OES_rgb8_rgba8 detected and used LIBGL: Extension GL_EXT_multi_draw_arrays detected LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used LIBGL: Extension GL_OES_depth_texture detected and used LIBGL: Extension GL_EXT_texture_rg detected and used LIBGL: Extension GL_OES_texture_float detected and used LIBGL: high precision float in fragment shader available and used LIBGL: Extension GL_EXT_frag_depth detected and used LIBGL: Max vertex attrib: 16 LIBGL: Extension GL_OES_standard_derivatives detected and used LIBGL: Max texture size: 8192 LIBGL: Max Varying Vector: 32 LIBGL: Texture Units: 8(8), Max lights: 8, Max planes: 6 LIBGL: Hardware vendor is VMware, Inc. LIBGL: sRGB surface supported LIBGL: Targeting OpenGL 2.0 LIBGL: Forcing NPOT support by disabling MIPMAP support for NPOT textures LIBGL: Current folder is:/home/p/install/gl4es MESA-LOADER: failed to retrieve device information libEGL warning: DRI2: failed to open mali_drm (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri) glshim: $ glxgears LIBGL: Initialising gl4es LIBGL: v1.0.9 built on Jun 28 2018 20:31:51 LIBGL: Using GLES 1.1 backend LIBGL:loaded: libGLESv1_CM.so LIBGL:loaded: libEGL.so LIBGL: Using GLES 1.1 backend MESA-LOADER: failed to retrieve device information libEGL warning: DRI2: failed to open mali_drm (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri) Segmentation fault As you can see, glshim does not even start anymore, but gl4es does not segfault however everything is so slow that I think software rasterizer works only. The retropie-setup script run very long and installed a lot of stuff, but I did not expected it will destroy support for opengl. Also I do not know if gles is now hardware accelerated or not, but normal opengl clearly not anymore. es2_gears runs, but that would run full speed regardless of having or not having hw acceleration so I cannot compare if it works or not. I mostly only used "normal gl" through gl4es earlier. Rationale: I have and OrangePi PC+ which was (and is) running great. It has a 64Gb SD and an 500Gb USB disk on which I store data for some web pages and my own gitea server for version controlling my stuff. Because I like these things to run all the time as a server, I did not wanted to "just use retrorangepi" but I wanted to have a system that both serves my lightweight web apps and runs as a machine acting as a media center for our not-so-smart lcd TV to watch movies from online sources with youtube_dl and play linux and retro games with cheap controllers while also serving my lightweight web stuff that basically has no traffic anyways. Sadly I did not make backup from the SD contents before installing the retropie as I did not know that it can have this big changes... I will try to provide all information you ask for. Does anyone had any issue like this? Maybe those who make the images for retrorangepi or some people who use pi all-around like I try? Btw I use the legacy 3.x kernel as that seemed to have the best support for 3D, hw video and working xpad etc.etc. Any help or ideas what I should look into?