On 04.07.2017 16:25, Ville Syrjälä wrote:
On Tue, Jul 04, 2017 at 03:58:02PM +0200, Andrzej Hajda wrote:
On 04.07.2017 14:44, Ville Syrjälä wrote:
On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote:
On 03.07.2017 21:19, ville.syrjala@linux.intel.com wrote:
From: Ville Syrjälä ville.syrjala@linux.intel.com
Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the infoframe even when strictly not necessary (ie. no VIC and no S3D). HDMI 1.4 does allow for this behaviour, stating that sending the infoframe is optional in this case.
My impression from the specs is that it should be done only after switching from 3d to 2d mode. In such case we just need to remember previous mode, if it was 3d, empty VSIF infoframe should be still generated for 2seconds. No need to do guesses from EDID. Am I right, or just missing something?
This code has no idea about any 3D->2D transitions, trying to make it do that would just result in a lot of complexity. Much easier to just always send the infoframe.
With such approach I see following 'issues': 0. It does not follow advices from specs.
Sure it does. The spec says you should keep sending it for at least two seconds, but it doesn't say that you can't keep sending it for longer, or even when there are no 3D->2D transitions.
- It changes behavior of old drivers, probably in harmless way but
still there can be some sinks which will stop working.
I think this is a justified risk. If we start to worry too much about every little change we stop making progress altogether. I did minimize the danger by making sure we don't send it for pre-1.4 sinks, and I was almost leaning towards not checking for that. But then I saw some language in the spec which might be interpreted to mean that the source isn't allowed to send unknown infoframe types to the sink, and I figured that maybe it's better to play it safe.
- What if EDID does not advertises 3d/4k modes but the sink supports
it, in such case userspace can set 3d mode, but after switch 3d->2d empty infoframe will not be sent.
IMO no point in worrying about broken EDIDs until one is proven to exist.
I though the whole 'fake edid' interface, possibility to provide custom mode, and avoiding connector:mode_valid in such case is enough proof of existence of such EDIDs. Internet is also full of advices how to force certain mode (also 3d mode), even if EDID does not advertise it.
- With this patch connector is required to generate infoframe, but
there are pipelines where infoframe can be generated in non-connector driver, for example: crtc -> hdmi_encoder -> mhl_encoder -> connector In such case encoder has no access to the connector, of course it can violate abstraction layers and localize one, but it shows that something here is probably wrong.
Just pass the connector down if needed. We'll need the connector to decide whether to send the new CEA-864-F VICs or not as well. And you could need it (well really the connector state) to figure out the value if some connector properties and whanot.
Also I didn't actually run into any cases where the connector is unavailable in the tree.
Not unavailable, just requires digging across layers.
Maybe another helper drm_hdmi_vendor_infoframe_from_connector will be enough to solve it. 4. Video mode provided by user has nothing to do with EDID, why infoframe generated for that mode should depend on EDID.
All above 'issues' are not serious ones but suggests that the solution is not the ideal one.
On the other side I do not see much complication in 3D->2D transition, it requires just recording if 3d mode was set before and again drm_hdmi_vendor_infoframe_from_connector can perform this check.
Well, then we'd have to pass in the old and new crtc/connector states etc. We don't want to start maintaining some custom state in the infoframe helpers that bypasses the normal atomic state handling altogether.
I understand, on the other side the issue the patch tries to solve has such nature.
And what causes us to stop sending it after the 2 seconds? Is two second the correct amount of time or should we do it longer? etc.
I though here about simpler approach: to send frame always after 3d mode was ever used. Approach with 2s timeout would require more work on drivers side.
So this line of thinking leads to a lot of new problems we can avoid by keeping it simple.
I have pointed out some weakness IMO, but as I said earlier they are non-blockers, so if you still think this approach is better it is OK.
Regards
Andrzej