jernej

Well, someone has to do it. I guess there is a lack of interest and/or time for such functionality for now. Would you care to do it? Replace? This needs to be added a top of previous patches. Please see my h3_hdmi_audio_v1 branch.

This patch is realy needed for HDMI audio (without it, it works on my TV but not on monitor). This is not a bug from either side. It comes from a fact that U-Boot puts framebuffer in such place that Linux puts some data into it when loading. Linux later reinitialize DE2 and puts framebuffer on different location. I agree that it may be annoying, but it doesn't hurt. Only difference is in display_clocks node, which has to have "allwinner,sun50i-h5-de2-clk" as compatible. Everything else should work with the same nodes (not tested). I guess we can move most of the nodes to sunxi-h3-ht.dtsi.

Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow. For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one? Driver should work (not tested), but DT must be updated. Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.

Uh, I typed too quickly. There is none known. That would be nice, although I don't have none of those two. OPi Plus 2E?

Yes, it does. True. Now that I managed to solve most of the driver problems + added HDMI audio & cec, I was thinking to add/update patches to Armbian. But I was thinking to start with H3, which means updating to 4.13 first. But enough of offtopic...

@zador.blood.stained I think Icenowy's linux git is only A64 oriented. For example, she added non-optional regulator to HDMI driver, which doesn't exist on OrangePi PC2. There may be more hidden issues...

@rusatch Can you rebuild kernel with this patch and report? https://github.com/jernejsk/linux-1/commit/d32309858f28948144d3d980d9e559b4e50dc940.patch

libGL is part of OpenGL and not OpenGL ES, which means you are running wrong tests and thus they are software rendered. There is GLShim library, which translates OpenGL 1.1 calls to OpenGL ES, but I'm not sure how good this works. There are already some threads here on Armbian forum about it. For example, one test which can properly determine if OpenGL ES works is glmark2-es2

I think it was developed with 64 bit ARM CPUs in mind, so that UEFI layer doesn't work properly on 32 bit ARM CPUs yet.

If it would be trivial or very easy, it would be done already, I guess. Here you have some additional details (FEL section): http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/README.sunxi64;h=c492f749b8bbe3a7418f29fa4050dee9251c64fb;hb=HEAD You can ask question also on IRC (#linux-sunxi, freenode), but you might have to ask question several times over few day period since people with this knowledge are not always present.

There is some hope, since there was last minute attempt to properly fix DT. I guess we will know in a day or two.

Unfortunately, driver bindings will be probably reverted before 4.13 ships and thus no out of the box dwmac driver. More info: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/528529.html

Nope, since mainline U-Boot don't support booting over FEL on 64-bit Allwinner SoCs yet. AFAIK, it is possible, just not implemented and till now, I didn't see any attempt to implement it.

there are 3 possible reasons or mix of them: - resolution issue - legacy kernel supports only standard resolutions like 1280x720 or 1920x1080. Description of your adapter sadly doesn't say if it supports autoscaling or it supports only native resolution of the panel. Let's hope it is first. - HDMI/DVI mode - since your screen doesn't seem to support sound, it would probably be better to switch to DVI mode (-d switch for h3disp). - colors - "-c" switch with h3disp Did you try to use "-d" and "-c" switches when you played with h3disp? If not, try with -d first and then with -c.

You can ask on IRC (freenode server, #linux-sunxi) where most of devs hangs out, but as far as I know, no thermal sensor patch exist for A83T. Chip is not popular...

Mainline kernel currently relies on U-Boot to properly set up HDMI screen. Can you tell me which exact version of U-Boot you have? Latest version is 2017.07, which have some fixes for HDMI monitors which don't support HDMI audio. It is included in latest Armbian. I can't tell if your monitor supports HDMI audio or not, since you gave us only panel model but not the name of electronics module which converts HDMI signal to something your panel understands.

Please note that H3 datasheet says that only H.265 codec supports decoding 4K videos. But since there is no public documentation of that piece of HW, other codecs might also support decoding 4K video, but I wouldn't count on it.

Of course, consider following line in drivers/video/videomodes.c char *p = getenv("video-mode"); Please note that video drivers are loaded very quickly, before U-Boot command line, so variable has to exist before. This can be achieved by setting variable and save it with "saveenv" command.

Actually you can't do much except patch U-Boot. H3 and newer chips uses driver in U-Boot which doesn't consider video-mode variable. Since kernel relies on U-Boot to set up HDMI for now, the only thing you can do is to create U-Boot patch and rebuild the image on your own. You only need to change line 131.

It has only IR receiver, so no, it is not possible without additional HW and probably some driver compiling. EDIT: Zero actually doesn't have IR receiver also, only with expansion board...

It seems that numbers in hdmi driver are wrong for this mode. Here is a patch which might solve the issue, although not tested for obvious reasons: https://transfer.sh/UCKIH/zzz-fix-video-modes.patch Note that link is valid only for 14 days. You can add this patch to build system and build your own image. If it works, we can include it in upstream repo. Although if you are not familiar with linux, this might be a nice challenge, but you will learn a few things along.

Currently that is not possible yet due to missing DRM driver, but it is in the works.

I can sent patches to mainline U-Boot for H3/H5/A64. I have never sent patches to Linux (but soon), but that shouldn't be a big problem to set up. However, I would rather see that original author of the patch is the one who sends it. It is very uncommon to send a patch of another person unless it is a serie of multiple patches where at least one is signed-off by a person who sends it. patman (tool in U-Boot) makes it easy to send a patch and it can be used for mainline Linux too.

You want to say that you can't get image on screen back? Not even after reboot? That would indicate broken script.bin. Maybe you can try that on fresh installation on spare card? Mentioned metod works, tested by me (in the past) and someone else.

That looks very promising code-wise. I will get rock64 soon and definetly test your project. Do you have any issue tracker for Kodi related issues? Do you have zero copy rendering or do you render through GPU?