jernej

No, there is not. As I said, it's been done, albeit not with the same environment, if we've been talking about the subtitles, overlaping and other similar things. Direct rendering could only help the performance and that is the thing someone usually desire, so it is already implemented in libvdpau-sunxi. Here we are talking about video layer Z (depth) order and if there is possibility to put playback layer below framebuffer and how that would be achieved without painful calculations of the visible window region.

I just figured it out. Taking shortcuts rarely pays off, so I need to do this fb screen size setting differently. Zador, thanks for all your help.

That means that something still reports 1920x1080 screen size.

Please do.

No need, boot logo is great indicator if everything is fine. Kodi needs some additional code to get screen width and height, which may be wrong. Maybe I used wrong term - proportions is not the right word, because image should stretch to full screen. I meant if it looks ok. Last request before I dive into the code again. Please upload kodi log located at /storage/.kodi/temp/kodi.log

What about boot screen? Does it have right proportions, e.g. nicely centered? Can you also please check which resolution is reported in "System Info" in Kodi?

Here is another OPiPC test image: https://transfer.sh/JxiVl/openelec-h3.arm-7.0-devel-20161020202145-r23108-g97f809b-opipc.img.gz Framebuffer size is still 1920x1080 in size, but only the portion corresponding to HDMI resolution is used. That reminds me, EDID resolutions, which are too big, must be discarded...

Highly depends how X11 rendering is done. I'm not willing to dig through all X11 code, so I guess I will just try it one time and see what happens.

Yes, fb0 has zorder 0, but this is completely hidden to rendering SW, even fb driver is not aware of that. That means that you can freely reorder layers and set alpha values, which I did with a few lines of code. Only one question remains - what alpha value has non occupied part of the window. In my case, mali drivers always set it to completely transparent, so this principle works. Unfortunatelly, that also means that script.bin must be correctly set - framebuffer has to have alpha channel.

Weird, I don't see the reason why that shouldn't be possible. In fact, I'm doing just that in my OpenELEC fork. Maybe someone on IRC will know the answer. I also don't see any reason why would that affect fbturbo driver. Is there any special disp2 version? Which sources are used by Armbian?

Yes, these few lines should be added at open: https://github.com/jernejsk/OpenELEC-OPi2/blob/openelec-7.0/projects/H3/patches/kodi/kodi-005-H3-support.patch#L680-L694and those at close: https://github.com/jernejsk/OpenELEC-OPi2/blob/openelec-7.0/projects/H3/patches/kodi/kodi-005-H3-support.patch#L680-L694 Which values have you in mind? I guess best way to discover if it works is to test it.

Heh, it seems that zhaolei merged WereCatf improvements 9 hours ago, so I guess zhaolei's version is now better. Are you ok with current state, e.g. copied libraries and executables, or do you want to have everything packed as a plugin?

Someone on OrangePi facebook group said that he will try to port my code from OpenELEC which puts video layer in the background and normal layer in foreground. I guess that he didn't try that yet. Are you willing to do that?

Yes, they seems to be correct, but still resolutions at the end for 1280x1024 monitor seems off. Can you check which supported resolutions are reported if you connect it throug HDMI adapter and which when you connect directly. It seems that VGA converter adds additional info, which is not correctly formed. I guess that xrandr should report all of them.

That would be most helpful, thanks.

Thanks. Timings seem to be calculated correctly. However, EDID dump is a bit misterious (a bit short comparing to dmesg edid output), but this may be bug in the driver. I guess that interlaced resolutions may need multiplication, but first let's make prefered EDID mode working. That is to be expected, because default framebuffer size is 1920x1080 and this is not fixed yet. I never saw your explicit confirmation: Is there any video ouput, albeit broken, on 1280x1024 monitor? If it is, we need to fix only framebuffer size and timings, I guess. Thanks for confirmation. I received enough informations for now and I have to fix few things before next try is needed.

