For integrators

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.

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.

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.

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.

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.

For implementors

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.

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.

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.

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.