Khronos Frequently Asked Questions


Why do the Composition and Display APIs have similar features for on-screen composition?

Both of the APIs can perform similar operations to the inputs and output to a screen. By having overlapping features it is not neccessary to implement both APIs, but choose the most suitable one. A WFD device is intended to expose the limitations of the underlying HW. There may be for example a limited number of pipelines in the display controller HW. A WFC device can always compose to memory, so it can overcome limitations by outputting intermediate results to memory and using them again as input.

When would it make sense for a WFD implementation to expose no pipelines?

The expected case for zero exposed pipelines is when the same manufacturer provides a WFD implementation as well as other graphics composition APIs, for instance WFC, such that exposing the WFD pipelines would be unnecessary since other more capable, less limited, composition graphics APIs exist. Given this case, the WFD implementation would be used to manage and configure the display hardware, but not be involved in the composition of displayed content.

What is the purpose of the "attribList" parameter of the WFC or WFD "create" functions?

The creation attribute list parameters are expected to be one of the primary means of extending the functionality of the APIs. At the moment most of the create functions do not have any defined attributes that can be passed in, but providing this feature allows for extensions to be written for these APIs in a fairly clean manner.

Why are the WFC & WFD extension query functions different than other Khronos APIs?

The OpenWF extension query functions (GetStrings, IsExtensionSupported) were developed per recommendations from several of the other Khronos working groups. Members of these other working groups have found that the previously defined methods are more cumbersome then expected, so suggestions were made to address this. It is expected that other Khronos APIs will, over time, move towards this new style of extension functions.

What is the point of allowing creation of more than one composition device with the same device ID?

As the multiple devices created from the same ID do not share any state, it is possible to create a device – context pair for each screen supported by the device and have a separate error state for each screen/ context.

Why is the WFD pipeline direct refresh attribute _not_ available for stream input?

The thought was that in the streaming case there is no need for the user to be aware of this since the buffers are provided/managed by the stream, not the user.

How can a WFC implementation access the screen using WFD API?

If a WFC implementation tries to access the screen using the public WFD API, it is likely to result in an error or preventing other clients from using WFD. The reason is that WFD API allows only one device instance created per device ID. It is recommended that interaction between the two APIs is handled using a propriety solution.

How and when is the WFD pipeline layering order decided?

Layering order of the WFD pipelines that can be bound to a particular port is expected to be a static feature of the implementation and likely of the hardware itself. For shareable pipelines, those that can be bound to more than one port (not simultaneously), the layering number of the pipeline for each port may be different, but the layering number in relation to a particular port is intended to be static.

What is the purpose for the WFD pipeline direct refresh attribute?

The WFD pipeline direct refresh attribute is intended to indicate to the client that the hardware is refreshing from the client provided directly bound image buffer. This is intended to denote to the client that any changes to the bound buffer contents may cause visual tearing or other display artifacts.

Does WFD support sharing of object handles?

The WFD specification was written with the expectation of a single client, the platform windowing system. The WFD object handles are single instance handles, meaning only one handle to an object can be created at any point in time. WFD handles are intended to be safe for use by multiple threads, in the same process, but the handle sharing mechanism is left to the API user.

Are OpenWF APIs thread and process safe?

The API specifications note that thread safety is indeed a goal. There is no requirement for per thread data storage. All API functions are intended to be safe when accessed from multiple threads within the same process. The subject of process safey is not addressed by the specifications. Process safety is left to the API user to resolve.

What pixel formats are supported by WFC or WFD APIs?

Input or output pixel formats are not addressed by the API specifications. Functions involving pixel input and output typically raise an error, if an unsupported format is used. To avoid trial and error type of usage, the native stream type, and/or EGL image type, may allow querying for supported pixel formats.

What is the minimal agreement our company has to get in with Khronos to access Conformance test Suite for OpenVG (till 1.1), OpenGL ES (till 2.0) and OpenWF drivers?

All Khronos members which have accepted the Conformance Test Source License Agreement (CTSLA) section of
the Member’s agreement can access all conformance test suites for those APIs
for which a conformance test program is in place for no additional fees
beyond the annual membership fee.

In order to submit a product for certification, there is a one-time adopter
fee of $10,000 for Members, $15,000 for non-members. The adopter fee is
one-time for the life of the API version and allows for unlimited product
submissions with no additional fees.