jernej
-
Posts
1145 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jernej
-
-
FYI, backported driver completely ignores IR settings in fex file. They are used only for resuming from sleep, IIRC.
-
Uh, I was wondering what's that for. I didn't think it could be directly connected to CEC
Currently I can't help you much. Maybe in a few days?
EDIT: Which registers exactly?
EDIT2: I see, I think it would be safe to call this function only at driver init, at least that mainline driver does. I will test once I will have time.
-
Ah, ok. I thought that AP6210 is used mostly because all FW files in Android image reference it as AP6210 and extracted fex file has secondary UART enabled with flow control, which is usually used by bcmdhd for bluetooth.
@markbirss, so nothing to test then.
-
Just out of curiosity, how did you found HDMI_H3_PHY_CEC register at address 0x1003c?
-
Continuation from here: http://forum.armbian.com/index.php/topic/1380-h3-kernel-repo/?p=10663
Yes. Mali is just the 3D engine. But afaik you can at least display the frame with an EGL window (native or X based).
For rendering it should be possible to use the vdpau presentation queue API or use the display ioctls directly in the app...
Depends... In case of Kodi, i'm a friend of adapting libvdpau-sunxi to imitate the nvidia/gl interoperation as near as possible to the spec. Just using neither nvidia nor gl but sunxi and gles
It is and will always be a hack, because vdpau is not intended to work on ARM at all.But If we can achieve this, the adaptions within e.g. kodi should be not that big. I have some minor success with nv_gles_interop and VDR (www.tvdr.de) already. But now we really get offtopic
Regards rellla
Interesting, it seems that even Tegra doesn't have VDPAU support. I concur that gles interop is most portable one, but it's not the most efficient, at least for H3. Maybe we could support both, presentation queue api and gles interop, with a switch in settings. Then both could be evaluated.
I saw some problems mentioned in regards of bandwidth capabilities on A10 (or A20?). Do you know what was that about? HW scaling and compositing is not possible at FullHD resolution? Could Mali mitigate the issue?
-
Let's continue that conversation in Kodi topic.
-
Uh, I checked original fex file extracted from Android image and there is a good chance that bluetooth could work. If someone is interested, just ask and I will prepare instructions for it (blindly, cos I don't own this board).
-
It seems that bluetooth is present on AP6210 but unfortunatelly not connected to SoC (based on fex file).
There might be easier way to make this driver work. ap6210 and ap6212 folders could be merged to one (for example, /lib/firmware/bcmdhd) and nvram.txt files renamed to something like nvram_ap6210.txt and nvram_ap6212.txt Then kernel config should be fixed to point to this merged folder. After module is rebuild, we could load bcmdhd based on board with only
modprobe bcmdhd nvram_path=/lib/firmware/bcmdhd/nvram_ap6210.txt
for example...
-
Firmware is missing. Extract https://transfer.sh/h6nda/ap6210.tar.xzto /lib/firmware so you will have /lib/firmware/ap6210 folder. Then unload bcmdhd driver if it is already loaded and load it with following command:
modprobe bcmdhd firmware_path=/lib/firmware/ap6210/bcmdhd.bin nvram_path=/lib/firmware/ap6210/nvram.txt
NOTE: Download link will be valid only for 14 days, but until then it will be fixed, I guess.
-
Can you post full output of dmesg after bcmdhd driver is loaded? It could be that we just need to find right wifi firmware to make it work.
-
@Melanrz,
no, it works without board modifications. That is the beauty of it.
@jodamm,
while I couldn't test it due to bad TV CEC support but others did and they report that everything works if TV is already on. Once you turn off and on again TV, it stops working. I compared your kernel code with the imx6 one and I noticed that your code doesn't have "HDMI cable connect/disconnect" hooks. Do you think that is the reason?
-
Ah, sorry. Completely missed that. BTW, I'm testing with 3.0.1.
-
I will port it, no problem. Currently it doesn't apply cleanly due to a newer driver used, but there isn't much to fix. Just out of curiosity - wouldn't be better to use libvdpau-sunxi presentation framework for rendering? Mali was not designed for rendering/scaling/compositing video, especially for 4K, while Display Engine 2.0 (H3 video driver) used in libvdpau-sunxi is designed exactly for that.
-
Just a few small observations:
1. Could you change SUNXI_ADAPTER_PID to something else? On systems with imx6 patches also applied, libcec crashes (OpenELEC).
2. Your kernel patch from server doesn't apply cleanly due to different end of line marker. Patch downloaded from github works, though.
3. Documentation has a typo. It suggests using "cmake -DHAVE_SUNXI_LIB=1 .." while it should "cmake -DHAVE_SUNXI_API=1 .."
Great job otherwise! I will test it tomorrow hopefully.
-
rellla,
I think you are right about subtitle rendering. pixman issue should not affect Kodi.
I'm not yet in the contact with mosterta, but I guess it would be beneficial. There are some parts in the code, which seems to render image once through vdpau and once through gles... But this is off topic here. H3 kernel has some issues with sound, which should be resolved first, I guess.
The problem with userspace mali r4p0 blobs is that they don't have clear usage license. Whitewind has them on github without any info where they came from. I and some others suspect that Steven/Xunlong provided them on forum or through e-mail, but that has to be confirmed.
@Igor, can you ask Steven about those mali drivers? Forum thread is extremely long...
-
You have done similar thing that is done in the patches. One patch "forbids" using 24 bit sound output and other properly founds all sound outputs and mark sndhdmi output as HDMI audio output (it is threated a bit in a special way, like enabled passthrough and other things). This is as far as you can get without patching. HW video decoding needs some changes, on which I intend to work in the future.
-
Thanks for at least some encouragement
While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure. -
Actually, white RCA connector has also wrong ground connection. It would be better to fix in on 3.5 mm side - somehow switch parts marked 3 and 4. If you have some soldering skills it would be easier just to buy 4 pole 3.5 mm connectors (male and female) and make an adapter cable... Or just buy a proper cable. It goes under name "Apple iBook AV cable" or some others mentioned here: http://anythingbutipod.com/2006/04/zen-vision-m-video-cable-other-4pole-35mm-pinouts/
-
Try build Kodi with abovementioned patches until kernel issues are resolved.
-
-
If you bought TV cable from Xunlong, I must disappoint you that you have wrong cable - ground and TV signal are inverted which means that you might get picture only if you try to gently pull out connector for few milimeteres, but definetly no sound, because instead of ground, you have TV signal there which completely scrambles the sound.
Image which I show you means that if you measure conductivity with a multimeter, all rings on RCA connector (don't know how to call it) should be connected to "4" on 3.5 mm jack. Xunlong cable has those rings connected to "3" on 3.5 mm jack. You should check that.
-
Seems ok, but maybe would be good to compare fw extracted from offical image to AP6212 fw included in armbian.
-
You changed disp_init section wrong. Test this:
[disp_init] disp_mode = 1 screen1_output_type = 2 screen1_output_mode = 14
Note that TV works on screen1 only.
And another detailed picture how the cable must look like: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1349&page=3#pid12309Video signal in this case is labeled as "3"
-
Unfortuantelly I don't have any camera to connect on the board. It was interesting to me to spot the difference.
[WIP]hdmi cec driver for H3
in Allwinner sunxi
Posted
Maybe something like this: https://transfer.sh/12Ss3a/linux-011-disp2-keep-cec-signals.patch
It preserves HDMI_CEC_MASK and HDMI_CEC_MASK, doesn't make software reset in HDMI_MC_SWRSTZ register and doesn't disable clock in HDMI_MC_CLKDIS register. Only question remains if register at address 0x10020 could hurt this or not.