class AllocatorGetVmoInfoRequest

Returns whether no field is set.

`vmo` is required to be set; ownership is transferred to the server

so in most cases a client will duplicate a handle and transfer the

duplicate via this field.

The GetVmoInfo call will fail with `NOT_FOUND` if this VMO isn't a

sysmem-provided VMO. Children of sysmem-provided VMOs don't count as

sysmem-provided VMOs.

Assuming this is a sysmem-provided VMO, the handle can be a sysmem

strong VMO handle or a sysmem weak VMO handle.

If this field is sysmem weak VMO handle, `close_weak_asap` will be

set in the response (not the only reason for close_weak_asap to be

set).

This field is required.

`vmo` is required to be set; ownership is transferred to the server

so in most cases a client will duplicate a handle and transfer the

duplicate via this field.

The GetVmoInfo call will fail with `NOT_FOUND` if this VMO isn't a

sysmem-provided VMO. Children of sysmem-provided VMOs don't count as

sysmem-provided VMOs.

Assuming this is a sysmem-provided VMO, the handle can be a sysmem

strong VMO handle or a sysmem weak VMO handle.

If this field is sysmem weak VMO handle, `close_weak_asap` will be

set in the response (not the only reason for close_weak_asap to be

set).

This field is required.

Iff set to true, a successful response will have weak_vmo set to a

sysmem weak VMO handle for the buffer, regardless of whether the vmo

handle in the request was weak or not.

Also, when `weak_vmo` is set in the response, `close_weak_asap` will

also be set in the response, whether `vmo` was sysmem strong or

sysmem weak (not the only reason for close_weak_asap to be set).

If set to true and `vmo` is a weak vmo and there aren't any

remaining strong vmo handles for the logical buffer (and the sysmem

server has had a chance to notice that), the request will fail with

`Error.NO_MORE_STRONG_VMO_HANDLES`.

This field is optional. The default is false.

Iff set to true, a successful response will have weak_vmo set to a

sysmem weak VMO handle for the buffer, regardless of whether the vmo

handle in the request was weak or not.

Also, when `weak_vmo` is set in the response, `close_weak_asap` will

also be set in the response, whether `vmo` was sysmem strong or

sysmem weak (not the only reason for close_weak_asap to be set).

If set to true and `vmo` is a weak vmo and there aren't any

remaining strong vmo handles for the logical buffer (and the sysmem

server has had a chance to notice that), the request will fail with

`Error.NO_MORE_STRONG_VMO_HANDLES`.

This field is optional. The default is false.

Iff set to true, a successful response will have

single_buffer_settings set to the SingleBufferSettings for the

buffer's buffer collection.

The fields in SingleBufferSettings can be thought of as similar in

nature to the information available from zx_object_get_info with

topic ZX_INFO_VMO, which doesn't require any rights on the VMO

handle to succeed. This information can be needed by the caller to

know how to correctly handle / use the VMO. Similarly, this call

doesn't require any particular rights in order to get

single_buffer_settings - just ZX_RIGHT_TRANSFER for the client's

message to send successfully, and of course the `vmo` field must be

a handle to a sysmem-provided VMO.

Clients should avoid manually checking whether

`single_buffer_settings` is consistent with the client's

BufferCollectionConstraints (or at least, shouldn't only rely on

that checking in the client). To have sysmem check, see

`constraints_to_check`.

This field is optional. The default is false.

Iff set to true, a successful response will have

single_buffer_settings set to the SingleBufferSettings for the

buffer's buffer collection.

The fields in SingleBufferSettings can be thought of as similar in

nature to the information available from zx_object_get_info with

topic ZX_INFO_VMO, which doesn't require any rights on the VMO

handle to succeed. This information can be needed by the caller to

know how to correctly handle / use the VMO. Similarly, this call

doesn't require any particular rights in order to get

single_buffer_settings - just ZX_RIGHT_TRANSFER for the client's

message to send successfully, and of course the `vmo` field must be

a handle to a sysmem-provided VMO.

Clients should avoid manually checking whether

`single_buffer_settings` is consistent with the client's

BufferCollectionConstraints (or at least, shouldn't only rely on

that checking in the client). To have sysmem check, see

`constraints_to_check`.

This field is optional. The default is false.

Iff set, `constraints_ok` will be set in the response indicating

whether the sent constraints are compatible with the parent buffer

collection as allocated.

Buffer counts are not checked for consistency, as there's no way for

sysmem to know whether the passed-in `vmo` was originally handed out

to the same logical participant that's now checking the vmo against

its constraints, and we also want to avoid adding things that might

lock sysmem into a static number of buffers per collection.

This can be thought of as checking `constraints_to_check` against

the `single_buffer_settings` (if that is/were requested), but sysmem

is free to check against additional info as well (such as a

hypothetical future sysmem3's buffer collection info, or modified

semantics for sysmem2 fields that this client hasn't opted into, or

similar). In other words, clients should let sysmem do this check,

regardless of whether the client also does some checking of its own.

This field is optional. If un-set, no constraints checking occurs.

Iff set, `constraints_ok` will be set in the response indicating

whether the sent constraints are compatible with the parent buffer

collection as allocated.

Buffer counts are not checked for consistency, as there's no way for

sysmem to know whether the passed-in `vmo` was originally handed out

to the same logical participant that's now checking the vmo against

its constraints, and we also want to avoid adding things that might

lock sysmem into a static number of buffers per collection.

This can be thought of as checking `constraints_to_check` against

the `single_buffer_settings` (if that is/were requested), but sysmem

is free to check against additional info as well (such as a

hypothetical future sysmem3's buffer collection info, or modified

semantics for sysmem2 fields that this client hasn't opted into, or

similar). In other words, clients should let sysmem do this check,

regardless of whether the client also does some checking of its own.

This field is optional. If un-set, no constraints checking occurs.

If set, `vmo_settings_match` will be set to indicate whether the

parent collection of `vmo` and `vmo_settings_to_check` have the same

SingleBufferSettings. This will be true if both are the same VMO,

will be true if both VMOs are from the same collection, and can also

be true if two VMOs from different collections have the same

SingleBufferSettings.

If set, `vmo_settings_match` will be set to indicate whether the

parent collection of `vmo` and `vmo_settings_to_check` have the same

SingleBufferSettings. This will be true if both are the same VMO,

will be true if both VMOs are from the same collection, and can also

be true if two VMOs from different collections have the same

SingleBufferSettings.

When vmo_settings_to_check is set to a VMO and

vmo_settings_to_check_ignore_size is set to true, the buffer size

is ignored when comparing the two buffer's settings. This can be

useful to set when checking video decoder input buffers.

When vmo_settings_to_check is set to a VMO and

vmo_settings_to_check_ignore_size is set to true, the buffer size

is ignored when comparing the two buffer's settings. This can be

useful to set when checking video decoder input buffers.