(源码)基于libcamera的相机控制与图像处理系统.zip

# Mojom Interface Definition Language (IDL) This document is a subset of the [Mojo documentation](/mojo/README.md). [TOC] ## Overview Mojom is the IDL for Mojo interfaces. Given a `.mojom` file, the [bindings generator](https://cs.chromium.org/chromium/src/mojo/public/tools/bindings/) can output bindings for any supported language: **C++**, **JavaScript**, or **Java**. For a trivial example consider the following hypothetical Mojom file we write to `//services/widget/public/mojom/frobinator.mojom`: ``` module widget.mojom; interface Frobinator { Frobinate(); }; ``` This defines a single [interface](#Interfaces) named `Frobinator` in a [module](#Modules) named `widget.mojom` (and thus fully qualified in Mojom as `widget.mojom.Frobinator`.) Note that many interfaces and/or other types of definitions (structs, enums, *etc.*) may be included in a single Mojom file. If we add a corresponding GN target to `//services/widget/public/mojom/BUILD.gn`: ``` import("mojo/public/tools/bindings/mojom.gni") mojom("mojom") { sources = [ "frobinator.mojom", ] } ``` and then build this target: ``` ninja -C out/r services/widget/public/mojom ``` we'll find several generated sources in our output directory: ``` out/r/gen/services/widget/public/mojom/frobinator.mojom.cc out/r/gen/services/widget/public/mojom/frobinator.mojom.h out/r/gen/services/widget/public/mojom/frobinator.mojom-shared.h etc... ``` Each of these generated source modules includes a set of definitions representing the Mojom contents in C++. You can also build or depend on suffixed target names to get bindings for other languages. For example, ``` ninja -C out/r services/widget/public/mojom:mojom_js ninja -C out/r services/widget/public/mojom:mojom_java ``` would generate JavaScript and Java bindings respectively, in the same generated output directory. For more details regarding the generated outputs please see [documentation for individual target languages](#Generated-Code-For-Target-Languages). ## Mojom Syntax Mojom IDL allows developers to define **structs**, **unions**, **interfaces**, **constants**, and **enums**, all within the context of a **module**. These definitions are used to generate code in the supported target languages at build time. Mojom files may **import** other Mojom files in order to reference their definitions. ### Primitive Types Mojom supports a few basic data types which may be composed into structs or used for message parameters. | Type | Description |-------------------------------|-------------------------------------------------------| | `bool` | Boolean type (`true` or `false`.) | `int8`, `uint8` | Signed or unsigned 8-bit integer. | `int16`, `uint16` | Signed or unsigned 16-bit integer. | `int32`, `uint32` | Signed or unsigned 32-bit integer. | `int64`, `uint64` | Signed or unsigned 64-bit integer. | `float`, `double` | 32- or 64-bit floating point number. | `string` | UTF-8 encoded string. | `array<T>` | Array of any Mojom type *T*; for example, `array<uint8>` or `array<array<string>>`. | `array<T, N>` | Fixed-length array of any Mojom type *T*. The parameter *N* must be an integral constant. | `map<S, T>` | Associated array maping values of type *S* to values of type *T*. *S* may be a `string`, `enum`, or numeric type. | `handle` | Generic Mojo handle. May be any type of handle, including a wrapped native platform handle. | `handle<message_pipe>` | Generic message pipe handle. | `handle<shared_buffer>` | Shared buffer handle. | `handle<data_pipe_producer>` | Data pipe producer handle. | `handle<data_pipe_consumer>` | Data pipe consumer handle. | `handle<platform>` | A native platform/OS handle. | *`pending_remote<InterfaceType>`* | Any user-defined Mojom interface type. This is sugar for a strongly-typed message pipe handle which should eventually be used to make outgoing calls on the interface. | *`pending_receiver<InterfaceType>`* | A pending receiver for any user-defined Mojom interface type. This is sugar for a more strongly-typed message pipe handle which is expected to receive request messages and should therefore eventually be bound to an implementation of the interface. | *`pending_associated_remote<InterfaceType>`* | An associated interface handle. See [Associated Interfaces](#Associated-Interfaces) | *`pending_associated_receiver<InterfaceType>`* | A pending associated receiver. See [Associated Interfaces](#Associated-Interfaces) | *T*? | An optional (nullable) value. Primitive numeric types (integers, floats, booleans, and enums) are not nullable. All other types are nullable. ### Modules Every Mojom file may optionally specify a single **module** to which it belongs. This is used strictly for aggregating all defined symbols therein within a common Mojom namespace. The specific impact this has on generated bindings code varies for each target language. For example, if the following Mojom is used to generate bindings: ``` module business.stuff; interface MoneyGenerator { GenerateMoney(); }; ``` Generated C++ bindings will define a class interface `MoneyGenerator` in the `business::stuff` namespace, while Java bindings will define an interface `MoneyGenerator` in the `org.chromium.business.stuff` package. JavaScript bindings at this time are unaffected by module declarations. **NOTE:** By convention in the Chromium codebase, **all** Mojom files should declare a module name with at least (and preferably exactly) one top-level name as well as an inner `mojom` module suffix. *e.g.*, `chrome.mojom`, `business.mojom`, *etc.* This convention makes it easy to tell which symbols are generated by Mojom when reading non-Mojom code, and it also avoids namespace collisions in the fairly common scenario where you have a real C++ or Java `Foo` along with a corresponding Mojom `Foo` for its serialized representation. ### Imports If your Mojom references definitions from other Mojom files, you must **import** those files. Import syntax is as follows: ``` import "services/widget/public/mojom/frobinator.mojom"; ``` Import paths are always relative to the top-level directory. Note that circular imports are **not** supported. ### Structs Structs are defined using the **struct** keyword, and they provide a way to group related fields together: ``` cpp struct StringPair { string first; string second; }; ``` Struct fields may be comprised of any of the types listed above in the [Primitive Types](#Primitive-Types) section. Default values may be specified as long as they are constant: ``` cpp struct Request { int32 id = -1; string details; }; ``` What follows is a fairly comprehensive example using the supported field types: ``` cpp struct StringPair { string first; string second; }; enum AnEnum { YES, NO }; interface SampleInterface { DoStuff(); }; struct AllTheThings { // Note that these types can never be marked nullable! bool boolean_value; int8 signed_8bit_value = 42; uint8 unsigned_8bit_value; int16 signed_16bit_value; uint16 unsigned_16bit_value; int32 signed_32bit_value; uint32 unsigned_32bit_value; int64 signed_64bit_value; uint64 unsigned_64bit_value; float float_value_32bit; double float_value_64bit; AnEnum enum_value = AnEnum.YES; // Strings may be nullable. string? maybe_a_string_maybe_not; // Structs may contain other structs. These may also be nullable. StringPair some_strings; StringPair? maybe_some_more_strings; // In fact structs can also be nested, though in pr