Skip to main content

Clarification of supported generic feature list

1 reply [Last post]
suntec
Offline
Joined: 2010-10-13
Points: 0

At boot time, the RI stack updates the basic card information by calling the "updatePODDatabase" method and this information is used when some APIs of org.ocap.hardware.pod.POD are called.

The difference between OCAP API doc and RI about generic feature makes me confused.

According to OCAP API doc, POD.java gets the feature list supported by the Host device and get/set the feature param of the Host device.

But, mpe_podmgrGetFeatures() and ri_cablecard_get_supported_features() seems to be focused on the feature list supported by the CableCARD.

Currently, the RI defines that all 12 features are supported by DRI.
But, in the real CabelCARD, if the Host device only supports the feature ids (1,2,3,4) and the CableCARD device supports the feature ids (3,4,5,6),
what values should be return by calling POD.getHostFeatureList() ?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03
Points: 0

The MPEOS porting APIs only exist to satisfy the requirements of the OCAP stack. Since the Java POD APIs only return host features, the MPEOS POD APIs should only return host features.

I can see from the comments above mpe_podmgrGetFeatures() why you would be confused. We will update these comments. mpe_podmgrGetFeatures() is responsible for returning host features and not card features.

In our PC Platform ri_cablecard_* APIs are only meant to satisfy the CableCARD-related requirements of the stack. The features we emulate in the ri_cablecard module are still host features, since that is all the stack needs.

G