[infinity85]

I wouldn't expect a C2 to switch a TV to H-SBS mode when playing H-SBS content - though it may have the ability to send the required data over HDMI it may not.

AIUI the Pi can be persuaded to output H-SBS as Frame Packed (with the Pi doing the 2:1 stretch for each eye feed rather than the TV) - and that will definitely trigger 3D.

hmmm.. I think I don't understand this completely with the 2:1 stretch. If I don't set the header to 1 (SBS) or 3 (TAB) the pi simply outputs the regular 2 eyed picture as a 2D. So both eyes side by side. That is not a strech of 2:1 correct? So how could I imagine the 2:1 stretch that you mentioned?

There are three ways to output HSBS 1080p (which is two 1920x1080 eye feeds 2:1 compressed to 960x1080 and put next to each other in a single 1920x1080 frame) over HDMI :

1. Output HSBS as if it is 2D 1920x1080. Don't do anything out of the ordinary. As far as the TV is concerned it is receiving a normal 2D image until you press the 3D button and select an SBS mode.

2. Output HSBS as a 1920x1080 video as above - but set a flag in one of the HDMI data packets that signals that the video signal contains HSBS content triggering the TV to automatically go into SBS mode.

3. Convert HSBS to a 1920x1080 3D Frame Packed output (in reality this is 1920x2205 video signal with two 1920x1080 eye feeds separated by 45 lines of blanking) The Pi is doing the 2:1 stretch to convert each 960x1080 eye feed to 1920x1080 before outputting (rather than leaving the TV to do it) This is - I think - what one of the 3D options does.

I suspect the ODroid is currently doing 1? but the Pi does 2 and/or 3?

Generally: It would be a real pity for this device if it could not trigger 3D on the TV. It can do almost everything now... I'm wondering what the Pi does over HDMI to trigger 3D on my TV. As it can also do HDMI CEC (which is not responsible for the automatic 3D switch, though) and so on, I thought there should be a quite complete featureset regarding HDMI compatibility :/

The Pi platform seems to 'do' 3D a bit better. It has Frame Packed output and seems more 'aware' of some aspects of HDMI as a result? Or maybe the C2 devs just haven't got there yet. (Though I think Frame Packed output may be a lost cause?)

phuh, interesing post! I will have to read it again with a fresh head tomorrow morning xD. Do you have an idea how to find out what the pi does with a particular testfile?

Tried now this "tvservice -s" on my Raspberry Pi2 (OpenELEC 6.0.3) playing a H-SBS File:

Code:

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

1. File was with headersetting 1 (SBS): Switched TV automatically to 3D mode
2. Same file without headersetting: TV did not switch. Displays both eyes side by side, have to switch manually


Tried the same on my Odroid with LibreELEC... the service is not there haha:

Code:

LibreELEC:~ # tvservice -s
-sh: tvservice: not found

But did a "dmesg output" also on my Odroid and found this here (different topic):

Code:

[   19.671596] cectx c810023c.aocec: aml_cec_class_devnode(): mode is 1b6
[   19.736898] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   19.772518] CEC: tx msg len: 1   dat: 2b
[   19.936798] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   19.972447] CEC: tx msg len: 1   dat: 2c
[   20.136731] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.172415] CEC: tx msg len: 1   dat: 2c
[   20.336699] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.372555] CEC: tx msg len: 1   dat: 2d
[   20.536830] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.572546] CEC: tx msg len: 1   dat: 2d
[   20.736819] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.772713] CEC: tx msg len: 1   dat: 2e
[   20.936988] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.972517] CEC: tx msg len: 1   dat: 2e
[   21.136789] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   24.906993] cectx c810023c.aocec: aml_cec_class_devnode(): mode is 1b6

Any Idea why this TX error appears? I think this is the reason why I broke my head about not getting my RemotePi Board (msldigital) to work on the Odroid C2 with standard GPIO pinning