Some fields need to be removed or renamed

[TimWei888]

DisplayPort_Product_Summary
Device_Power_Source (USB VIF has this information already)

SOP_DP_Capabilities

1. The following fields need to be removed

• DP_Receptacle_Indication (I think this should be removed, but seems Jacob want to keep it and check the consistency of it vs the Captive_Cable USB VIF field)
• Signaling_For_Transport_Of_DisplayPort_Protocol (because there is only 1 possible value: 1)
• DP_Alt_Mode_Version (this is the same as the DP_Version field)
• DP_Mode_Auto_Entry (no such device has ever been seen, and if there is one, we don't know how to test it)

2. USB2_Used needs to be renamed to USB2_Not_Used

SOPP_DisplayPort_Capabilities

1. All fields need to prefix with SOPP_
2. DPAM_Version needs to be removed

DisplayPort_Status
DP_Src_Sink_Device_Connected needs to be removed because this is a dynamic field

[bleungatchromium]

DP_Receptacle_Indication (I think this should be removed, but seems Jacob want to keep it and check the consistency of it vs the Captive_Cable USB VIF field)

@TimWei888 I would also vote to keep the field in the VIF tool, since in my observation the DP_Receptacle_Indication bit is older and more consistently implemented compared to the one in USB PD's ID Header VDO. I actually added the receptacle indication in ID Header VDO, and I recognize it was only present in most recent USB PD implementations.

The DP one came first, so we should use it for consistency check.

Also, the value returned for Receptacle Indication here has implications for the VIF tool description as well, now that I think about it. Basically, if the VIF is describing a product that has a receptacle, then all of the fields in the VIF regarding SOP' are irrelevant, since the product being tested doesn't inherently have a SOP'. In test, the test equipment will provide a SOP' where it makes sense.

However, if the VIF describes a captive plug, then the product contains a captive cable, and if it's DPAM 2.1, it must be e-marked, so a SOP' is expected, and should be tested for (and therefore, the test equipment does not need to emulate a SOP' when testing this product).

What do you think, Tim?

[alevkoy]

USB2_Used needs to be renamed to USB2_Not_Used

I'd prefer to reverse the values of the field and keep the name as USB2_Used. That would be incompatible with previously generated VIFs, but it would avoid having to think about a double negative while filling out the fields.

DP_Mode_Auto_Entry (no such device has ever been seen, and if there is one, we don't know how to test it)

I didn't understand quite what this means in the spec. I took it to be a source that will enter DP alt mode when it sees that it's available, without waiting for some action on the part of the tester. If that's what it means, I would think this would apply to most DP sources.

DP_Alt_Mode_Version (this is the same as the DP_Version field)

I don't think that you can support DP 2.1 with alt mode version 2.0. But I think you may not support DP 2.1 while supporting DPAM 2.1, e.g. you use the DPAM 2.1 to advertise that you only support DP 1.4. If that's valid, then I don't think these fields mean the same thing.

[TimWei888]

I was not talking about the field in the ID header, I was talking about the VIF field Captive_Cable in the USB VIF, which has been there since the very beginning. I don't have a very strong opinion here, I am fine to keep this field.

DP_Receptacle_Indication (I think this should be removed, but seems Jacob want to keep it and check the consistency of it vs the Captive_Cable USB VIF field)

@TimWei888 I would also vote to keep the field in the VIF tool, since in my observation the DP_Receptacle_Indication bit is older and more consistently implemented compared to the one in USB PD's ID Header VDO. I actually added the receptacle indication in ID Header VDO, and I recognize it was only present in most recent USB PD implementations.

The DP one came first, so we should use it for consistency check.

Also, the value returned for Receptacle Indication here has implications for the VIF tool description as well, now that I think about it. Basically, if the VIF is describing a product that has a receptacle, then all of the fields in the VIF regarding SOP' are irrelevant, since the product being tested doesn't inherently have a SOP'. In test, the test equipment will provide a SOP' where it makes sense.

However, if the VIF describes a captive plug, then the product contains a captive cable, and if it's DPAM 2.1, it must be e-marked, so a SOP' is expected, and should be tested for (and therefore, the test equipment does not need to emulate a SOP' when testing this product).

What do you think, Tim?

[TimWei888]

USB2_Used needs to be renamed to USB2_Not_Used

I'd prefer to reverse the values of the field and keep the name as USB2_Used. That would be incompatible with previously generated VIFs, but it would avoid having to think about a double negative while filling out the fields.

This is the way it is defined in the spec "USB 2.0 Signaling Not Used", I like the VIF definition to be the same as what in the base spec, so that we can use the value directly.

DP_Mode_Auto_Entry (no such device has ever been seen, and if there is one, we don't know how to test it)

I didn't understand quite what this means in the spec. I took it to be a source that will enter DP alt mode when it sees that it's available, without waiting for some action on the part of the tester. If that's what it means, I would think this would apply to most DP sources.

I don't understand what this means either, I have never seen any DPAM UUT works differently from others, maybe we should clarify this in the working group meeting.

DP_Alt_Mode_Version (this is the same as the DP_Version field)

I don't think that you can support DP 2.1 with alt mode version 2.0. But I think you may not support DP 2.1 while supporting DPAM 2.1, e.g. you use the DPAM 2.1 to advertise that you only support DP 1.4. If that's valid, then I don't think these fields mean the same thing.

You raised an interesting point here. Let's discuss it in the working group meeting. Even it's true, we should move it to the DisplayPort_Product_Summary group, we should not allow an UUT to have different DPAM version on SOP and SOP Prime.

[alevkoy]

This is the way it is defined in the spec "USB 2.0 Signaling Not Used", I like the VIF definition to be the same as what in the base spec, so that we can use the value directly.

That's fair. Objection withdrawn.