[infinity85]

[...]
I have not plugged the RPi code into the current release yet. There are some Kodi 3D GUI options I see sitting in there that may or may not work on AML.

Code:

cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!

You would have to ask Raybuntu over on the HK C2 forums about this as its to do with the new Hybrid CEC control code in the Kernel.
[...]

With RPi code you are referring to the possibility of autoswitch to 3D on TVs or something else?

Out of logic the automatic 3Dswitch for TVs should be linked somehow to the automatic framerateswitching in kodi. As framerateswitching is working for 2D material with 60hz, 50hz for IPTV and 24hz for Blurays the basics are there I assume.

Here I looked at the modes the rpi uses in my most usecases (tvservice -s)

• Kodi Gui: state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
  
• LiveTV (IPTV Simple Client): state 0x12000a [HDMI CEA (31) RGB lim 16:9], 1920x1080 @ 50.00Hz, progressive
  
• 3D movies: state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
  
• 2D movies: state 0x12000a [HDMI CEA (32) RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
  

Its the list of modes my RPi gives me... if this could be useful somehow...:

Code:

OpenELEC:~ # tvservice -mCEA
Group CEA has 18 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced 3D:TopBot|SbS-HH
           mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
           mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced
  (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive 3D:TopBot|SbS-HH
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced 3D:TopBot|SbS-HH
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
           mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive 3D:TopBot|SbS-HH
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive 3D:TopBot|SbS-HH
           mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive 3D:TopBot|SbS-HH

Thanks for referring to Raybuntu! I will ask him about this. Actually I am not using CEC for the remote, so I did not notice anything yet except these errormessages.


EDIT:
Another comparison testrun on Raspberry Pi with a Half-SBS file:

a) If using 3D.SBS. flags in filename (without stereoheader=1) and having activated Support MVC video (full frame 3D) in settings:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

So the Raspberry tricks the TV into automatic 3D switch by sending some kind of FramePacked signal (but the video is not really sent framepacked to my TV I think.


But more interesting is the next try...

b) If using 3D.SBS. flags in filename (without stereoheader=1) and having deactivated Support MVC video (full frame 3D) in settings:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D SbS RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

Here is nothing related to framepacked, so triggering the TV into 3D must be somehow possible without using a framepacked signal or impuls or so.