Here is OPi PC image: https://transfer.sh/oj6zQ/openelec-h3.arm-7.0-devel-20161018225654-r23108-g97f809b-opipc.img.gz It reboots automatically at first boot and ssh must be enabled in wizard at first Kodi run, but you can easily use UART console. Dmesg can be uploaded by "dmesg | pastebinit". I noticed that edid parser produces weird modes on 1280x1024 monitors. Can you please upload "/sys/class/hdmi/hdmi/attr/edid" somewhere? is 1280x1024 mode confirmed working on Armbian? Hopefully all that info will be enough to resolve any discrepancies between Armbian 1280x1024 patch and my EDID parsing. BTW, image on 1280x1024 will be scrambled due to incorrect framebuffer size, but nevertheless, it should show something.

Well, then something else is wrong. Please check my example of output: http://sprunge.us/HPFVImportant parts are right after EDID parsing, from line "waited 760 ms for EDID info" onwards. Also something weird is going on with kernel mode resolution setting. My dmesg http://sprunge.us/eRAj clearly states "disp: edid mode for type 4 and disp 0 is set". I desperately need some non standard display to work on this code. I will try to obtain it...

Well, EDID info is always parsed. During parsing, it is always marked which modes are supported. Unfortunately, this info in current driver servers only as info to a userspace if requested over ioctl but otherwise is ignored. Once EDID mode will be properly implemented, it will automatically use only supported modes.

Thanks. It's weird. Some informations are missing. Does Armbian suppress "info" loglevel after userspace starts to execute? Can you try at least one with "ignore_loglevel" as kernel argument? TV reported 720p prefered. It seems that resolution is not properly propagated. Let me take a look. I guess 1080p monitor worked ok?

@zador, that would be the easiest. Here you can find the patch: https://transfer.sh/3tyen/hdmi-edid.patch Due to a yet unfixed bug, HDMI EDID mode is always on. All you have to do is to make sure that HDMI cable is connected before kernel starts to boot or else it will fall back to a kernel argument or script.bin setting. You can now also use kernel argument like "disp.screen0_output_mode=EDID:1280x1024p60". As I said, EDID is always on for now, even if not present. Please also include dmesg output in your response in both cases.

zador, I guess it is enough if I just build kernel deb package and give you instructions how to change boot.scr? I will try to prepare something in following days.

I'm not sure if hijacking Armbian forum is ok for my OpenELEC fork, but due to reachability issues I will answer anyway. You can open an issue on github with question label. Not sure on mpv but certainly doesn't support CEC. One thing which helps with lowering temperature is disabling RSS feeds. It will lower it for at least few degrees. I guess OE is hotter due to more intensive GPU usage. I think usual temperature settings are basically the same. Yes, pvr.iptvsimple is a folder inside build system. Please take a look at content inside this folder to get an idea what is needed to create custom plugin. AFAIK a big issue here in my opinion is that all plugins must be compiled statically or at least without external dependencies (other than already included in base image). RCSwitch has dependency on wiringPi. I already compiled it as a plugin (gpio program) and you can test it here (link will be valid for 14 days): https://transfer.sh/ILHOt/tools.wiringop-7.0.1.zipI will take a look if there is some way to compile plugins with external dependencies or else I may include wiringPi in base image. Does anyone know which wiringPi port for H3 is best? I used this: https://github.com/WereCatf/WiringOP/commits/h3

My HDMI changes can be found here: https://github.com/jernejsk/linux/tree/hdmi_wipBut I stopped a bit because I currently don't have display which isn't 1080p native. I confirmed that timings are correctly calculated for 1080p but with current progress that's about it. I need a result from a display with another aspect ratio in order to confirm that everything is working. Is anyone interested here in helping me with testing?

@Cubietruck, Please search for kodi log and upload it. I think it is located at /home/<username>/.kodi/temp But even if we manage to get it running, it won't be HW accelerated. For that you need modified Kodi. mosterta (https://github.com/mosterta) is trying to do that for A10/A20 boards. I don't have such board, so you should ask him for help. Usually, he can be found on IRC - #linux-sunxi channel on freenode.