Google Git
Sign in
fuchsia / reference-docs / main / . / f8 / sdk / fidl / fuchsia.sysmem / README.md
blob: c1ec787b5a9904093a0a15993c24590cdba23730 [file] [log] [blame] [view]
<link rel="stylesheet" href="../style.css" />
[TOC]
# fuchsia.sysmem
<div class="fidl-version-div"><span class="fidl-attribute fidl-version">Added: 7</span></div>
## **PROTOCOLS**
## Allocator {#Allocator}
*Defined in [fuchsia.sysmem/allocator.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/allocator.fidl;l=13)*
<p>Allocates system memory buffers.</p>
### AllocateNonSharedCollection {#Allocator.AllocateNonSharedCollection}
<p>Allocates a BufferCollection on behalf of a single client (aka initiator)
who is also the only participant (from the point of view of sysmem).</p>
<p>This call exists mainly for temp/testing purposes. This call skips the
BufferCollectionToken stage, so there's no way to allow another
participant to specify its constraints.</p>
<p>Real clients are encouraged to use AllocateSharedCollection() instead,
and to let relevant participants directly convey their own constraints to
sysmem.</p>
<p><code>collection_request</code> is the server end of the BufferCollection FIDL
channel. The client can call SetConstraints() and then
WaitForBuffersAllocated() on the client end of this channel to specify
constraints and then determine success/failure and get the
BufferCollectionInfo_2 for the BufferCollection. The client should also
keep the client end of this channel open while using the
BufferCollection, and should notice when this channel closes and stop
using the BufferCollection ASAP.</p>
#### Request {#Allocator.AllocateNonSharedCollection_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>collection_request</code></td>
<td>
<code>request&lt;<a class='link' href='#BufferCollection'>BufferCollection</a>&gt;</code>
</td>
</tr>
</table>
### AllocateSharedCollection {#Allocator.AllocateSharedCollection}
<p>Creates a logical BufferCollectionToken which can be shared among
participants (using BufferCollectionToken.Duplicate()), and then
converted into a BufferCollection using BindSharedCollection().</p>
<p>Success/failure to populate the BufferCollection with buffers is
determined via the BufferCollection interface.</p>
#### Request {#Allocator.AllocateSharedCollection_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>token_request</code></td>
<td>
<code>request&lt;<a class='link' href='#BufferCollectionToken'>BufferCollectionToken</a>&gt;</code>
</td>
</tr>
</table>
### BindSharedCollection {#Allocator.BindSharedCollection}
<p>Convert a BufferCollectionToken into a connection to the logical
BufferCollection. The BufferCollection hasn't yet been populated with
buffers - the participant must first also send SetConstraints() via the
client end of buffer_collection.</p>
<p>All BufferCollectionToken(s) duplicated from a logical
BufferCollectionToken created via AllocateSharedCollection() must be
turned in via BindSharedCollection() before the logical BufferCollection
will be populated with buffers.</p>
<p><code>token</code> the client endpoint of a channel whose server end was sent to
sysmem using AllocateSharedCollection or whose server end was sent to
sysmem using BufferCollectionToken.Duplicate(). The token is being
&quot;exchanged&quot; for a channel to the logical BufferCollection.</p>
<p><code>buffer_collection_request</code> the server end of a BufferCollection
channel. The sender retains the client end as usual. The
BufferCollection channel is a single participant's connection to the
logical BufferCollection. There typically will be other participants
with their own BufferCollection channel to the logical BufferCollection.</p>
#### Request {#Allocator.BindSharedCollection_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>token</code></td>
<td>
<code><a class='link' href='#BufferCollectionToken'>BufferCollectionToken</a></code>
</td>
</tr>
<tr>
<td><code>buffer_collection_request</code></td>
<td>
<code>request&lt;<a class='link' href='#BufferCollection'>BufferCollection</a>&gt;</code>
</td>
</tr>
</table>
### SetDebugClientInfo {#Allocator.SetDebugClientInfo}
<p>Set information about the current client that can be used by sysmem to
help debug leaking memory and hangs waiting for constraints. |name| can
be an arbitrary string, but the current process name (see
fsl::GetCurrentProcessName()) is a good default. |id| can be an arbitrary
id, but the current process ID (see fsl::GetCurrentProcessKoid()) is a
good default.
This information is propagated to all BufferCollections created using
BindSharedCollection() or AllocateNonSharedCollection() from this
allocator. It does not affect BufferCollectionTokens, since they are
often passed cross-process and should have their names managed manually.</p>
#### Request {#Allocator.SetDebugClientInfo_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>name</code></td>
<td>
<code>string[64]</code>
</td>
</tr>
<tr>
<td><code>id</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
### ValidateBufferCollectionToken {#Allocator.ValidateBufferCollectionToken}
<p>Validate that a BufferCollectionToken is known to the sysmem server.</p>
<p>This can be used in cases where BindSharedCollection() won't be called
until after BufferCollectionToken.Duplicate() +
BufferCollectionToken.Sync(), when the client code wants to know earlier
whether an incoming token is valid (so far).</p>
<p>Calling BufferCollectionToken.Sync() on a token that isn't known to
sysmem risks the Sync() hanging forever.</p>
<p>Given that an incoming token can become invalid at any time if any
participant drops their BufferCollectionToken(s) or BufferCollection(s),
authors of client code are encouraged to consider not calling
ValidateBufferCollectionToken() and instead dealing with async failure
of the BufferCollection.Sync() after all the
BufferCollectionToken.Duplicate() and BindSharedCollection() (before
sending any duplicate tokens to other processes).</p>
<p>Regardless of the result of this call, this call has no effect on the
token with the referenced koid.</p>
<p>A true result from this call doesn't guarantee that the token remains
valid for any duration afterwards.</p>
<p>Client code will zx_object_get_info() on the client's token handle,
passing ZX_INFO_HANDLE_BASIC and getting back the related_koid
which then gets passed to ValidateBufferCollectionToken().</p>
<p>If ValidateBufferCollectionToken() returns true, the token was known at
the time the sysmem server processed the call, but may no longer be
valid/known by the time the client code receives the response.</p>
<p>If ValidateBufferCollectionToken() returns false, the token wasn't known
at the time the sysmem server processed the call, but the token may
become known by the time the client code receives the response. However
client code is not required to mitigate the possibility that the token
may become known late, since the source of the token should have synced
the token to sysmem before sending the token to the client code.</p>
<p>If calling ValidateBufferCollectionToken() fails in some way, there will
be a zx_status_t from the FIDL layer.</p>
<p><code>token_server_koid</code> the koid of the server end of a channel that might
be a BufferCollectionToken channel. This can be obtained from
zx_object_get_info() ZX_INFO_HANDLE_BASIC related_koid.</p>
#### Request {#Allocator.ValidateBufferCollectionToken_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>token_server_koid</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#koid'>koid</a></code>
</td>
</tr>
</table>
#### Response {#Allocator.ValidateBufferCollectionToken_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>is_known</code></td>
<td>
<code>bool</code>
</td>
</tr>
</table>
## BufferCollection {#BufferCollection}
*Defined in [fuchsia.sysmem/collection.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/collection.fidl;l=225)*
<p>BufferCollection is a connection directly from a participant to sysmem re.
a logical BufferCollection; typically the logical BufferCollection is shared
with other participants. In other words, an instance of the BufferCollection
interface is a view of a &quot;logical buffer collection&quot;.</p>
<p>This connection exists to facilitate async indication of when the logical
BufferCollection has been populated with buffers.</p>
<p>Also, the channel's closure by the server is an indication to the client
that the client should close all VMO handles that were obtained from the
BufferCollection ASAP.</p>
<p>Also, this interface may in future allow specifying constraints in other
ways, and may allow for back-and-forth negotiation of constraints to some
degree.</p>
<p>This interface may in future allow for more than 64 VMO handles per
BufferCollection, but currently the limit is 64.</p>
<p>This interface may in future allow for allocating/deallocating single
buffers.</p>
<p>Some initiators may wait a short duration until all old logical
BufferCollection VMO handles have closed (or until the short duration times
out) before allocating a new BufferCollection, to help control physical
memory fragmentation and avoid overlap of buffer allocation lifetimes for
the old and new collections. Collections can be large enough that it's worth
avoiding allocation overlap (in time).</p>
### AllocateSingleBuffer {#BufferCollection.AllocateSingleBuffer}
<p>This allocates a new buffer that is consistent with the most recent call
to SetConstraints(), if possible. If not possible, this indicates the
failure via OnNewBufferAllocated().</p>
<p>Only a participant with write can do this. Coordination among multiple
participants with write is outside the scope of this interface.</p>
<p>The participant is (intentionally) never informed of other participant's
constraints.</p>
#### Request {#BufferCollection.AllocateSingleBuffer_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>buffer_index</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
### AttachLifetimeTracking {#BufferCollection.AttachLifetimeTracking}
<p>AttachLifetimeTracking:</p>
<p>AttachLifetimeTracking() is intended to allow a client to wait until an
old logical buffer collection is fully or mostly deallocated before
attempting allocation of a new logical buffer collection.</p>
<p>Attach an eventpair endpoint to the logical buffer collection, so that
the server_end will be closed when the number of buffers allocated
drops to 'buffers_remaining'. The server_end won't close until after
logical allocation has completed.</p>
<p>If logical allocation fails, such as for an attached sub-tree (using
AttachToken()), the server_end will close during that failure regardless
of the number of buffers potenitally allocated in the overall logical
buffer collection.</p>
<p>Multiple eventpair endpoints can be attached, with an enforced limit of
SYSMEM_LIFETIME_TRACKING_EVENTPAIR_PER_BUFFER_COLLECTION_CHANNEL_MAX.</p>
<p>The lifetime signalled by this event includes asynchronous cleanup of
allocated buffers, and this asynchronous cleanup cannot occur until all
holders of VMO handles to the buffers have closed those VMO handles.
Therefore clients should take care not to become blocked forever waiting
for ZX_EVENTPAIR_PEER_CLOSED to be signalled, especially if any of the
participants using the logical buffer collection are less trusted or
less reliable.</p>
<p>The buffers_remaining parameter allows waiting for all but
buffers_remaining buffers to be fully deallocated. This can be useful
in situations where a known number of buffers are intentionally not
closed so that the data can continue to be used, such as for keeping the
last available video picture displayed in the UI even if the video
stream was using protected output buffers. It's outside the scope of
the BufferCollection interface (at least for now) to determine how many
buffers may be held without closing, but it'll typically be in the range
0-2.</p>
<p>This mechanism is meant to be compatible with other protocols providing
a similar AttachLifetimeTracking() mechanism, in that duplicates of the
same event can be sent to more than one AttachLifetimeTracking(), and
the ZX_EVENTPAIR_PEER_CLOSED will be signalled when all the lifetime
over conditions are met (all holders of duplicates have closed their
handle(s)).</p>
<p>A maximum of
SYSMEM_LIFETIME_TRACKING_EVENTPAIR_PER_BUFFER_COLLECTION_CHANNEL_MAX
AttachLifetimeTracking() messages are allowed per BufferCollection
channel.</p>
<p>There is no way to cancel an attach. Closing the client end of the
eventpair doesn't subtract from the number of pending attach(es).</p>
<p>Closing the client's end doesn't result in any action by the server.
If the server listens to events from the client end at all, it is for
debug logging only.</p>
<p>The server intentionally doesn't &quot;trust&quot; any bits signalled by the
client. This mechanism intentionally uses only ZX_EVENTPAIR_PEER_CLOSED
which can't be triggered early, and is only triggered when all handles
to server_end are closed. No meaning is associated with any of the
other signal bits, and clients should functionally ignore any other
signal bits on either end of the eventpair or its peer.</p>
<p>The server_end may lack ZX_RIGHT_SIGNAL or ZX_RIGHT_SIGNAL_PEER, but
must have ZX_RIGHT_DUPLICATE (and must have ZX_RIGHT_TRANSFER to
transfer without causing CodecFactory channel failure).</p>
#### Request {#BufferCollection.AttachLifetimeTracking_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>server_end</code></td>
<td>
<code>handle&lt;eventpair&gt;</code>
</td>
</tr>
<tr>
<td><code>buffers_remaining</code></td>
<td>
<code>uint32</code>
</td>
</tr>
</table>
### AttachToken {#BufferCollection.AttachToken}
<p>Create a new token, for trying to add a new participant to an existing
collection, if the existing collection's buffer counts, constraints,
and participants allow.</p>
<p>This can be useful in replacing a failed participant, and/or in
adding/re-adding a participant after buffers have already been
allocated.</p>
<p>Failure of an attached token / collection does not propagate to the
parent of the attached token. Failure does propagate from a normal
child of a dispensable token to the dispensable token. Failure
of a child is blocked from reaching its parent if the child is attached,
or if the child is dispensable and the failure occurred after logical
allocation.</p>
<p>An initiator may in some scenarios choose to initially use a dispensable
token for a given instance of a participant, and then later if the first
instance of that participant fails, a new second instance of that
participant my be given a token created with AttachToken().</p>
<p>From the point of view of the client end of the BufferCollectionToken
channel, the token acts like any other token. The client can
Duplicate() the token as needed, and can send the token to a different
process. The token should be converted to a BufferCollection channel
as normal by calling BindSharedCollection(). SetConstraints() should
be called on that BufferCollection channel.</p>
<p>A success result from WaitForBuffersAllocated() means the new
participant's constraints were satisfiable using the already-existing
buffer collection, the already-established BufferCollectionInfo
including image format constraints, and the already-existing other
participants and their buffer counts. A failure result means the new
participant's constraints cannot be satisfied using the existing
buffer collection and its already-logically-allocated participants.
Creating a new collection instead may allow all participant's
constraints to be satisfied, assuming SetDispensable() is used in place
of AttachToken(), or a normal token is used.</p>
<p>A token created with AttachToken() performs constraints aggregation with
all constraints currently in effect on the buffer collection, plus the
attached token under consideration plus child tokens under the attached
token which are not themselves an attached token or under such a token.</p>
<p>Allocation of buffer_count to min_buffer_count_for_camping etc is
first-come first-served, but a child can't logically allocate before
all its parents have sent SetConstraints().</p>
<p>See also SetDispensable(), which in contrast to AttachToken(), has the
created token + children participate in constraints aggregation along
with its parent.</p>
<p>The newly created token needs to be Sync()ed to sysmem before the new
token can be passed to BindSharedCollection(). The Sync() of the new
token can be accomplished with BufferCollection.Sync() on this
BufferCollection. Alternately BufferCollectionToken.Sync() on the new
token also works. A BufferCollectionToken.Sync() can be started after
any BufferCollectionToken.Duplicate() messages have been sent via the
newly created token, to also sync those additional tokens to sysmem
using a single round-trip.</p>
<p>These values for rights_attenuation_mask result in no attenuation (note
that 0 is not on this list; 0 will output an ERROR to the system log
to help diagnose the bug in client code):</p>
<ul>
<li>ZX_RIGHT_SAME_RIGHTS (preferred)</li>
<li>0xFFFFFFFF (this is reasonable when an attenuation mask is computed)</li>
</ul>
#### Request {#BufferCollection.AttachToken_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>rights_attenuation_mask</code></td>
<td>
<code>uint32</code>
</td>
</tr>
<tr>
<td><code>token_request</code></td>
<td>
<code>request&lt;<a class='link' href='#BufferCollectionToken'>BufferCollectionToken</a>&gt;</code>
</td>
</tr>
</table>
### CheckBuffersAllocated {#BufferCollection.CheckBuffersAllocated}
<p>This returns the same result code as WaitForBuffersAllocated if the
buffer collection has been allocated or failed, or <code>ZX_ERR_UNAVAILABLE</code>
if WaitForBuffersAllocated would block.</p>
#### Request {#BufferCollection.CheckBuffersAllocated_Request}
&lt;EMPTY&gt;
#### Response {#BufferCollection.CheckBuffersAllocated_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>status</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
</tr>
</table>
### CheckSingleBufferAllocated {#BufferCollection.CheckSingleBufferAllocated}
<p>A participant can use this message to have sysmem verify that this
buffer_index exists. This message is intentionally ignored by the
server if the buffer_index <em>does</em> exist. In that case, the client will
see OnAllocateSingleBufferDone() soon with status == <code>ZX_OK</code> (if the
client hasn't already seen that message). If on the other hand the
buffer_index does not exist, this message causes the server to send
OnAllocateSingleBufferDone() with status == <code>ZX_ERR_NOT_FOUND</code>. A
particpant will typically use this when the participant receives a new
buffer_index that the participant doesn't yet know about, to ensure that
the participant won't be waiting forever for the
OnAllocateSingleBufferDone() message regarding this buffer_index.</p>
#### Request {#BufferCollection.CheckSingleBufferAllocated_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>buffer_index</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
### Close {#BufferCollection.Close}
<p>The server handles unexpected failure of a BufferCollection by failing
the whole logical buffer collection. Partly this is to expedite closing
VMO handles. If a participant would like to cleanly close a
BufferCollection view without causing logical buffer collection failure,
the participant can send Close() before closing the client end of the
BufferCollection channel. If this is the last BufferCollection view, the
logical buffer collection will still go away.</p>
#### Request {#BufferCollection.Close_Request}
&lt;EMPTY&gt;
### CloseSingleBuffer {#BufferCollection.CloseSingleBuffer}
<p>The CloseBuffer() doesn't immediately force all VMO handles to that
buffer to close, but it does close any handle held by sysmem, and does
notify all participants of the desire to close the buffer at which point
each participant that's listening may close their handle to the buffer.</p>
<p>Only a particpant with write can do this. Coordination among multiple
participants with write is outside of the scope of this interface.</p>
<p><code>buffer_index</code> indicates which buffer to close. If the buffer is already
closed this has no effect (idempotent).</p>
#### Request {#BufferCollection.CloseSingleBuffer_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>buffer_index</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
### GetAuxBuffers {#BufferCollection.GetAuxBuffers}
<p>Allows getting any aux buffers allocated after using
SetConstraintsAuxBuffers().</p>
<p>Sending this message is not permitted until WaitForBuffersAllocated() completes.</p>
<p>On failure, status will be a failing status and
buffer_collection_info_aux_buffers won't be filled out, and won't have
any handles.</p>
<p>On success, status will be ZX_OK, and buffer_count will be the same as
the main buffer_count from WaitForBuffersAllocated().</p>
<p>If a participant specified &quot;allow_clear_aux_buffers_for_secure&quot; true but
&quot;need_clear_aux_buffers_for_secure&quot; false (or not set), the participant
can determine if aux buffers were allocated by looking at buffer[0].vmo.
If buffer 0 has no vmo, aux VMOs were not allocated. The resulting
status will still be ZX_OK in this case, and buffer_count will still be
filled out to match the main buffer_count.</p>
<p>It's legal for a participant that set
&quot;allow_clear_aux_buffers_for_secure&quot; false to call GetAuxBuffers(), in
which case buffer[0].vmo will not be set.</p>
#### Request {#BufferCollection.GetAuxBuffers_Request}
&lt;EMPTY&gt;
#### Response {#BufferCollection.GetAuxBuffers_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>status</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
</tr>
<tr>
<td><code>buffer_collection_info_aux_buffers</code></td>
<td>
<code><a class='link' href='#BufferCollectionInfo_2'>BufferCollectionInfo_2</a></code>
</td>
</tr>
</table>
### SetConstraints {#BufferCollection.SetConstraints}
<p>Provide BufferCollectionConstraints to the logical BufferCollection.</p>
<p>A participant may only call SetConstraints() once.</p>
<p>Sometimes the initiator is a participant only in the sense of wanting to
keep an eye on success/failure to populate with buffers, and zx.status on
failure. In that case, <code>has_constraints</code> can be false, and <code>constraints</code>
will be ignored.</p>
<p>VMO handles will not be provided to the client that sends null
constraints - that can be intentional for an initiator that doesn't need
VMO handles. Not having VMO handles doesn't prevent the initator from
adjusting which portion of a buffer is considered valid and similar, but
the initiator can't hold a VMO handle open to prevent the logical
BufferCollection from cleaning up if the logical BufferCollection needs
to go away regardless of the initiator's degree of involvement for
whatever reason.</p>
<p>For population of buffers to be attempted, all holders of a
BufferCollection client channel need to call SetConstraints() before
sysmem will attempt to allocate buffers.</p>
<p><code>has_constraints</code> if false, the constraints are effectively null, and
<code>constraints</code> are ignored. The sender of null constraints won't get any
VMO handles in BufferCollectionInfo, but can still find out how many
buffers were allocated and can still refer to buffers by their
buffer_index.</p>
<p><code>constraints</code> are constraints on the buffer collection.</p>
#### Request {#BufferCollection.SetConstraints_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>has_constraints</code></td>
<td>
<code>bool</code>
</td>
</tr>
<tr>
<td><code>constraints</code></td>
<td>
<code><a class='link' href='#BufferCollectionConstraints'>BufferCollectionConstraints</a></code>
</td>
</tr>
</table>
### SetConstraintsAuxBuffers {#BufferCollection.SetConstraintsAuxBuffers}
<p>Optionally sent before SetConstraints() to set constraints related to
clear (not encrypted, not in protected/secure memory) aux buffers. This
is only valid when sent before SetConstraints(). Invalid settings may
not result in channel closure until SetConstraints() is received by
sysmem.</p>
#### Request {#BufferCollection.SetConstraintsAuxBuffers_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>constraints</code></td>
<td>
<code><a class='link' href='#BufferCollectionConstraintsAuxBuffers'>BufferCollectionConstraintsAuxBuffers</a></code>
</td>
</tr>
</table>
### SetDebugClientInfo {#BufferCollection.SetDebugClientInfo}
<p>See BufferCollectionToken.SetClientDebugInfo.</p>
#### Request {#BufferCollection.SetDebugClientInfo_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>name</code></td>
<td>
<code>string[64]</code>
</td>
</tr>
<tr>
<td><code>id</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
### SetName {#BufferCollection.SetName}
<p>Set a name for VMOs in this buffer collection. The name may be truncated shorter. The name
only affects VMOs allocated after it's set - this call does not rename existing VMOs. If
multiple clients set different names then the larger priority value will win.</p>
#### Request {#BufferCollection.SetName_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>priority</code></td>
<td>
<code>uint32</code>
</td>
</tr>
<tr>
<td><code>name</code></td>
<td>
<code>string[64]</code>
</td>
</tr>
</table>
### Sync {#BufferCollection.Sync}
<p>See comments on BufferCollectionToken::Sync().</p>
#### Request {#BufferCollection.Sync_Request}
&lt;EMPTY&gt;
#### Response {#BufferCollection.Sync_Response}
&lt;EMPTY&gt;
### WaitForBuffersAllocated {#BufferCollection.WaitForBuffersAllocated}
<p>This request completes when buffers have been allocated, responds with
some failure detail if allocation has been attempted but failed.</p>
<p>The following must occur before buffers will be allocated:</p>
<ul>
<li>All BufferCollectionToken(s) of the logical BufferCollectionToken
must be turned in via BindSharedCollection().</li>
<li>All BufferCollection(s) of the logical BufferCollection must have had
SetConstraints() sent to them.</li>
</ul>
<p>Returns <code>ZX_OK</code> if successful.
Returns <code>ZX_ERR_NO_MEMORY</code> if the request is valid but cannot be
fulfilled due to resource exhaustion.
Returns <code>ZX_ERR_ACCESS_DENIED</code> if the caller is not permitted to
obtain the buffers it requested.
Returns <code>ZX_ERR_INVALID_ARGS</code> if the request is malformed.
Returns <code>ZX_ERR_NOT_SUPPORTED</code> if request is valid but cannot be
satisfied, perhaps due to hardware limitations.</p>
<p><code>buffer_collection_info</code> has the VMO handles and other related info.</p>
#### Request {#BufferCollection.WaitForBuffersAllocated_Request}
&lt;EMPTY&gt;
#### Response {#BufferCollection.WaitForBuffersAllocated_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>status</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
</tr>
<tr>
<td><code>buffer_collection_info</code></td>
<td>
<code><a class='link' href='#BufferCollectionInfo_2'>BufferCollectionInfo_2</a></code>
</td>
</tr>
</table>
### WaitForSingleBufferAllocated {#BufferCollection.WaitForSingleBufferAllocated}
<p>Completes when AllocateBuffer is done. Callers who wish to avoid
blocking a thread while waiting can use OnAllocateSingleBufferDone()
instead.</p>
#### Request {#BufferCollection.WaitForSingleBufferAllocated_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>buffer_index</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
#### Response {#BufferCollection.WaitForSingleBufferAllocated_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>status</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
</tr>
<tr>
<td><code>buffer_info</code></td>
<td>
<code><a class='link' href='#SingleBufferInfo'>SingleBufferInfo</a></code>
</td>
</tr>
</table>
## BufferCollectionToken {#BufferCollectionToken}
*Defined in [fuchsia.sysmem/collection.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/collection.fidl;l=17)*
<p>A BufferCollectionToken is not a BufferCollection, but rather a way to
identify a potential shared BufferCollection prior to the BufferCollection
being allocated.</p>
<p>We use a channel for the BufferCollectionToken instead of a single eventpair
(pair) because this way we can detect error conditions like a participant
dying mid-create.</p>
### Close {#BufferCollectionToken.Close}
<p>Normally a participant will convert the token into a BufferCollection
view, but a particpant is also free to Close() the token (and then close
the channel immediately or shortly later in response to server closing
its end), which avoids causing logical buffer collection failure.
Normally an unexpected token channel close will cause
logical buffer collection failure.</p>
#### Request {#BufferCollectionToken.Close_Request}
&lt;EMPTY&gt;
### Duplicate {#BufferCollectionToken.Duplicate}
<p>This method can be used to add a participant prior to creating a shared
BufferCollection. It should only be used instead of DuplicateSync in
performance sensitive cases where it would be undesireable to wait for
sysmem to respond as part of each duplicate.</p>
<p>After sending one or more Duplicate() messages, and before sending the
created tokens to other participants (or to other Allocator channels),
the client should send a Sync() and wait for its response. The Sync()
call can be made on the token, or on the BufferCollection obtained by
passing this token to BindSharedCollection(). Either will ensure that
the server knows about the tokens created via Duplicate() before the
other participant sends the token to the server via separate Allocator
channel.</p>
<p>All tokens must be turned in via BindSharedCollection() or Close() for a
BufferCollection to be successfully created.</p>
<p>When a client calls BindSharedCollection() to turn in a
BufferCollectionToken, the server will process all Duplicate() messages
before closing down the BufferCollectionToken. This allows the client
to Duplicate() and immediately turn in the BufferCollectionToken using
BindSharedCollection, then later transfer the client end of token_request
to another participant - the server will notice the existence of the
token_request before considering this BufferCollectionToken fully closed.</p>
<p><code>rights_attenuation_mask</code> rights bits that are zero in this mask will be
absent in the buffer VMO rights obtainable via the client end of
token_request. This allows an initiator or intermediary participant to
attenuate the rights available to a participant. This does not allow a
participant to gain rights that the participant doesn't already have.
The value ZX_RIGHT_SAME_RIGHTS can be used to specify that no
attenuation should be applied.</p>
<p>These values for rights_attenuation_mask result in no attenuation:</p>
<ul>
<li>ZX_RIGHT_SAME_RIGHTS (preferred)</li>
<li>0xFFFFFFFF (this is reasonable when an attenuation mask is computed)</li>
<li>0 (deprecated - do not use 0 - an ERROR will go to the log)</li>
</ul>
<p><code>token_request</code> is the server end of a BufferCollectionToken channel.
The client end of this channel acts as another participant in creating the
shared BufferCollection.</p>
#### Request {#BufferCollectionToken.Duplicate_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>rights_attenuation_mask</code></td>
<td>
<code>uint32</code>
</td>
</tr>
<tr>
<td><code>token_request</code></td>
<td>
<code>request&lt;<a class='link' href='#BufferCollectionToken'>BufferCollectionToken</a>&gt;</code>
</td>
</tr>
</table>
### DuplicateSync {#BufferCollectionToken.DuplicateSync}
<p>This method can be used to add more participants prior to creating a
shared BufferCollection. A new token will be returned for each entry in
the <code>rights_attenuation_masks</code> array. The return value is the client
ends of each new participant token.</p>
<p>In contrast to Duplicate(), no Sync() is needed after calling this
method.</p>
<p>All tokens must be turned in via BindSharedCollection() or Close() for a
BufferCollection to be successfully created.</p>
<p>In each entry of <code>rights_attenuation_masks</code>, rights bits that are zero
will be absent in the buffer VMO rights obtainable via the corresponding
returned token. This allows an initiator or intermediary participant to
attenuate the rights available to a participant. This does not allow a
participant to gain rights that the participant doesn't already have.
The value ZX_RIGHT_SAME_RIGHTS can be used to specify that no
attenuation should be applied.</p>
#### Request {#BufferCollectionToken.DuplicateSync_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>rights_attenuation_masks</code></td>
<td>
<code>vector&lt;<a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#rights'>rights</a>&gt;[64]</code>
</td>
</tr>
</table>
#### Response {#BufferCollectionToken.DuplicateSync_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>tokens</code></td>
<td>
<code>vector&lt;<a class='link' href='#BufferCollectionToken'>BufferCollectionToken</a>&gt;[64]</code>
</td>
</tr>
</table>
### SetDebugClientInfo {#BufferCollectionToken.SetDebugClientInfo}
<p>Set information about the current client that can be used by sysmem to
help debug leaking memory and hangs waiting for constraints. |name| can
be an arbitrary string, but the current process name (see
fsl::GetCurrentProcessName()) is a good default. |id| can be an arbitrary
id, but the current process ID (see fsl::GetCurrentProcessKoid()) is a
good default.</p>
#### Request {#BufferCollectionToken.SetDebugClientInfo_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>name</code></td>
<td>
<code>string[64]</code>
</td>
</tr>
<tr>
<td><code>id</code></td>
<td>
<code>uint64</code>
</td>
</tr>
</table>
### SetDebugTimeoutLogDeadline {#BufferCollectionToken.SetDebugTimeoutLogDeadline}
<p>Sysmem logs a warning if not all clients have set constraints 5 seconds
after creating a collection. Clients can call this method to change
when the log is printed. If multiple client set the deadline, it's
unspecified which deadline will take effect.</p>
#### Request {#BufferCollectionToken.SetDebugTimeoutLogDeadline_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>deadline</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#time'>time</a></code>
</td>
</tr>
</table>
### SetDispensable {#BufferCollectionToken.SetDispensable}
<p>A dispensable token can fail after buffers are logically allocated
without causing failure of its parent (if any).</p>
<p>The dispensable token participates in constraints aggregation along with
its parent before logical buffer allocation. If the dispensable token
fails before buffers are logically allocated, the failure propagates to
the dispensable token's parent.</p>
<p>After buffers are logically allocated, failure of the dispensable token
(or any child of the dispensable token) does not propagate to the
dispensable token's parent. Failure does propagate from a normal
child of a dispensable token to the dispensable token. Failure
of a child is blocked from reaching its parent if the child is attached,
or if the child is dispensable and the failure occurred after logical
allocation.</p>
<p>A dispensable token can be used in cases where a participant needs to
provide constraints, but after buffers are allocated, the participant
can fail without causing buffer collection failure from the parent's
point of view.</p>
<p>In contrast, AttachToken() can be used to create a token which does not
participate in constraints aggregation with its parent, and whose
failure at any time does not propagate to its parent, and whose delay
providing constraints does not prevent the parent from completing its
buffer allocation.</p>
<p>An initiator may in some scenarios choose to initially use a dispensable
token for a given instance of a participant, and then later if the first
instance of that participant fails, a new second instance of that
participant my be given a token created with AttachToken().</p>
<p>If a client uses this message, the client should not rely on the
client's own BufferCollectionToken or BufferCollection channel to close
from the server end due to abrupt failure of any BufferCollectionToken
or BufferCollection that the client has SetDispensable() and given out
to another process. For this reason, the client should take extra care
to notice failure of that other process via other means.</p>
<p>SetDispensable() on an already-dispensable token is idempotent.</p>
#### Request {#BufferCollectionToken.SetDispensable_Request}
&lt;EMPTY&gt;
### SetName {#BufferCollectionToken.SetName}
<p>Set a name for VMOs in this buffer collection. The name may be truncated shorter. The name
only affects VMOs allocated after it's set - this call does not rename existing VMOs. If
multiple clients set different names then the larger priority value will win.</p>
#### Request {#BufferCollectionToken.SetName_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>priority</code></td>
<td>
<code>uint32</code>
</td>
</tr>
<tr>
<td><code>name</code></td>
<td>
<code>string[64]</code>
</td>
</tr>
</table>
### Sync {#BufferCollectionToken.Sync}
<p>Ensure that previous Duplicate() messages have been received server side,
so that it's safe to send the client end of token_request to another
participant knowing the server will recognize the token when it's sent
into BindSharedCollection by the other participant.</p>
<p>Other options include waiting for each Duplicate() to complete
individually (using separate call to BufferCollectionToken.Sync() after
each), or calling Sync() on BufferCollection after this token has
been turned in via BindSharedCollection().</p>
<p>Calling BufferCollectionToken.Sync() on a token that isn't/wasn't a
valid sysmem token risks the Sync() hanging forever. See
ValidateBufferCollectionToken() for one way to mitigate the possibility
of a hostile/fake BufferCollectionToken at the cost of one round trip.</p>
<p>Another way to mitigate is to avoid calling Sync() on the token, and
instead later deal with potential failure of BufferCollection.Sync() if
the original token was invalid. This option can be preferable from a
performance point of view, but requires client code to delay sending
tokens duplicated from this token until after client code has converted
this token to a BufferCollection and received successful response from
BufferCollection.Sync() (or received OnDuplicatedTokensKnownByServer()).</p>
<p>Prefer using BufferCollection.Sync() instead, when feasible (see above).
When BufferCollection.Sync() isn't feasible, the caller must already
know that this token is/was valid, or BufferCollectionToken.Sync() may
hang forever. See ValidateBufferCollectionToken() to check token
validity first if the token isn't already known to be (is/was) valid.</p>
#### Request {#BufferCollectionToken.Sync_Request}
&lt;EMPTY&gt;
#### Response {#BufferCollectionToken.Sync_Response}
&lt;EMPTY&gt;
## DriverConnector {#DriverConnector}
*Defined in [fuchsia.sysmem/driver_connector.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/driver_connector.fidl;l=28)*
<p>Once a channel with this interface is established to a driver (typically in
advance), this interface allows asynchronously sending the server end of an
Allocator channel which will be served by the driver.</p>
<p>For now, the only FIDL interface directly served via normal devhost FIDL
dispatching code by the sysmem driver is this interface. Other sysmem
interfaces are served by separate dispatching code primarily because we want
to be able to establish channels async by sending the server channel toward
the driver without needing a round-trip open and without managing the channel
as a file descriptor.</p>
<p>A secondary current reason tracked by fxbug.dev/32924 is that the current devhost
dispatching code doesn't permit async processing of requests, which we want
for proper functioning of at least the BufferCollection interface since
that interface has requests that don't complete until the devhost has
constraints from other participants.</p>
### Connect {#DriverConnector.Connect}
<p>This one-way message sends in the server end of an Allocator channel.</p>
<p><code>allocator_request</code> will be served by the sysmem driver (or the channel
will close).</p>
#### Request {#DriverConnector.Connect_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>allocator_request</code></td>
<td>
<code>request&lt;<a class='link' href='#Allocator'>Allocator</a>&gt;</code>
</td>
</tr>
</table>
### SetAuxServiceDirectory {#DriverConnector.SetAuxServiceDirectory}
#### Request {#DriverConnector.SetAuxServiceDirectory_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>service_directory</code></td>
<td>
<code><a class='link' href='../fuchsia.io/'>fuchsia.io</a>/<a class='link' href='../fuchsia.io/#Directory'>Directory</a></code>
</td>
</tr>
</table>
## SecureMem {#SecureMem}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=26)*
<p>SecureMem</p>
<p>The client is sysmem. The server is securemem driver.</p>
<p>TEE - Trusted Execution Environment.</p>
<p>REE - Rich Execution Environment.</p>
<p>Enables sysmem to call the securemem driver to get any secure heaps
configured via the TEE (or via the securemem driver), and set any physical
secure heaps configured via sysmem.</p>
<p>Presently, dynamically-allocated secure heaps are configured via sysmem, as
it starts quite early during boot and can successfully reserve contiguous
physical memory. Presently, fixed-location secure heaps are configured via
TEE, as the plumbing goes from the bootloader to the TEE. However, this
protocol intentionally doesn't care which heaps are dynamically-allocated
and which are fixed-location.</p>
### AddSecureHeapPhysicalRange {#SecureMem.AddSecureHeapPhysicalRange}
<p>This request from sysmem to the securemem driver conveys a physical
range to add, for a heap whose physical range(s) are set up via
sysmem.</p>
<p>Only sysmem can call this because only sysmem is handed the client end
of a FIDL channel serving this protocol, via RegisterSecureMem(). The
securemem driver is the server end of this protocol.</p>
<p>The securemem driver must configure all the covered offsets as protected
before responding to this message with success.</p>
<p>On failure, the securemem driver must ensure the protected range was not
created.</p>
<p>Sysmem must only call this up to once if dynamic_protection_ranges
false.</p>
<p>If dynamic_protection_ranges is true, sysmem can call this multiple
times as long as the current number of ranges never exceeds
max_protected_range_count.</p>
<p>The caller must not attempt to add a range that matches an
already-existing range. Added ranges can overlap each other as long as
no two ranges match exactly.</p>
<p>Errors:</p>
<ul>
<li>ZX_ERR_BAD_STATE - called more than once when
!dynamic_protection_ranges. Adding a heap that would cause overall
heap count to exceed max_protected_range_count.</li>
<li>ZX_ERR_INVALID_ARGS - unexpected heap, or range that doesn't conform
to protected_range_granularity.</li>
<li>ZX_ERR_INTERNAL - generic internal error (such as in communication
with TEE which doesn't generate zx_status_t errors).</li>
<li>other errors are possible, such as from communication failures or
server propagation of zx_status_t failures.</li>
</ul>
#### Request {#SecureMem.AddSecureHeapPhysicalRange_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>heap_range</code></td>
<td>
<code><a class='link' href='#SecureHeapAndRange'>SecureHeapAndRange</a></code>
</td>
</tr>
</table>
#### Response {#SecureMem.AddSecureHeapPhysicalRange_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>result</code></td>
<td>
<code><a class='link' href='#SecureMem_AddSecureHeapPhysicalRange_Result'>SecureMem_AddSecureHeapPhysicalRange_Result</a></code>
</td>
</tr>
</table>
### DeleteSecureHeapPhysicalRange {#SecureMem.DeleteSecureHeapPhysicalRange}
<p>This request from sysmem to the securemem driver conveys a physical
range to delete, for a heap whose physical range(s) are set up via
sysmem.</p>
<p>Only sysmem can call this because only sysmem is handed the client end
of a FIDL channel serving this protocol, via RegisterSecureMem(). The
securemem driver is the server end of this protocol.</p>
<p>The securemem driver must configure all the covered offsets as not
protected before responding to this message with success.</p>
<p>On failure, the securemem driver must ensure the protected range was not
deleted.</p>
<p>Sysmem must not call this if dynamic_protection_ranges false.</p>
<p>If dynamic_protection_ranges is true, sysmem can call this repeatedly,
on various ranges that exist at the time of the call.</p>
<p>If any portion of the range being deleted is not also covered by another
protected range, then any ongoing DMA to any part of the entire range
may be interrupted / may fail, potentially in a way that's disruptive to
the entire system (bus lockup or similar, depending on device details).
Therefore, the caller must ensure that no ongoing DMA is occurring to
any portion of the range being deleted, unless the caller has other
active ranges covering every block of the range being deleted. Ongoing
DMA to/from blocks outside the range being deleted is never impacted by
the deletion.</p>
<p>Errors:</p>
<ul>
<li>ZX_ERR_BAD_STATE - called when !dynamic_protection_ranges.</li>
<li>ZX_ERR_INVALID_ARGS - unexpected heap, or range that doesn't conform
to protected_range_granularity.</li>
<li>ZX_ERR_INTERNAL - generic internal error (such as in communication
with TEE which doesn't generate zx_status_t errors).</li>
<li>ZX_ERR_NOT_FOUND - the specified range is not found.</li>
<li>other errors are possible, such as from communication failures or
server propagation of zx_status_t failures.</li>
</ul>
#### Request {#SecureMem.DeleteSecureHeapPhysicalRange_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>heap_range</code></td>
<td>
<code><a class='link' href='#SecureHeapAndRange'>SecureHeapAndRange</a></code>
</td>
</tr>
</table>
#### Response {#SecureMem.DeleteSecureHeapPhysicalRange_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>result</code></td>
<td>
<code><a class='link' href='#SecureMem_DeleteSecureHeapPhysicalRange_Result'>SecureMem_DeleteSecureHeapPhysicalRange_Result</a></code>
</td>
</tr>
</table>
### GetPhysicalSecureHeapProperties {#SecureMem.GetPhysicalSecureHeapProperties}
<p>This request from sysmem to the securemem driver gets the properties of
a protected/secure heap.</p>
#### Request {#SecureMem.GetPhysicalSecureHeapProperties_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>heap</code></td>
<td>
<code><a class='link' href='#HeapType'>HeapType</a></code>
</td>
</tr>
</table>
#### Response {#SecureMem.GetPhysicalSecureHeapProperties_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>result</code></td>
<td>
<code><a class='link' href='#SecureMem_GetPhysicalSecureHeapProperties_Result'>SecureMem_GetPhysicalSecureHeapProperties_Result</a></code>
</td>
</tr>
</table>
### GetPhysicalSecureHeaps {#SecureMem.GetPhysicalSecureHeaps}
<p>Gets the physical address and length of any secure heap whose physical
range is configured via the TEE.</p>
<p>Presently, these will be fixed physical addresses and lengths, with the
location plumbed via the TEE.</p>
<p>This is preferred over RegisterHeap() when there isn't any special
heap-specific per-VMO setup or teardown required.</p>
<p>The physical range must be secured/protected by the TEE before the
securemem driver responds to this request with success.</p>
<p>Sysmem should only call this once. Returning zero heaps is not a
failure.</p>
<p>Errors:</p>
<ul>
<li>ZX_ERR_BAD_STATE - called more than once.</li>
<li>ZX_ERR_INTERNAL - generic internal error (such as in communication
with TEE which doesn't generate zx_status_t errors).</li>
<li>other errors are possible, such as from communication failures or
server propagation of zx_status_t failures</li>
</ul>
#### Request {#SecureMem.GetPhysicalSecureHeaps_Request}
&lt;EMPTY&gt;
#### Response {#SecureMem.GetPhysicalSecureHeaps_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>result</code></td>
<td>
<code><a class='link' href='#SecureMem_GetPhysicalSecureHeaps_Result'>SecureMem_GetPhysicalSecureHeaps_Result</a></code>
</td>
</tr>
</table>
### ModifySecureHeapPhysicalRange {#SecureMem.ModifySecureHeapPhysicalRange}
<p>This request from sysmem to the securemem driver conveys a physical
range to modify and its new base and length, for a heap whose physical
range(s) are set up via sysmem.</p>
<p>Only sysmem can call this because only sysmem is handed the client end
of a FIDL channel serving this protocol, via RegisterSecureMem(). The
securemem driver is the server end of this protocol.</p>
<p>The securemem driver must configure the range to cover only the new
offsets before responding to this message with success.</p>
<p>On failure, the securemem driver must ensure the range was not changed.</p>
<p>Sysmem must not call this if dynamic_protection_ranges false. Sysmem
must not call this if !is_mod_protected_range_available.</p>
<p>If dynamic_protection_ranges is true, sysmem can call this repeatedly,
on various ranges that exist at the time of the call.</p>
<p>The range must only be modified at one end or the other, but not both.
If the range is getting shorter, and the un-covered blocks are not
covered by other active ranges, any ongoing DMA to the entire range
that's geting shorter may fail in a way that disrupts the entire system
(bus lockup or similar), so the caller must ensure that no DMA is
ongoing to any portion of a range that is getting shorter, unless the
blocks being un-covered by the modification to this range are all
covered by other active ranges, in which case no disruption to ongoing
DMA will occur.</p>
<p>If a range is modified to become &lt;= zero length, the range is deleted.</p>
<p>Errors:</p>
<ul>
<li>ZX_ERR_BAD_STATE - called when !dynamic_protection_ranges.</li>
<li>ZX_ERR_INVALID_ARGS - unexpected heap, or old_range or new_range
that doesn't conform to protected_range_granularity, or old_range
and new_range differ in both begin and end (disallowed).</li>
<li>ZX_ERR_INTERNAL - generic internal error (such as in communication
with TEE which doesn't generate zx_status_t errors).</li>
<li>ZX_ERR_NOT_FOUND - the specified range is not found.</li>
<li>other errors are possible, such as from communication failures or
server propagation of zx_status_t failures.</li>
</ul>
#### Request {#SecureMem.ModifySecureHeapPhysicalRange_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>range_modification</code></td>
<td>
<code><a class='link' href='#SecureHeapAndRangeModification'>SecureHeapAndRangeModification</a></code>
</td>
</tr>
</table>
#### Response {#SecureMem.ModifySecureHeapPhysicalRange_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>result</code></td>
<td>
<code><a class='link' href='#SecureMem_ModifySecureHeapPhysicalRange_Result'>SecureMem_ModifySecureHeapPhysicalRange_Result</a></code>
</td>
</tr>
</table>
### ZeroSubRange {#SecureMem.ZeroSubRange}
<p>Zero a sub-range of a currently-existing physical range added via
AddSecureHeapPhysicalRange(). The sub-range must be fully covered by
exactly one physical range, and must not overlap with any other
physical range.</p>
<p>is_covering_range_explicit - When true, the covering range must be one
of the ranges explicitly created via AddSecureHeapPhysicalRange(),
possibly modified since. When false, the covering range must not
be one of the ranges explicitly created via
AddSecureHeapPhysicalRange(), but the covering range must exist as
a covering range not created via AddSecureHeapPhysicalRange(). The
covering range is typically the entire physical range (or a range
which covers even more) of a heap configured by the TEE and whose
configuration is conveyed to sysmem via GetPhysicalSecureHeaps().</p>
<p>Ongoing DMA is not disrupted by this request.</p>
#### Request {#SecureMem.ZeroSubRange_Request}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>is_covering_range_explicit</code></td>
<td>
<code>bool</code>
</td>
</tr>
<tr>
<td><code>heap_range</code></td>
<td>
<code><a class='link' href='#SecureHeapAndRange'>SecureHeapAndRange</a></code>
</td>
</tr>
</table>
#### Response {#SecureMem.ZeroSubRange_Response}
<table>
<tr><th>Name</th><th>Type</th></tr>
<tr>
<td><code>result</code></td>
<td>
<code><a class='link' href='#SecureMem_ZeroSubRange_Result'>SecureMem_ZeroSubRange_Result</a></code>
</td>
</tr>
</table>
## **STRUCTS**
### BufferCollectionConstraints {#BufferCollectionConstraints data-text="BufferCollectionConstraints"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=23)*
<p>Constraints on BufferCollection parameters. These constraints can be
specified per-participant. The sysmem service implements aggregation of
constraints from multiple participants.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferCollectionConstraints.usage">
<td><code>usage</code></td>
<td>
<code><a class='link' href='#BufferUsage'>BufferUsage</a></code>
</td>
<td><p>The usage is only meant as a hint to help sysmem choose a more optimal
PixelFormat or similar when multiple compatible options exist.</p>
<p>When aggregating BufferCollectionConstraints, these values bitwise-OR.</p>
<p>At least one usage bit must be specified unless the whole
BufferCollectionConstraints is logically null due to !has_constraints.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.min_buffer_count_for_camping">
<td><code>min_buffer_count_for_camping</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Per-participant number of buffers that the participant may concurrently
hold for its exclusive use for a non-transient period of time (camp on).</p>
<p>For example, a video decoder would specify (at least) the maximum number
of reference frames + 1 frame currently being decoded into.</p>
<p>A participant must not camp on more buffers than specified here (except
very transiently) else processing may get stuck.</p>
<p>When aggregating BufferCollectionConstraints, these values add.</p>
<p>In testing scenarios, camping on more buffers than this for any
significant duration may (ideally will) be flagged as a failure. In
testing scenarios, the participant may not be provided with more buffers
than this concurrently.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.min_buffer_count_for_dedicated_slack">
<td><code>min_buffer_count_for_dedicated_slack</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Per-participant minimum number of buffers that are needed for slack
reasons, for better overlap of processing / better performance.</p>
<p>When aggregating BufferCollectionConstraints, these values add.</p>
<p>A participant should typically specify 0 or 1 here - typically 0 is
appropriate if min_buffer_count_for_camping is already enough to keep
the participant busy 100% of the time when the participant is slightly
behind, while 1 can be appropriate if 1 more buffer than strictly needed
for min-camping reasons gives enough slack to stay busy 100% of the time
(when slightly behind, vs. lower % without the extra buffer).</p>
<p>In testing scenarios, this field may be forced to 0, and all
participants are expected to continue to work without getting stuck. If
a buffer is needed for forward progress reasons, that buffer should be
accounted for in min_buffer_count_for_camping.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.min_buffer_count_for_shared_slack">
<td><code>min_buffer_count_for_shared_slack</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Similar to min_buffer_count_for_dedicated_slack, except when aggregating
these values max (instead of add). The value here is not shared with
any participant's min_buffer_count_for_dedicated_slack.</p>
<p>A participant can specify &gt; 0 here if a participant would like to ensure
there's some slack overall, but doesn't need that slack to be dedicated.</p>
<p>The choice whether to use min_buffer_count_for_dedicated_slack or
min_buffer_count_for_shared_slack (or both) will typically be about the
degree to which the extra slack improves performance.</p>
<p>In testing scenarios, this field may be forced to 0, and all
participants are expected to continue to work without getting stuck. If
a buffer is needed for forward progress reasons, that buffer should be
accounted for in min_buffer_count_for_camping.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.min_buffer_count">
<td><code>min_buffer_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>A particularly-picky participant may unfortunately need to demand a
tight range of buffer_count, or even a specific buffer_count. This
field should remain 0 unless a participant really must set this field to
constrain the overall BufferCollectionInfo_2.buffer_count. Any such
participant should still fill out the min_buffer_count_for_* fields
above.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.max_buffer_count">
<td><code>max_buffer_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.has_buffer_memory_constraints">
<td><code>has_buffer_memory_constraints</code></td>
<td>
<code>bool</code>
</td>
<td><p>Constraints on BufferCollectionSettings.buffer_settings.</p>
<p>A participant that intends to specify image_format_constraints_count &gt; 1
will typically specify the minimum buffer size implicitly via
image_format_constraints, and possibly specify only the max buffer size
via buffer_memory_constraints.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.buffer_memory_constraints">
<td><code>buffer_memory_constraints</code></td>
<td>
<code><a class='link' href='#BufferMemoryConstraints'>BufferMemoryConstraints</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.image_format_constraints_count">
<td><code>image_format_constraints_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Optional constraints on the image format parameters of an image stored
in a buffer of the BufferCollection. This includes pixel format and
image layout. These constraints are per-pixel-format, so more than one
is permitted. Entries in the list must have unique pixel_formats.</p>
<p>When aggregating, only pixel formats that are specified by all
particpants with non-zero image_format_constraints_count (and non-Null)
BufferCollectionConstraints) are retained.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraints.image_format_constraints">
<td><code>image_format_constraints</code></td>
<td>
<code>[32]</code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### BufferCollectionConstraintsAuxBuffers {#BufferCollectionConstraintsAuxBuffers data-text="BufferCollectionConstraintsAuxBuffers"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=118)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferCollectionConstraintsAuxBuffers.need_clear_aux_buffers_for_secure">
<td><code>need_clear_aux_buffers_for_secure</code></td>
<td>
<code>bool</code>
</td>
<td><p>If true, a secure heap may only be selected if all participants with
BufferMemoryConstraints specify allow_clear_aux_buffers_for_secure. If
&quot;need&quot; is true, &quot;allow&quot; must also be true.</p>
<p>If false, the participant can still work, potentially even with secure
memory (depending on supported heaps), without clear aux buffers.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionConstraintsAuxBuffers.allow_clear_aux_buffers_for_secure">
<td><code>allow_clear_aux_buffers_for_secure</code></td>
<td>
<code>bool</code>
</td>
<td><p>If true, the participant will use clear aux buffers, if they are
allocated, as appropriate to the participant's role. If the participant
is a producer, then the participant producer will populate the clear aux
buffers with the clear (not-encrypted, not-DRM-protected) bytes, and
fill protected bytes with data that does not emulate start codes, such
as 0xFF.</p>
<p>If BufferCollectionConstraintsAuxBuffers is never sent by a
participant, then &quot;allow&quot; is true iff the participant specifies usage
which is read only.</p>
<p>If unspecified by a participant with write usage, or false, the
buffer collection won't be able to allocate if any participant specifies
need_clear_aux_buffers_for_secure true.</p>
</td>
<td>No default</td>
</tr>
</table>
### BufferCollectionInfo [resource](/fuchsia-src/reference/fidl/language/language.md#value-vs-resource){:.fidl-attribute} {#BufferCollectionInfo data-text="BufferCollectionInfo"}
*Defined in [fuchsia.sysmem/collections_deprecated.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/collections_deprecated.fidl;l=11)*
<p>Information about a buffer collection and its buffers.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferCollectionInfo.buffer_count">
<td><code>buffer_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>The number of buffers in the collection.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionInfo.format">
<td><code>format</code></td>
<td>
<code><a class='link' href='#BufferFormat'>BufferFormat</a></code>
</td>
<td><p>Describes how the contents of buffers are represented.
All buffers within the collection have the same format.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionInfo.vmos">
<td><code>vmos</code></td>
<td>
<code>vmo[64]</code>
</td>
<td><p>VMO handles for each buffer in the collection.
The VMOs are only present when the buffers are backed by VMOs.</p>
<p>If present, all the VMOs after <code>buffer_count</code> are invalid handles.
All buffer VMO handles have identical size and access rights.
The VMO access rights are determined based on the usages which the
client specified when allocating the buffer collection. For example,
a client which expressed a read-only usage will receive VMOs without
write rights.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionInfo.vmo_size">
<td><code>vmo_size</code></td>
<td>
<code>uint64</code>
</td>
<td><p>The size of each VMO provided.
This property is only present when the buffers are backed by VMOs.</p>
</td>
<td>0</td>
</tr>
</table>
### BufferCollectionInfo_2 [resource](/fuchsia-src/reference/fidl/language/language.md#value-vs-resource){:.fidl-attribute} {#BufferCollectionInfo_2 data-text="BufferCollectionInfo_2"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=162)*
<p>Information about a buffer collection and its buffers.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferCollectionInfo_2.buffer_count">
<td><code>buffer_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>The total number of buffers.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionInfo_2.settings">
<td><code>settings</code></td>
<td>
<code><a class='link' href='#SingleBufferSettings'>SingleBufferSettings</a></code>
</td>
<td><p>These settings apply to all the buffers in the initial buffer allocation.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferCollectionInfo_2.buffers">
<td><code>buffers</code></td>
<td>
<code>[64]</code>
</td>
<td><p>VMO handles (and vmo_usable_start offset) for each buffer in the
collection.</p>
<p>If present, all the VMOs at or after index <code>buffer_count</code> are invalid
(0) handles.</p>
<p>All buffer VMO handles have identical size and access rights. The size
is in settings.buffer_settings.size_bytes.</p>
<p>The VMO access rights are determined based on the usages which the
client specified when allocating the buffer collection. For example,
a client which expressed a read-only usage will receive VMOs without
write rights. In addition, the rights can be attenuated by the
parameter to BufferCollectionToken.Duplicate() calls.</p>
</td>
<td>No default</td>
</tr>
</table>
### BufferFormat {#BufferFormat data-text="BufferFormat"}
*Defined in [fuchsia.sysmem/formats_deprecated.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/formats_deprecated.fidl;l=9)*
<p>Describes how the contents of buffers are represented.
Buffers of each type are described by their own tables.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferFormat.tag">
<td><code>tag</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Since this struct used to be a single member union, we kept the tag
to avoid any wire format changes. The tag must be set to <code>0</code>,
no other value is correct.</p>
</td>
<td>0</td>
</tr>
<tr id="BufferFormat.image">
<td><code>image</code></td>
<td>
<code><a class='link' href='#ImageFormat'>ImageFormat</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### BufferMemoryConstraints {#BufferMemoryConstraints data-text="BufferMemoryConstraints"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=237)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferMemoryConstraints.min_size_bytes">
<td><code>min_size_bytes</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>0</td>
</tr>
<tr id="BufferMemoryConstraints.max_size_bytes">
<td><code>max_size_bytes</code></td>
<td>
<code>uint32</code>
</td>
<td><p>0 is treated as 0xFFFFFFFF.</p>
</td>
<td>4294967295</td>
</tr>
<tr id="BufferMemoryConstraints.physically_contiguous_required">
<td><code>physically_contiguous_required</code></td>
<td>
<code>bool</code>
</td>
<td></td>
<td>false</td>
</tr>
<tr id="BufferMemoryConstraints.secure_required">
<td><code>secure_required</code></td>
<td>
<code>bool</code>
</td>
<td><p>If true, at least one participant requires secure memory.</p>
<p>When aggregating BufferCollectionConstraints, these values boolean-OR.</p>
</td>
<td>false</td>
</tr>
<tr id="BufferMemoryConstraints.ram_domain_supported">
<td><code>ram_domain_supported</code></td>
<td>
<code>bool</code>
</td>
<td><p>By default, participants must ensure the CPU can read or write data to
the buffer without cache operations. If they support using the RAM
domain, data must be available in RAM (with CPU cache state such that
the RAM data won't get corrupted by a dirty CPU cache line writing
incorrect data to RAM), and a consumer reading using the CPU must
invalidate CPU cache before reading (the producer doesn't guarantee
zero stale &quot;clean&quot; cache lines)</p>
</td>
<td>false</td>
</tr>
<tr id="BufferMemoryConstraints.cpu_domain_supported">
<td><code>cpu_domain_supported</code></td>
<td>
<code>bool</code>
</td>
<td></td>
<td>true</td>
</tr>
<tr id="BufferMemoryConstraints.inaccessible_domain_supported">
<td><code>inaccessible_domain_supported</code></td>
<td>
<code>bool</code>
</td>
<td></td>
<td>false</td>
</tr>
<tr id="BufferMemoryConstraints.heap_permitted_count">
<td><code>heap_permitted_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Optional heap constraints. Participants that don't care which heap
memory is allocated on should leave this field 0.</p>
</td>
<td>No default</td>
</tr>
<tr id="BufferMemoryConstraints.heap_permitted">
<td><code>heap_permitted</code></td>
<td>
<code>[32]</code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### BufferMemorySettings {#BufferMemorySettings data-text="BufferMemorySettings"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=287)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferMemorySettings.size_bytes">
<td><code>size_bytes</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferMemorySettings.is_physically_contiguous">
<td><code>is_physically_contiguous</code></td>
<td>
<code>bool</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferMemorySettings.is_secure">
<td><code>is_secure</code></td>
<td>
<code>bool</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferMemorySettings.coherency_domain">
<td><code>coherency_domain</code></td>
<td>
<code><a class='link' href='#CoherencyDomain'>CoherencyDomain</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferMemorySettings.heap">
<td><code>heap</code></td>
<td>
<code><a class='link' href='#HeapType'>HeapType</a></code>
</td>
<td><p>The specific heap from which buffers are allocated.
See above in this file for heap identifier values.</p>
</td>
<td>No default</td>
</tr>
</table>
### BufferUsage {#BufferUsage data-text="BufferUsage"}
*Defined in [fuchsia.sysmem/usages.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=9)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="BufferUsage.none">
<td><code>none</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferUsage.cpu">
<td><code>cpu</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferUsage.vulkan">
<td><code>vulkan</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferUsage.display">
<td><code>display</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="BufferUsage.video">
<td><code>video</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### ColorSpace {#ColorSpace data-text="ColorSpace"}
*Defined in [fuchsia.sysmem/image_formats.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats.fidl;l=118)*
<p>Describes how the pixels within an image are meant to be presented.
Simple color spaces need only a type.
Parametric color spaces may require additional properties.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="ColorSpace.type">
<td><code>type</code></td>
<td>
<code><a class='link' href='#ColorSpaceType'>ColorSpaceType</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### FormatModifier {#FormatModifier data-text="FormatModifier"}
*Defined in [fuchsia.sysmem/format_modifier.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=7)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="FormatModifier.value">
<td><code>value</code></td>
<td>
<code>uint64</code>
</td>
<td><p>The upper 8 bits are a vendor code as allocated in FormatModifierVendor
enum. The lower 56 bits are vendor-defined.</p>
<p>This field and the values that go in this field are defined this way for
compatibility reasons.</p>
</td>
<td>No default</td>
</tr>
</table>
### ImageFormat {#ImageFormat data-text="ImageFormat"}
*Defined in [fuchsia.sysmem/image_formats_deprecated.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats_deprecated.fidl;l=9)*
<p>Describes how an image is represented.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="ImageFormat.width">
<td><code>width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Row width in pixels.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat.height">
<td><code>height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of rows.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat.layers">
<td><code>layers</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of layers within a multi-layered image.
Defaults to 1 if not specified.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormat.pixel_format">
<td><code>pixel_format</code></td>
<td>
<code><a class='link' href='#PixelFormat'>PixelFormat</a></code>
</td>
<td><p>Pixel format.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat.color_space">
<td><code>color_space</code></td>
<td>
<code><a class='link' href='#ColorSpace'>ColorSpace</a></code>
</td>
<td><p>Color space.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat.planes">
<td><code>planes</code></td>
<td>
<code>[4]</code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### ImageFormatConstraints {#ImageFormatConstraints data-text="ImageFormatConstraints"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=300)*
<p>Describes constraints on layout of image data in buffers.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="ImageFormatConstraints.pixel_format">
<td><code>pixel_format</code></td>
<td>
<code><a class='link' href='#PixelFormat'>PixelFormat</a></code>
</td>
<td><p>The PixelFormat for which the following constraints apply. A
participant may have more than one PixelFormat that's supported, in
which case that participant can use a list of ImageFormatConstraints
with an entry per PixelFormat. It's not uncommon for the other fields
of ImageFormatConstraints to vary by PixelFormat - for example for a
linear format to support smaller max size than a tiled format.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.color_spaces_count">
<td><code>color_spaces_count</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Empty is an error. Redundant entries are an error. Arbitrary ordering
is not an error.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.color_space">
<td><code>color_space</code></td>
<td>
<code>[32]</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.min_coded_width">
<td><code>min_coded_width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Minimum permitted width in pixels.</p>
<p>For example a video decoder participant may set this field to the
minimum coded_width that might potentially be specified by a stream. In
contrast, required_min_coded_width would be set to the current
coded_width specified by the stream. While min_coded_width aggregates
by taking the max, required_min_coded_width aggregates by taking the
min.</p>
<p>See also required_min_coded_width.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.max_coded_width">
<td><code>max_coded_width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Maximum width in pixels. For example Scenic may set this field
(directly or via sub-participants) to the maximum width that can be
composited.
0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.min_coded_height">
<td><code>min_coded_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Minimum height in pixels. For example a video decoder participant may
set this field to the coded_height specified by a stream.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.max_coded_height">
<td><code>max_coded_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Maximum height in pixels. For example Scenic may set this field
(directly or via sub-participants) to the maximum height that can be
composited.
0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.min_bytes_per_row">
<td><code>min_bytes_per_row</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Must be &gt;= the value implied by min_coded_width for plane 0.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.max_bytes_per_row">
<td><code>max_bytes_per_row</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Must be &gt;= the value implied by max_coded_width for plane 0.
0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.max_coded_width_times_coded_height">
<td><code>max_coded_width_times_coded_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>The max image area in pixels is limited indirectly via
BufferSettings.size_bytes, and can also be enforced directly via this
field.
0 is treated as 0xFFFFFFFF.</p>
</td>
<td>4294967295</td>
</tr>
<tr id="ImageFormatConstraints.layers">
<td><code>layers</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of layers within a multi-layered image.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.coded_width_divisor">
<td><code>coded_width_divisor</code></td>
<td>
<code>uint32</code>
</td>
<td><p>coded_width % width_divisor must be 0.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.coded_height_divisor">
<td><code>coded_height_divisor</code></td>
<td>
<code>uint32</code>
</td>
<td><p>coded_height % height_divisor must be 0.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.bytes_per_row_divisor">
<td><code>bytes_per_row_divisor</code></td>
<td>
<code>uint32</code>
</td>
<td><p>bytes_per_row % bytes_per_row_divisor must be 0.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.start_offset_divisor">
<td><code>start_offset_divisor</code></td>
<td>
<code>uint32</code>
</td>
<td><p>vmo_usable_start % start_offset_divisor must be 0.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.display_width_divisor">
<td><code>display_width_divisor</code></td>
<td>
<code>uint32</code>
</td>
<td><p>display_width % display_width_divisor must be 0.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.display_height_divisor">
<td><code>display_height_divisor</code></td>
<td>
<code>uint32</code>
</td>
<td><p>display_height % display_height_divisor must be 0.
0 is treated as 1.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormatConstraints.required_min_coded_width">
<td><code>required_min_coded_width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>required_ dimension bounds.</p>
<p>In contrast to the corresponding fields without &quot;required_&quot; at the
start, these fields (when set to non-zero values) express a requirement
that the resulting aggregated non-required_ fields specify a space that
fully contain the space expressed by each participant's required_
fields.</p>
<p>For example, a producer video decoder is perfectly happy for the
consumer to be willing to accept anything, and the video decoder doesn't
really want to constrain the potential space of dimensions that might be
seen in a stream and may be acceptable to the consumer, but the video
decoder needs to ensure that the resulting dimension ranges contain
at least the current dimensions decoded from the stream.</p>
<p>Similarly, an initiator with a particular dynamic-dimension scenario in
mind may wish to require up front that participants agree to handle at
least the range of dimensions expected by the initiator in that
scenario (else fail earlier rather than later, maybe trying again with
smaller required_ space).</p>
<p>It's much more common for a producer or initiator to set these fields
than for a consumer to set these fields.</p>
<p>While the non-required_ fields aggregate by taking the intersection, the
required_ fields aggregate by taking the union.</p>
<p>If set, the required_max_coded_width and required_max_coded_height will
cause the allocated buffers to be large enough to hold an image that is
required_max_coded_width * required_max_coded_height.</p>
<p>TODO(dustingreen): Make it easier to allocate buffers of minimal size
that can (optionally) also handle 90 degree rotated version of the max
dimensions / alternate required bounds for another main aspect ratio.
0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.required_max_coded_width">
<td><code>required_max_coded_width</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.required_min_coded_height">
<td><code>required_min_coded_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.required_max_coded_height">
<td><code>required_max_coded_height</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.required_min_bytes_per_row">
<td><code>required_min_bytes_per_row</code></td>
<td>
<code>uint32</code>
</td>
<td><p>0 is treated as 0xFFFFFFFF.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormatConstraints.required_max_bytes_per_row">
<td><code>required_max_bytes_per_row</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### ImageFormat_2 {#ImageFormat_2 data-text="ImageFormat_2"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=436)*
<p>Describes how an image is represented.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="ImageFormat_2.pixel_format">
<td><code>pixel_format</code></td>
<td>
<code><a class='link' href='#PixelFormat'>PixelFormat</a></code>
</td>
<td><p>Pixel format.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.coded_width">
<td><code>coded_width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Row width in pixels that exist in the buffer. Must be &gt;= display_width.
Can be &lt; the width implied by stride_bytes.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.coded_height">
<td><code>coded_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of rows. Must be &gt;= display_height.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.bytes_per_row">
<td><code>bytes_per_row</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.display_width">
<td><code>display_width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Row width in pixels that are to be displayed. This can be &lt;=
coded_width. Any cropping occurs on the right of the image (not left).</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.display_height">
<td><code>display_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of rows to be displayed. This can be &lt;= coded_height, with any
cropping on the bottom (not top).</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.layers">
<td><code>layers</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of layers within a multi-layered image.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageFormat_2.color_space">
<td><code>color_space</code></td>
<td>
<code><a class='link' href='#ColorSpace'>ColorSpace</a></code>
</td>
<td><p>Color space.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageFormat_2.has_pixel_aspect_ratio">
<td><code>has_pixel_aspect_ratio</code></td>
<td>
<code>bool</code>
</td>
<td><p>The pixel_aspect_ratio_width : pixel_aspect_ratio_height is the
pixel aspect ratio (AKA sample aspect ratio aka SAR) for the luma
(AKA Y) samples. A pixel_aspect_ratio of 1:1 mean square pixels. A
pixel_aspect_ratio of 2:1 would mean pixels that are displayed twice
as wide as they are tall. Codec implementation should ensure these
two values are relatively prime by reducing the fraction (dividing
both by GCF) if necessary.</p>
<p>When has_pixel_aspect_ratio == false, the pixel_aspect_ratio is unknown.
A default of 1:1 can be appropriate in some cases, but as always, a
consumer may determine the actual pixel_aspect_ratio by OOB means.</p>
</td>
<td>false</td>
</tr>
<tr id="ImageFormat_2.pixel_aspect_ratio_width">
<td><code>pixel_aspect_ratio_width</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>1</td>
</tr>
<tr id="ImageFormat_2.pixel_aspect_ratio_height">
<td><code>pixel_aspect_ratio_height</code></td>
<td>
<code>uint32</code>
</td>
<td></td>
<td>1</td>
</tr>
</table>
### ImagePlane {#ImagePlane data-text="ImagePlane"}
*Defined in [fuchsia.sysmem/image_formats_deprecated.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats_deprecated.fidl;l=31)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="ImagePlane.byte_offset">
<td><code>byte_offset</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Byte offset of the start of the plane from the beginning of the image.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImagePlane.bytes_per_row">
<td><code>bytes_per_row</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Stride in bytes per row.
Only meaningful for linear buffer formats.</p>
</td>
<td>No default</td>
</tr>
</table>
### ImageSpec {#ImageSpec data-text="ImageSpec"}
*Defined in [fuchsia.sysmem/image_formats_deprecated.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats_deprecated.fidl;l=42)*
<p>Describes constraints for allocating images of some desired form.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="ImageSpec.min_width">
<td><code>min_width</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Minimum width in pixels.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageSpec.min_height">
<td><code>min_height</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Minimum height in pixels.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageSpec.layers">
<td><code>layers</code></td>
<td>
<code>uint32</code>
</td>
<td><p>Number of layers within a multi-layered image.
Defaults to 1 if not specified.</p>
</td>
<td>1</td>
</tr>
<tr id="ImageSpec.pixel_format">
<td><code>pixel_format</code></td>
<td>
<code><a class='link' href='#PixelFormat'>PixelFormat</a></code>
</td>
<td><p>Pixel format.</p>
</td>
<td>No default</td>
</tr>
<tr id="ImageSpec.color_space">
<td><code>color_space</code></td>
<td>
<code><a class='link' href='#ColorSpace'>ColorSpace</a></code>
</td>
<td><p>Color space.</p>
</td>
<td>No default</td>
</tr>
</table>
### PixelFormat {#PixelFormat data-text="PixelFormat"}
*Defined in [fuchsia.sysmem/image_formats.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats.fidl;l=11)*
<p>Describes how the pixels within an image are represented.
Simple formats need only a type.
Parametric pixel formats may require additional properties.</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="PixelFormat.type">
<td><code>type</code></td>
<td>
<code><a class='link' href='#PixelFormatType'>PixelFormatType</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="PixelFormat.has_format_modifier">
<td><code>has_format_modifier</code></td>
<td>
<code>bool</code>
</td>
<td><p>This bool effectively makes format_modifier optional, to satisfy
'ForDeprecatedCBindings', to satisfy &quot;FIDL Simple C Bindings&quot;.</p>
</td>
<td>No default</td>
</tr>
<tr id="PixelFormat.format_modifier">
<td><code>format_modifier</code></td>
<td>
<code><a class='link' href='#FormatModifier'>FormatModifier</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### SecureMem_AddSecureHeapPhysicalRange_Response {#SecureMem_AddSecureHeapPhysicalRange_Response data-text="SecureMem_AddSecureHeapPhysicalRange_Response"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=97)*
&lt;EMPTY&gt;
### SecureMem_DeleteSecureHeapPhysicalRange_Response {#SecureMem_DeleteSecureHeapPhysicalRange_Response data-text="SecureMem_DeleteSecureHeapPhysicalRange_Response"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=139)*
&lt;EMPTY&gt;
### SecureMem_GetPhysicalSecureHeapProperties_Response {#SecureMem_GetPhysicalSecureHeapProperties_Response data-text="SecureMem_GetPhysicalSecureHeapProperties_Response"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=56)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="SecureMem_GetPhysicalSecureHeapProperties_Response.properties">
<td><code>properties</code></td>
<td>
<code><a class='link' href='#SecureHeapProperties'>SecureHeapProperties</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### SecureMem_GetPhysicalSecureHeaps_Response {#SecureMem_GetPhysicalSecureHeaps_Response data-text="SecureMem_GetPhysicalSecureHeaps_Response"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=48)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="SecureMem_GetPhysicalSecureHeaps_Response.heaps">
<td><code>heaps</code></td>
<td>
<code><a class='link' href='#SecureHeapsAndRanges'>SecureHeapsAndRanges</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### SecureMem_ModifySecureHeapPhysicalRange_Response {#SecureMem_ModifySecureHeapPhysicalRange_Response data-text="SecureMem_ModifySecureHeapPhysicalRange_Response"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=184)*
&lt;EMPTY&gt;
### SecureMem_ZeroSubRange_Response {#SecureMem_ZeroSubRange_Response data-text="SecureMem_ZeroSubRange_Response"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=205)*
&lt;EMPTY&gt;
### SingleBufferInfo [resource](/fuchsia-src/reference/fidl/language/language.md#value-vs-resource){:.fidl-attribute} {#SingleBufferInfo data-text="SingleBufferInfo"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=187)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="SingleBufferInfo.settings">
<td><code>settings</code></td>
<td>
<code><a class='link' href='#SingleBufferSettings'>SingleBufferSettings</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="SingleBufferInfo.buffer">
<td><code>buffer</code></td>
<td>
<code><a class='link' href='#VmoBuffer'>VmoBuffer</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### SingleBufferSettings {#SingleBufferSettings data-text="SingleBufferSettings"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=198)*
<p>After the initial buffer allocation, it's allowed to close old buffers and
allocate new buffers. When a new buffer is allocated its settings can
differ from the rest of the buffers in the collection, and the single
buffer's settings are delivered via OnSingleBufferAllocated() using this
struct:</p>
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="SingleBufferSettings.buffer_settings">
<td><code>buffer_settings</code></td>
<td>
<code><a class='link' href='#BufferMemorySettings'>BufferMemorySettings</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
<tr id="SingleBufferSettings.has_image_format_constraints">
<td><code>has_image_format_constraints</code></td>
<td>
<code>bool</code>
</td>
<td><p>Buffers holding data that is not uncompressed image data will not have
this field set. Buffers holding data that is uncompressed image data
<em>may</em> have this field set.</p>
<p>At least for now, changing the PixelFormat requires re-allocating
buffers.</p>
</td>
<td>No default</td>
</tr>
<tr id="SingleBufferSettings.image_format_constraints">
<td><code>image_format_constraints</code></td>
<td>
<code><a class='link' href='#ImageFormatConstraints'>ImageFormatConstraints</a></code>
</td>
<td></td>
<td>No default</td>
</tr>
</table>
### VmoBuffer [resource](/fuchsia-src/reference/fidl/language/language.md#value-vs-resource){:.fidl-attribute} {#VmoBuffer data-text="VmoBuffer"}
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=145)*
<table>
<tr><th>Field</th><th>Type</th><th>Description</th><th>Default</th></tr>
<tr id="VmoBuffer.vmo">
<td><code>vmo</code></td>
<td>
<code>handle&lt;vmo&gt;?</code>
</td>
<td><p>The same VMO can be used by more than one CodecBuffer (only of the same
buffer_lifetime_ordinal), but each vmo handle must be a separate handle.</p>
<p>The vmo field can be 0 if this is a VmoBuffer in BufferCollectionInfo_2
that's at or beyond BufferCollectionInfo_2.buffer_count.</p>
</td>
<td>No default</td>
</tr>
<tr id="VmoBuffer.vmo_usable_start">
<td><code>vmo_usable_start</code></td>
<td>
<code>uint64</code>
</td>
<td><p>Offset within the VMO of the first usable byte. Must be &lt; the VMO's
size in bytes, and leave sufficient room for
BufferMemorySettings.size_bytes before the end of the VMO.</p>
</td>
<td>No default</td>
</tr>
</table>
## **ENUMS**
### CoherencyDomain [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#CoherencyDomain data-text="CoherencyDomain"}
Type: <code>uint32</code>
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=280)*
<p>Inaccessible is only for cases where there is no CPU-based access to the
buffers. A secure_required buffer can still have CoherencyDomain Cpu or
Ram even if the secure_required buffer can only be accessed by the CPU when
the CPU is running in secure mode (or similar). In contrast, device-local
memory that isn't reachable from the CPU is CoherencyDomain Inaccessible,
even if it's possible to cause a device (physical or virtual) to copy the
data from the Inaccessible buffers to buffers that are visible to the CPU.</p>
<table>
<tr><th>Name</th><th>Value</th><th>Description</th></tr>
<tr id="CoherencyDomain.CPU">
<td><h3 id="CoherencyDomain.CPU" class="add-link hide-from-toc">CPU</h3></td>
<td><code>0</code></td>
<td></td>
</tr>
<tr id="CoherencyDomain.RAM">
<td><h3 id="CoherencyDomain.RAM" class="add-link hide-from-toc">RAM</h3></td>
<td><code>1</code></td>
<td></td>
</tr>
<tr id="CoherencyDomain.INACCESSIBLE">
<td><h3 id="CoherencyDomain.INACCESSIBLE" class="add-link hide-from-toc">INACCESSIBLE</h3></td>
<td><code>2</code></td>
<td></td>
</tr>
</table>
### ColorSpaceType [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#ColorSpaceType data-text="ColorSpaceType"}
Type: <code>uint32</code>
*Defined in [fuchsia.sysmem/image_formats.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats.fidl;l=148)*
<p>This list has a separate entry for each variant of a color space standard.</p>
<p>For this reason, should we ever add support for the RGB variant of 709, for
example, we'd add a separate entry to this list for that variant. Similarly
for the RGB variants of 2020 or 2100. Similarly for the YcCbcCrc variant of
2020. Similarly for the ICtCp variant of 2100.</p>
<p>A given ColorSpaceType may permit usage with a PixelFormatType(s) that
provides a bits-per-sample that's compatible with the ColorSpaceType's
official spec. Not all spec-valid combinations are necessarily supported.
See ImageFormatIsSupportedColorSpaceForPixelFormat() for the best-case degree
of support, but a &quot;true&quot; from that function doesn't guarantee that any given
combination of participants will all support the desired combination of
ColorSpaceType and PixelFormatType.</p>
<p>The sysmem service helps find a mutually supported combination and allocate
suitable buffers.</p>
<p>A ColorSpaceType's spec is not implicitly extended to support
outside-the-standard bits-per-sample (R, G, B, or Y sample). For example,
for 2020 and 2100, 8 bits-per-Y-sample is not supported (by sysmem), because
8 bits-per-Y-sample is not in the spec for 2020 or 2100. A sysmem
participant that attempts to advertise support for a PixelFormat + ColorSpace
that's non-standard will cause sysmem to reject the combo and fail to
allocate (intentionally, to strongly discourage specifying
insufficiently-defined combos).</p>
<table>
<tr><th>Name</th><th>Value</th><th>Description</th></tr>
<tr id="ColorSpaceType.INVALID">
<td><h3 id="ColorSpaceType.INVALID" class="add-link hide-from-toc">INVALID</h3></td>
<td><code>0</code></td>
<td><p>Not a valid color space type.</p>
</td>
</tr>
<tr id="ColorSpaceType.SRGB">
<td><h3 id="ColorSpaceType.SRGB" class="add-link hide-from-toc">SRGB</h3></td>
<td><code>1</code></td>
<td><p>sRGB</p>
</td>
</tr>
<tr id="ColorSpaceType.REC601_NTSC">
<td><h3 id="ColorSpaceType.REC601_NTSC" class="add-link hide-from-toc">REC601_NTSC</h3></td>
<td><code>2</code></td>
<td><p>601 NTSC (&quot;525 line&quot;) YCbCr primaries, narrow</p>
</td>
</tr>
<tr id="ColorSpaceType.REC601_NTSC_FULL_RANGE">
<td><h3 id="ColorSpaceType.REC601_NTSC_FULL_RANGE" class="add-link hide-from-toc">REC601_NTSC_FULL_RANGE</h3></td>
<td><code>3</code></td>
<td><p>601 NTSC (&quot;525 line&quot;) YCbCr primaries, wide</p>
</td>
</tr>
<tr id="ColorSpaceType.REC601_PAL">
<td><h3 id="ColorSpaceType.REC601_PAL" class="add-link hide-from-toc">REC601_PAL</h3></td>
<td><code>4</code></td>
<td><p>601 PAL (&quot;625 line&quot;) YCbCr primaries, narrow</p>
</td>
</tr>
<tr id="ColorSpaceType.REC601_PAL_FULL_RANGE">
<td><h3 id="ColorSpaceType.REC601_PAL_FULL_RANGE" class="add-link hide-from-toc">REC601_PAL_FULL_RANGE</h3></td>
<td><code>5</code></td>
<td><p>601 PAL (&quot;625 line&quot;) YCbCr primaries, wide</p>
</td>
</tr>
<tr id="ColorSpaceType.REC709">
<td><h3 id="ColorSpaceType.REC709" class="add-link hide-from-toc">REC709</h3></td>
<td><code>6</code></td>
<td><p>709 YCbCr (not RGB)</p>
</td>
</tr>
<tr id="ColorSpaceType.REC2020">
<td><h3 id="ColorSpaceType.REC2020" class="add-link hide-from-toc">REC2020</h3></td>
<td><code>7</code></td>
<td><p>2020 YCbCr (not RGB, not YcCbcCrc)</p>
</td>
</tr>
<tr id="ColorSpaceType.REC2100">
<td><h3 id="ColorSpaceType.REC2100" class="add-link hide-from-toc">REC2100</h3></td>
<td><code>8</code></td>
<td><p>2100 YCbCr (not RGB, not ICtCp)</p>
</td>
</tr>
<tr id="ColorSpaceType.PASS_THROUGH">
<td><h3 id="ColorSpaceType.PASS_THROUGH" class="add-link hide-from-toc">PASS_THROUGH</h3></td>
<td><code>9</code></td>
<td><p>Either the pixel format doesn't represent a color, or it's in an
application-specific colorspace that isn't describable by another entry
in this enum.</p>
</td>
</tr>
</table>
### HeapType [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#HeapType data-text="HeapType"}
Type: <code>uint64</code>
*Defined in [fuchsia.sysmem/constraints.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=214)*
<p>Known heap types.
Device specific types should have bit 60 set. Top order bit is reserved
and should not be set.</p>
<table>
<tr><th>Name</th><th>Value</th><th>Description</th></tr>
<tr id="HeapType.SYSTEM_RAM">
<td><h3 id="HeapType.SYSTEM_RAM" class="add-link hide-from-toc">SYSTEM_RAM</h3></td>
<td><code>0</code></td>
<td></td>
</tr>
<tr id="HeapType.AMLOGIC_SECURE">
<td><h3 id="HeapType.AMLOGIC_SECURE" class="add-link hide-from-toc">AMLOGIC_SECURE</h3></td>
<td><code>1152921504606912512</code></td>
<td><p>Heap used for amlogic protected memory.</p>
</td>
</tr>
<tr id="HeapType.AMLOGIC_SECURE_VDEC">
<td><h3 id="HeapType.AMLOGIC_SECURE_VDEC" class="add-link hide-from-toc">AMLOGIC_SECURE_VDEC</h3></td>
<td><code>1152921504606912513</code></td>
<td><p>Heap used for amlogic protected memory between decrypt and video decode.</p>
</td>
</tr>
<tr id="HeapType.GOLDFISH_DEVICE_LOCAL">
<td><h3 id="HeapType.GOLDFISH_DEVICE_LOCAL" class="add-link hide-from-toc">GOLDFISH_DEVICE_LOCAL</h3></td>
<td><code>1152921504606978048</code></td>
<td><p>Heap used by goldfish vulkan for device-local memory.</p>
</td>
</tr>
<tr id="HeapType.GOLDFISH_HOST_VISIBLE">
<td><h3 id="HeapType.GOLDFISH_HOST_VISIBLE" class="add-link hide-from-toc">GOLDFISH_HOST_VISIBLE</h3></td>
<td><code>1152921504606978049</code></td>
<td><p>Heap used by goldfish vulkan for host-visible memory.</p>
</td>
</tr>
<tr id="HeapType.FRAMEBUFFER">
<td><h3 id="HeapType.FRAMEBUFFER" class="add-link hide-from-toc">FRAMEBUFFER</h3></td>
<td><code>1152921504607043585</code></td>
<td><p>Heap used for display framebuffer. This is used by display drivers
limited to a single framebuffer located at a specific physical address.
The framebuffer heap makes it possible to create buffer collections
for the framebuffer and enables sysmem support in these drivers.</p>
</td>
</tr>
</table>
### PixelFormatType [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#PixelFormatType data-text="PixelFormatType"}
Type: <code>uint32</code>
*Defined in [fuchsia.sysmem/image_formats.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/image_formats.fidl;l=30)*
<p>The ordering of the channels in the format name reflects how
the actual layout of the channel.</p>
<p>Each of these values is opinionated re. the color spaces that can be
contained within (in contrast with Vulkan).</p>
<p>This should be kept in sync with fuchsia.sysmem2.PixelFormatType.</p>
<table>
<tr><th>Name</th><th>Value</th><th>Description</th></tr>
<tr id="PixelFormatType.INVALID">
<td><h3 id="PixelFormatType.INVALID" class="add-link hide-from-toc">INVALID</h3></td>
<td><code>0</code></td>
<td></td>
</tr>
<tr id="PixelFormatType.R8G8B8A8">
<td><h3 id="PixelFormatType.R8G8B8A8" class="add-link hide-from-toc">R8G8B8A8</h3></td>
<td><code>1</code></td>
<td><p>RGB only, 8 bits per each of R/G/B/A sample
Compatible with VK_FORMAT_R8G8B8A8_UNORM.
Compatible with ZX_PIXEL_FORMAT_ABGR_8888 and ZX_PIXEL_FORMAT_BGR_x8888.</p>
</td>
</tr>
<tr id="PixelFormatType.BGRA32">
<td><h3 id="PixelFormatType.BGRA32" class="add-link hide-from-toc">BGRA32</h3></td>
<td><code>101</code></td>
<td><p>32bpp BGRA, 1 plane. RGB only, 8 bits per each of B/G/R/A sample.
Compatible with VK_FORMAT_B8G8R8A8_UNORM.
Compatible with ZX_PIXEL_FORMAT_RGB_x888 and ZX_PIXEL_FORMAT_ARGB_8888.</p>
</td>
</tr>
<tr id="PixelFormatType.I420">
<td><h3 id="PixelFormatType.I420" class="add-link hide-from-toc">I420</h3></td>
<td><code>102</code></td>
<td><p>YUV only, 8 bits per Y sample
Compatible with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM.</p>
</td>
</tr>
<tr id="PixelFormatType.M420">
<td><h3 id="PixelFormatType.M420" class="add-link hide-from-toc">M420</h3></td>
<td><code>103</code></td>
<td><p>YUV only, 8 bits per Y sample
Not compatible with any vulkan format.</p>
</td>
</tr>
<tr id="PixelFormatType.NV12">
<td><h3 id="PixelFormatType.NV12" class="add-link hide-from-toc">NV12</h3></td>
<td><code>104</code></td>
<td><p>YUV only, 8 bits per Y sample
Compatible with VK_FORMAT_G8_B8R8_2PLANE_420_UNORM.
Compatible with ZX_PIXEL_FORMAT_NV12.</p>
</td>
</tr>
<tr id="PixelFormatType.YUY2">
<td><h3 id="PixelFormatType.YUY2" class="add-link hide-from-toc">YUY2</h3></td>
<td><code>105</code></td>
<td><p>YUV only, 8 bits per Y sample
Compatible with VK_FORMAT_G8B8G8R8_422_UNORM.</p>
</td>
</tr>
<tr id="PixelFormatType.MJPEG">
<td><h3 id="PixelFormatType.MJPEG" class="add-link hide-from-toc">MJPEG</h3></td>
<td><code>106</code></td>
<td></td>
</tr>
<tr id="PixelFormatType.YV12">
<td><h3 id="PixelFormatType.YV12" class="add-link hide-from-toc">YV12</h3></td>
<td><code>107</code></td>
<td><p>YUV only, 8 bits per Y sample
Compatible with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM with B and R swizzled.</p>
</td>
</tr>
<tr id="PixelFormatType.BGR24">
<td><h3 id="PixelFormatType.BGR24" class="add-link hide-from-toc">BGR24</h3></td>
<td><code>108</code></td>
<td><p>24bpp BGR, 1 plane. RGB only, 8 bits per each of B/G/R sample
Compatible with VK_FORMAT_B8G8R8_UNORM.
Compatible with ZX_PIXEL_FORMAT_RGB_888.</p>
</td>
</tr>
<tr id="PixelFormatType.RGB565">
<td><h3 id="PixelFormatType.RGB565" class="add-link hide-from-toc">RGB565</h3></td>
<td><code>109</code></td>
<td><p>16bpp RGB, 1 plane. 5 bits R, 6 bits G, 5 bits B
Compatible with VK_FORMAT_R5G6B5_UNORM_PACK16.
Compatible with ZX_PIXEL_FORMAT_RGB_565.</p>
</td>
</tr>
<tr id="PixelFormatType.RGB332">
<td><h3 id="PixelFormatType.RGB332" class="add-link hide-from-toc">RGB332</h3></td>
<td><code>110</code></td>
<td><p>8bpp RGB, 1 plane. 3 bits R, 3 bits G, 2 bits B
Not compatible with any vulkan format.
Compatible with ZX_PIXEL_FORMAT_RGB_332.</p>
</td>
</tr>
<tr id="PixelFormatType.RGB2220">
<td><h3 id="PixelFormatType.RGB2220" class="add-link hide-from-toc">RGB2220</h3></td>
<td><code>111</code></td>
<td><p>8bpp RGB, 1 plane. 2 bits R, 2 bits G, 2 bits B
Not compatible with any vulkan format.
Compatible with ZX_PIXEL_FORMAT_RGB_2220.</p>
</td>
</tr>
<tr id="PixelFormatType.L8">
<td><h3 id="PixelFormatType.L8" class="add-link hide-from-toc">L8</h3></td>
<td><code>112</code></td>
<td><p>8bpp, Luminance-only (red, green and blue have identical values.)
Compatible with VK_FORMAT_R8_UNORM.
Compatible with ZX_PIXEL_FORMAT_GRAY_8 and ZX_PIXEL_FORMAT_MONO_8.</p>
</td>
</tr>
<tr id="PixelFormatType.R8">
<td><h3 id="PixelFormatType.R8" class="add-link hide-from-toc">R8</h3></td>
<td><code>113</code></td>
<td><p>8bpp, Red-only (Green and Blue are to be interpreted as 0).
Compatible with VK_FORMAT_R8_UNORM.</p>
</td>
</tr>
<tr id="PixelFormatType.R8G8">
<td><h3 id="PixelFormatType.R8G8" class="add-link hide-from-toc">R8G8</h3></td>
<td><code>114</code></td>
<td><p>16bpp RG, 1 plane. 8 bits R, 8 bits G.
Compatible with VK_FORMAT_R8G8_UNORM.</p>
</td>
</tr>
<tr id="PixelFormatType.A2R10G10B10">
<td><h3 id="PixelFormatType.A2R10G10B10" class="add-link hide-from-toc">A2R10G10B10</h3></td>
<td><code>115</code></td>
<td><p>32bpp RGBA, 1 plane. 2 bits A, 10 bits R/G/B.
Compatible with VK_FORMAT_A2R10G10B10_UNORM_PACK32.
Compatible with ZX_PIXEL_FORMAT_ARGB_2_10_10_10.</p>
</td>
</tr>
<tr id="PixelFormatType.A2B10G10R10">
<td><h3 id="PixelFormatType.A2B10G10R10" class="add-link hide-from-toc">A2B10G10R10</h3></td>
<td><code>116</code></td>
<td><p>32bpp BGRA, 1 plane. 2 bits A, 10 bits R/G/B.
Compatible with VK_FORMAT_A2B10G10R10_UNORM_PACK32.
Compatible with ZX_PIXEL_FORMAT_ABGR_2_10_10_10.</p>
</td>
</tr>
</table>
## **TABLES**
### SecureHeapAndRange {#SecureHeapAndRange data-text="SecureHeapAndRange"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=280)*
<table>
<tr><th>Ordinal</th><th>Field</th><th>Type</th><th>Description</th></tr>
<tr id="SecureHeapAndRange.heap">
<td><h3 id="SecureHeapAndRange.heap" class="add-link hide-from-toc">1</h3></td>
<td><code>heap</code></td>
<td>
<code><a class='link' href='#HeapType'>HeapType</a></code>
</td>
<td></td>
</tr>
<tr id="SecureHeapAndRange.range">
<td><h3 id="SecureHeapAndRange.range" class="add-link hide-from-toc">2</h3></td>
<td><code>range</code></td>
<td>
<code><a class='link' href='#SecureHeapRange'>SecureHeapRange</a></code>
</td>
<td></td>
</tr>
</table>
### SecureHeapAndRangeModification {#SecureHeapAndRangeModification data-text="SecureHeapAndRangeModification"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=285)*
<table>
<tr><th>Ordinal</th><th>Field</th><th>Type</th><th>Description</th></tr>
<tr id="SecureHeapAndRangeModification.heap">
<td><h3 id="SecureHeapAndRangeModification.heap" class="add-link hide-from-toc">1</h3></td>
<td><code>heap</code></td>
<td>
<code><a class='link' href='#HeapType'>HeapType</a></code>
</td>
<td></td>
</tr>
<tr id="SecureHeapAndRangeModification.old_range">
<td><h3 id="SecureHeapAndRangeModification.old_range" class="add-link hide-from-toc">2</h3></td>
<td><code>old_range</code></td>
<td>
<code><a class='link' href='#SecureHeapRange'>SecureHeapRange</a></code>
</td>
<td></td>
</tr>
<tr id="SecureHeapAndRangeModification.new_range">
<td><h3 id="SecureHeapAndRangeModification.new_range" class="add-link hide-from-toc">3</h3></td>
<td><code>new_range</code></td>
<td>
<code><a class='link' href='#SecureHeapRange'>SecureHeapRange</a></code>
</td>
<td></td>
</tr>
</table>
### SecureHeapAndRanges {#SecureHeapAndRanges data-text="SecureHeapAndRanges"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=265)*
<table>
<tr><th>Ordinal</th><th>Field</th><th>Type</th><th>Description</th></tr>
<tr id="SecureHeapAndRanges.heap">
<td><h3 id="SecureHeapAndRanges.heap" class="add-link hide-from-toc">1</h3></td>
<td><code>heap</code></td>
<td>
<code><a class='link' href='#HeapType'>HeapType</a></code>
</td>
<td><p>This is which secure/protected heap.</p>
</td>
</tr>
<tr id="SecureHeapAndRanges.ranges">
<td><h3 id="SecureHeapAndRanges.ranges" class="add-link hide-from-toc">2</h3></td>
<td><code>ranges</code></td>
<td>
<code>vector&lt;<a class='link' href='#SecureHeapRange'>SecureHeapRange</a>&gt;[128]</code>
</td>
<td><p>The list of physical ranges. This list must be sorted by
physical_address (lower first), and must not have any overlapping
ranges. Ranges that are directly adjacent are allowed (not
overlapping).</p>
</td>
</tr>
</table>
### SecureHeapProperties {#SecureHeapProperties data-text="SecureHeapProperties"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=208)*
<table>
<tr><th>Ordinal</th><th>Field</th><th>Type</th><th>Description</th></tr>
<tr id="SecureHeapProperties.heap">
<td><h3 id="SecureHeapProperties.heap" class="add-link hide-from-toc">1</h3></td>
<td><code>heap</code></td>
<td>
<code><a class='link' href='#HeapType'>HeapType</a></code>
</td>
<td><p>The HeapType is repeated here for convenience.</p>
</td>
</tr>
<tr id="SecureHeapProperties.dynamic_protection_ranges">
<td><h3 id="SecureHeapProperties.dynamic_protection_ranges" class="add-link hide-from-toc">2</h3></td>
<td><code>dynamic_protection_ranges</code></td>
<td>
<code>bool</code>
</td>
<td><p>If true, more than one call to SetPhysicalSecureHeap() for the same
heap is allowed. If false, only one SetPhyscialSecureHeap() call is
allowed, and no calls to DeleteSecureHeapPhysicalRange() or
ModifySecureHeapPhysicalRange() are allowed. Even when this is false,
the SecureMem server (driver) is still responsible for de-protecting
just before warm reboot if protected ranges would not otherwise be
cleaned up during a warm reboot.</p>
</td>
</tr>
<tr id="SecureHeapProperties.protected_range_granularity">
<td><h3 id="SecureHeapProperties.protected_range_granularity" class="add-link hide-from-toc">3</h3></td>
<td><code>protected_range_granularity</code></td>
<td>
<code>uint32</code>
</td>
<td><p>The granularity of protection ranges. If the granularity of start is
different than granularity of end or length, then this is the max
granularity value among those values.</p>
<p>This must be a power of 2. The client must not request ranges that
specify smaller granularity.</p>
<p>This must be at least zx_system_page_size() even if the HW can do
smaller granularity.</p>
</td>
</tr>
<tr id="SecureHeapProperties.max_protected_range_count">
<td><h3 id="SecureHeapProperties.max_protected_range_count" class="add-link hide-from-toc">4</h3></td>
<td><code>max_protected_range_count</code></td>
<td>
<code>uint64</code>
</td>
<td><p>The SecureMem server should not count reserved ranges that the SecureMem
server uses internally to get from range set A to range set B, if the
SecureMem server needs to do any emulation of that sort. Normally such
emulation by the SecureMem server is unnecessary. If any ranges are
reserved by the SecureMem server, those reserved ranges are not
available for use by the SecureMem client.</p>
<p>If the number of ranges is limited only by available memory, it's ok for
the SecureMem server to report 0xFFFFFFFFFFFFFFFF for this value. The
field must still be set. As usual, the SecureMem server should ensure
that SetPhysicalSecureHeapRanges() succeeds or fails atomically (either
fully updates or rolls back before completing).</p>
</td>
</tr>
<tr id="SecureHeapProperties.is_mod_protected_range_available">
<td><h3 id="SecureHeapProperties.is_mod_protected_range_available" class="add-link hide-from-toc">5</h3></td>
<td><code>is_mod_protected_range_available</code></td>
<td>
<code>bool</code>
</td>
<td><p>Iff true, ModifySecureHeapPhysicalRange() is implemented. Calling
ModifySecureHeapPhysicalRange() when is_mod_protected_range_available
is false is prohibited. Don't attempt to detect availability of
ModifySecureHeapPhysicalRange() by calling it to see if it fails; it
may ZX_PANIC().</p>
</td>
</tr>
</table>
### SecureHeapRange {#SecureHeapRange data-text="SecureHeapRange"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=257)*
<table>
<tr><th>Ordinal</th><th>Field</th><th>Type</th><th>Description</th></tr>
<tr id="SecureHeapRange.physical_address">
<td><h3 id="SecureHeapRange.physical_address" class="add-link hide-from-toc">1</h3></td>
<td><code>physical_address</code></td>
<td>
<code>uint64</code>
</td>
<td><p>Must be aligned to at least heap_range_granularity.</p>
</td>
</tr>
<tr id="SecureHeapRange.size_bytes">
<td><h3 id="SecureHeapRange.size_bytes" class="add-link hide-from-toc">2</h3></td>
<td><code>size_bytes</code></td>
<td>
<code>uint64</code>
</td>
<td><p>Must be aligned to at least heap_range_granularity.</p>
</td>
</tr>
</table>
### SecureHeapsAndRanges {#SecureHeapsAndRanges data-text="SecureHeapsAndRanges"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=276)*
<table>
<tr><th>Ordinal</th><th>Field</th><th>Type</th><th>Description</th></tr>
<tr id="SecureHeapsAndRanges.heaps">
<td><h3 id="SecureHeapsAndRanges.heaps" class="add-link hide-from-toc">1</h3></td>
<td><code>heaps</code></td>
<td>
<code>vector&lt;<a class='link' href='#SecureHeapAndRanges'>SecureHeapAndRanges</a>&gt;[32]</code>
</td>
<td></td>
</tr>
</table>
## **UNIONS**
### SecureMem_AddSecureHeapPhysicalRange_Result [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#SecureMem_AddSecureHeapPhysicalRange_Result data-text="SecureMem_AddSecureHeapPhysicalRange_Result"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=97)*
<table>
<tr><th>Ordinal</th><th>Variant</th><th>Type</th><th>Description</th></tr>
<tr id="SecureMem_AddSecureHeapPhysicalRange_Result.response">
<td><h3 id="SecureMem_AddSecureHeapPhysicalRange_Result.response" class="add-link hide-from-toc">1</h3></td>
<td><code>response</code></td>
<td>
<code><a class='link' href='#SecureMem_AddSecureHeapPhysicalRange_Response'>SecureMem_AddSecureHeapPhysicalRange_Response</a></code>
</td>
<td></td>
</tr>
<tr id="SecureMem_AddSecureHeapPhysicalRange_Result.err">
<td><h3 id="SecureMem_AddSecureHeapPhysicalRange_Result.err" class="add-link hide-from-toc">2</h3></td>
<td><code>err</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
<td></td>
</tr>
</table>
### SecureMem_DeleteSecureHeapPhysicalRange_Result [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#SecureMem_DeleteSecureHeapPhysicalRange_Result data-text="SecureMem_DeleteSecureHeapPhysicalRange_Result"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=139)*
<table>
<tr><th>Ordinal</th><th>Variant</th><th>Type</th><th>Description</th></tr>
<tr id="SecureMem_DeleteSecureHeapPhysicalRange_Result.response">
<td><h3 id="SecureMem_DeleteSecureHeapPhysicalRange_Result.response" class="add-link hide-from-toc">1</h3></td>
<td><code>response</code></td>
<td>
<code><a class='link' href='#SecureMem_DeleteSecureHeapPhysicalRange_Response'>SecureMem_DeleteSecureHeapPhysicalRange_Response</a></code>
</td>
<td></td>
</tr>
<tr id="SecureMem_DeleteSecureHeapPhysicalRange_Result.err">
<td><h3 id="SecureMem_DeleteSecureHeapPhysicalRange_Result.err" class="add-link hide-from-toc">2</h3></td>
<td><code>err</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
<td></td>
</tr>
</table>
### SecureMem_GetPhysicalSecureHeapProperties_Result [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#SecureMem_GetPhysicalSecureHeapProperties_Result data-text="SecureMem_GetPhysicalSecureHeapProperties_Result"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=56)*
<table>
<tr><th>Ordinal</th><th>Variant</th><th>Type</th><th>Description</th></tr>
<tr id="SecureMem_GetPhysicalSecureHeapProperties_Result.response">
<td><h3 id="SecureMem_GetPhysicalSecureHeapProperties_Result.response" class="add-link hide-from-toc">1</h3></td>
<td><code>response</code></td>
<td>
<code><a class='link' href='#SecureMem_GetPhysicalSecureHeapProperties_Response'>SecureMem_GetPhysicalSecureHeapProperties_Response</a></code>
</td>
<td></td>
</tr>
<tr id="SecureMem_GetPhysicalSecureHeapProperties_Result.err">
<td><h3 id="SecureMem_GetPhysicalSecureHeapProperties_Result.err" class="add-link hide-from-toc">2</h3></td>
<td><code>err</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
<td></td>
</tr>
</table>
### SecureMem_GetPhysicalSecureHeaps_Result [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#SecureMem_GetPhysicalSecureHeaps_Result data-text="SecureMem_GetPhysicalSecureHeaps_Result"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=48)*
<table>
<tr><th>Ordinal</th><th>Variant</th><th>Type</th><th>Description</th></tr>
<tr id="SecureMem_GetPhysicalSecureHeaps_Result.response">
<td><h3 id="SecureMem_GetPhysicalSecureHeaps_Result.response" class="add-link hide-from-toc">1</h3></td>
<td><code>response</code></td>
<td>
<code><a class='link' href='#SecureMem_GetPhysicalSecureHeaps_Response'>SecureMem_GetPhysicalSecureHeaps_Response</a></code>
</td>
<td></td>
</tr>
<tr id="SecureMem_GetPhysicalSecureHeaps_Result.err">
<td><h3 id="SecureMem_GetPhysicalSecureHeaps_Result.err" class="add-link hide-from-toc">2</h3></td>
<td><code>err</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
<td></td>
</tr>
</table>
### SecureMem_ModifySecureHeapPhysicalRange_Result [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#SecureMem_ModifySecureHeapPhysicalRange_Result data-text="SecureMem_ModifySecureHeapPhysicalRange_Result"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=184)*
<table>
<tr><th>Ordinal</th><th>Variant</th><th>Type</th><th>Description</th></tr>
<tr id="SecureMem_ModifySecureHeapPhysicalRange_Result.response">
<td><h3 id="SecureMem_ModifySecureHeapPhysicalRange_Result.response" class="add-link hide-from-toc">1</h3></td>
<td><code>response</code></td>
<td>
<code><a class='link' href='#SecureMem_ModifySecureHeapPhysicalRange_Response'>SecureMem_ModifySecureHeapPhysicalRange_Response</a></code>
</td>
<td></td>
</tr>
<tr id="SecureMem_ModifySecureHeapPhysicalRange_Result.err">
<td><h3 id="SecureMem_ModifySecureHeapPhysicalRange_Result.err" class="add-link hide-from-toc">2</h3></td>
<td><code>err</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
<td></td>
</tr>
</table>
### SecureMem_ZeroSubRange_Result [strict](/fuchsia-src/reference/fidl/language/language.md#strict-vs-flexible){:.fidl-attribute} {#SecureMem_ZeroSubRange_Result data-text="SecureMem_ZeroSubRange_Result"}
*Defined in [fuchsia.sysmem/secure_mem.fidl](https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=205)*
<table>
<tr><th>Ordinal</th><th>Variant</th><th>Type</th><th>Description</th></tr>
<tr id="SecureMem_ZeroSubRange_Result.response">
<td><h3 id="SecureMem_ZeroSubRange_Result.response" class="add-link hide-from-toc">1</h3></td>
<td><code>response</code></td>
<td>
<code><a class='link' href='#SecureMem_ZeroSubRange_Response'>SecureMem_ZeroSubRange_Response</a></code>
</td>
<td></td>
</tr>
<tr id="SecureMem_ZeroSubRange_Result.err">
<td><h3 id="SecureMem_ZeroSubRange_Result.err" class="add-link hide-from-toc">2</h3></td>
<td><code>err</code></td>
<td>
<code><a class='link' href='../zx/'>zx</a>/<a class='link' href='../zx/#status'>status</a></code>
</td>
<td></td>
</tr>
</table>
## **CONSTANTS**
<table>
<tr><th>Name</th><th>Value</th><th>Type</th><th>Description</th></tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=79">FORMAT_MODIFIER_ARM_AFBC_16X16</a></td>
<td>
<code>576460752303423489</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=88">FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV</a></td>
<td>
<code>576460752303423601</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=89">FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE</a></td>
<td>
<code>576460752303427697</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE_TILED_HEADER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=93">FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE_TILED_HEADER</a></td>
<td>
<code>576460752303435889</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TILED_HEADER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=91">FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TILED_HEADER</a></td>
<td>
<code>576460752303431793</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16_TE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=83">FORMAT_MODIFIER_ARM_AFBC_16X16_TE</a></td>
<td>
<code>576460752303427585</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_16X16_YUV_TILED_HEADER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=86">FORMAT_MODIFIER_ARM_AFBC_16X16_YUV_TILED_HEADER</a></td>
<td>
<code>576460752303431697</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_32X8">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=80">FORMAT_MODIFIER_ARM_AFBC_32X8</a></td>
<td>
<code>576460752303423490</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_AFBC_32X8_TE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=84">FORMAT_MODIFIER_ARM_AFBC_32X8_TE</a></td>
<td>
<code>576460752303427586</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_BCH_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=71">FORMAT_MODIFIER_ARM_BCH_BIT</a></td>
<td>
<code>2048</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_LINEAR_TE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=82">FORMAT_MODIFIER_ARM_LINEAR_TE</a></td>
<td>
<code>576460752303427584</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_SPARSE_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=69">FORMAT_MODIFIER_ARM_SPARSE_BIT</a></td>
<td>
<code>64</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_SPLIT_BLOCK_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=67">FORMAT_MODIFIER_ARM_SPLIT_BLOCK_BIT</a></td>
<td>
<code>32</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_TE_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=73">FORMAT_MODIFIER_ARM_TE_BIT</a></td>
<td>
<code>4096</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_TILED_HEADER_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=75">FORMAT_MODIFIER_ARM_TILED_HEADER_BIT</a></td>
<td>
<code>8192</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_ARM_YUV_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=65">FORMAT_MODIFIER_ARM_YUV_BIT</a></td>
<td>
<code>16</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_GOOGLE_GOLDFISH_OPTIMAL">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=97">FORMAT_MODIFIER_GOOGLE_GOLDFISH_OPTIMAL</a></td>
<td>
<code>648518346341351425</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INTEL_CCS_BIT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=42">FORMAT_MODIFIER_INTEL_CCS_BIT</a></td>
<td>
<code>16777216</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INTEL_I915_X_TILED">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=43">FORMAT_MODIFIER_INTEL_I915_X_TILED</a></td>
<td>
<code>72057594037927937</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INTEL_I915_YF_TILED">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=45">FORMAT_MODIFIER_INTEL_I915_YF_TILED</a></td>
<td>
<code>72057594037927939</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INTEL_I915_YF_TILED_CCS">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=48">FORMAT_MODIFIER_INTEL_I915_YF_TILED_CCS</a></td>
<td>
<code>72057594054705155</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INTEL_I915_Y_TILED">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=44">FORMAT_MODIFIER_INTEL_I915_Y_TILED</a></td>
<td>
<code>72057594037927938</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INTEL_I915_Y_TILED_CCS">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=47">FORMAT_MODIFIER_INTEL_I915_Y_TILED_CCS</a></td>
<td>
<code>72057594054705154</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_INVALID">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=31">FORMAT_MODIFIER_INVALID</a></td>
<td>
<code><a class='link' href='#FORMAT_MODIFIER_VALUE_RESERVED'>FORMAT_MODIFIER_VALUE_RESERVED</a></code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_LINEAR">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=33">FORMAT_MODIFIER_LINEAR</a></td>
<td>
<code>0</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_NONE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=16">FORMAT_MODIFIER_NONE</a></td>
<td>
<code>0</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VALUE_RESERVED">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=29">FORMAT_MODIFIER_VALUE_RESERVED</a></td>
<td>
<code>72057594037927935</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_AMD">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=20">FORMAT_MODIFIER_VENDOR_AMD</a></td>
<td>
<code>144115188075855872</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_ARM">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=26">FORMAT_MODIFIER_VENDOR_ARM</a></td>
<td>
<code>576460752303423488</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_BROADCOM">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=25">FORMAT_MODIFIER_VENDOR_BROADCOM</a></td>
<td>
<code>504403158265495552</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_GOOGLE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=27">FORMAT_MODIFIER_VENDOR_GOOGLE</a></td>
<td>
<code>648518346341351424</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_INTEL">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=19">FORMAT_MODIFIER_VENDOR_INTEL</a></td>
<td>
<code>72057594037927936</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_NONE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=18">FORMAT_MODIFIER_VENDOR_NONE</a></td>
<td>
<code>0</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_NVIDIA">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=21">FORMAT_MODIFIER_VENDOR_NVIDIA</a></td>
<td>
<code>216172782113783808</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_QCOM">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=23">FORMAT_MODIFIER_VENDOR_QCOM</a></td>
<td>
<code>360287970189639680</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_SAMSUNG">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=22">FORMAT_MODIFIER_VENDOR_SAMSUNG</a></td>
<td>
<code>288230376151711744</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="FORMAT_MODIFIER_VENDOR_VIVANTE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/format_modifier.fidl;l=24">FORMAT_MODIFIER_VENDOR_VIVANTE</a></td>
<td>
<code>432345564227567616</code>
</td>
<td><code>uint64</code></td>
<td></td>
</tr>
<tr id="MAX_COUNT_BUFFER_COLLECTION_CONSTRAINTS_IMAGE_FORMAT_CONSTRAINTS">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=8">MAX_COUNT_BUFFER_COLLECTION_CONSTRAINTS_IMAGE_FORMAT_CONSTRAINTS</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="MAX_COUNT_BUFFER_COLLECTION_INFO_BUFFERS">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=11">MAX_COUNT_BUFFER_COLLECTION_INFO_BUFFERS</a></td>
<td>
<code>64</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="MAX_COUNT_BUFFER_MEMORY_CONSTRAINTS_HEAP_PERMITTED">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=9">MAX_COUNT_BUFFER_MEMORY_CONSTRAINTS_HEAP_PERMITTED</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="MAX_COUNT_DUPLICATES">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/collection.fidl;l=8">MAX_COUNT_DUPLICATES</a></td>
<td>
<code>64</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="MAX_COUNT_IMAGE_FORMAT_CONSTRAINTS_COLOR_SPACES">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/constraints.fidl;l=10">MAX_COUNT_IMAGE_FORMAT_CONSTRAINTS_COLOR_SPACES</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="MAX_HEAPS_COUNT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=254">MAX_HEAPS_COUNT</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="MAX_RANGES_COUNT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/secure_mem.fidl;l=255">MAX_RANGES_COUNT</a></td>
<td>
<code>128</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_INDEX_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=64">VULKAN_BUFFER_USAGE_INDEX_BUFFER</a></td>
<td>
<code>4194304</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_INDIRECT_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=66">VULKAN_BUFFER_USAGE_INDIRECT_BUFFER</a></td>
<td>
<code>16777216</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_STORAGE_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=63">VULKAN_BUFFER_USAGE_STORAGE_BUFFER</a></td>
<td>
<code>2097152</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_STORAGE_TEXEL_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=61">VULKAN_BUFFER_USAGE_STORAGE_TEXEL_BUFFER</a></td>
<td>
<code>524288</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_TRANSFER_DST">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=59">VULKAN_BUFFER_USAGE_TRANSFER_DST</a></td>
<td>
<code>131072</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_TRANSFER_SRC">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=58">VULKAN_BUFFER_USAGE_TRANSFER_SRC</a></td>
<td>
<code>65536</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_UNIFORM_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=62">VULKAN_BUFFER_USAGE_UNIFORM_BUFFER</a></td>
<td>
<code>1048576</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=60">VULKAN_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER</a></td>
<td>
<code>262144</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_BUFFER_USAGE_VERTEX_BUFFER">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=65">VULKAN_BUFFER_USAGE_VERTEX_BUFFER</a></td>
<td>
<code>8388608</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_COLOR_ATTACHMENT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=41">VULKAN_IMAGE_USAGE_COLOR_ATTACHMENT</a></td>
<td>
<code>16</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_INPUT_ATTACHMENT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=44">VULKAN_IMAGE_USAGE_INPUT_ATTACHMENT</a></td>
<td>
<code>128</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_SAMPLED">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=39">VULKAN_IMAGE_USAGE_SAMPLED</a></td>
<td>
<code>4</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_STENCIL_ATTACHMENT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=42">VULKAN_IMAGE_USAGE_STENCIL_ATTACHMENT</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_STORAGE">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=40">VULKAN_IMAGE_USAGE_STORAGE</a></td>
<td>
<code>8</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_TRANSFER_DST">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=38">VULKAN_IMAGE_USAGE_TRANSFER_DST</a></td>
<td>
<code>2</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_TRANSFER_SRC">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=37">VULKAN_IMAGE_USAGE_TRANSFER_SRC</a></td>
<td>
<code>1</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="VULKAN_IMAGE_USAGE_TRANSIENT_ATTACHMENT">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=43">VULKAN_IMAGE_USAGE_TRANSIENT_ATTACHMENT</a></td>
<td>
<code>64</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="cpuUsageRead">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=28">cpuUsageRead</a></td>
<td>
<code>1</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="cpuUsageReadOften">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=29">cpuUsageReadOften</a></td>
<td>
<code>2</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="cpuUsageWrite">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=30">cpuUsageWrite</a></td>
<td>
<code>4</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="cpuUsageWriteOften">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=31">cpuUsageWriteOften</a></td>
<td>
<code>8</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="displayUsageCursor">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=70">displayUsageCursor</a></td>
<td>
<code>2</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="displayUsageLayer">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=69">displayUsageLayer</a></td>
<td>
<code>1</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="noneUsage">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=24">noneUsage</a></td>
<td>
<code>1</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="videoUsageCapture">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=79">videoUsageCapture</a></td>
<td>
<code>8</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="videoUsageDecryptorOutput">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=92">videoUsageDecryptorOutput</a></td>
<td>
<code>16</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="videoUsageHwDecoder">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=74">videoUsageHwDecoder</a></td>
<td>
<code>1</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="videoUsageHwDecoderInternal">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=96">videoUsageHwDecoderInternal</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="videoUsageHwEncoder">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=75">videoUsageHwEncoder</a></td>
<td>
<code>2</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="videoUsageHwProtected">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=78">videoUsageHwProtected</a></td>
<td>
<code>4</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageColorAttachment">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=51">vulkanUsageColorAttachment</a></td>
<td>
<code>16</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageInputAttachment">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=54">vulkanUsageInputAttachment</a></td>
<td>
<code>128</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageSampled">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=49">vulkanUsageSampled</a></td>
<td>
<code>4</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageStencilAttachment">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=52">vulkanUsageStencilAttachment</a></td>
<td>
<code>32</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageStorage">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=50">vulkanUsageStorage</a></td>
<td>
<code>8</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageTransferDst">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=48">vulkanUsageTransferDst</a></td>
<td>
<code>2</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageTransferSrc">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=47">vulkanUsageTransferSrc</a></td>
<td>
<code>1</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
<tr id="vulkanUsageTransientAttachment">
<td><a href="https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.sysmem/usages.fidl;l=53">vulkanUsageTransientAttachment</a></td>
<td>
<code>64</code>
</td>
<td><code>uint32</code></td>
<td></td>
</tr>
</table>