In depth understanding of camera 8 (Qualcomm framework)


Lifelong learning with you, this is Android programmer

Classic good articles are recommended. By reading this article, you will gain the following knowledge points:

1、 Overview
2、 Core module analysis
Three. Module initialization
4、 Processing UMD CSL requests

Camera driver layer – detailed explanation of Qualcomm KMD framework

1、 Overview

Taking advantage of the extensibility of v4l2, Qualcomm has implemented its own KMD framework in the camera driver. The framework creates device nodes in the system through the v4l2 standard method, directly exposes the control interface to UMD CSL for access, and mainly defines a series of core modules, including CRM (camera request manager), It is used to manage the creation and destruction of the session / link of the whole KMD and the flow of requests between sub devices. The module creates a video0 device node to expose key interfaces to UMD. In addition, it also includes a sync module, which is mainly responsible for data synchronization and transmission between UMD / KMD, and creates a Video1 device node to expose interfaces to UMD for access. In addition, In order to more finely control a series of hardware image processing modules, including ISP / IPE / sensor and other hardware modules, Qualcomm also created device nodes for their sub modules, and then exposed the control interface for UMD access.
The main contents are as follows:

  • cam_ Core /: the implementation of KMD core functions is put here, mainly including some standard methods such as creation / registration / destruction of subdev, node and context.
  • cam_ req_ Mgr /: the concrete implementation of CRM, which is used to create v4l2_ Device is used to manage all sub devices, generate video device nodes, and expose control interfaces to UMD, mainly including session / link behavior management and request synchronization and distribution. In addition, media is also created_ Device, which is used to expose the enumeration interface to UMD to poll and find the child devices of the whole KMD.
  • cam_ Sync /: this part mainly implements the business logic related to maintaining the synchronization with UMD image data. Due to the particularity of this module, Qualcomm directly creates a separate video device node for it, exposing some control interfaces for synchronization.
  • cam_ Utils /: implementation of some common methods, including debug method set, etc
  • cam_ SMMU /: Qualcomm has implemented a set of SMMU APIs for KMD
  • cam_ Lrme /: Driver implementation of low resolution motion estimation module
  • cam_ FD /: driver for face recognition
  • cam_ ISP /: driver for ISP
  • cam_ JPEG /: encoder, which can complete JPEG coding through the driver
  • cam_ CDM /: camera data mover, the driver implementation of data mover, is mainly used to parse the command information transmitted from CSL, including register setting and image data processing.
  • cam_ CPAs /: This module is mainly used for CSL to obtain camera platform driver information, IPE / BPS power control, etc
  • cam_ ICP /: image control processor, image processing controller driver implementation
  • cam_ sensor_ Module /: a series of hardware modules of sensor
    • cam_ Actuator /: driving realization of focusing motor
    • cam_ CCI /: it implements the CCI interface for communication, including the implementation of I2C and GPIO
    • cam_ Csiphy: physical layer driver based on Mipi CSI interface, which is used to transmit image data
    • cam_ sensor_ IO: using cam_ CCI, which upward implements the IO interface of the control sensor
    • cam_ Sensor: Driver implementation of sensor
    • cam_ sensor_ Util: implementation of public methods related to sensor
    • cam_ EEPROM: Driver implementation of EEPROM device
    • cam_ OIS: drive implementation of optical anti shake equipment
    • cam_ Flash: Driver implementation of flash device

2、 Core module analysis

As mentioned earlier, the whole framework is mainly composed of three parts, CRM / camera sync and sub modules. Next, let’s take the following figure as an example to briefly explain their relationship:

In depth understanding of camera 8 (Qualcomm framework)

Programmer Android to network

During system initialization, a v4l2 database will be created inside CRM_ The device structure is used to manage all sub devices. At the same time, each sub device will create its own v4l2 when registering_ Subdev is mounted to the v4l2_ Device. In addition, CRM will create a video0 device node to provide key interfaces to CSL for access, and each sub device will also generate its own v4l2-sbudev device node in the system to provide interfaces to CSL for more refined control. During initialization, cam sync also creates a v4l2_ Device and generates a Video1 node for CSL to control. This framework mainly focuses on these three parts. CRM is used to manage the creation of session / link and control the flow of request in each sub device. The sub devices are controlled by CSL for configuration and image processing. Once the image processing is completed, the results will be sent to cam sync module and uploaded to CSL.

1. CRM(Camera Request Manager)

This module is essentially a software module, which mainly does the following things:

  • Receive session / link / request requests from CSL and maintain their status in the kernel.
  • Synchronize each request status between sub modules of different pipeline delay and send it to each sub device as needed.
  • Responsible for uploading to CSL in case of error.
  • Responsible for flush operation for real-time sub modules.

The request for session / link / request is to expose the interface to the CSL through the previously created video device node. Once the command is received, it will be processed. The commands mainly include the following:

  • CAM_ REQ_ MGR_ CREATE_ SESSION/CAM_ REQ_ MGR_ DESTROY_ Session: respectively indicates the creation and destruction of a session, which maintains a one-to-one correspondence with camx-chi.
  • CAM_ REQ_ MGR_ LINK/CAM_ REQ_ MGR_ Unlink: indicates the creation and destruction of links respectively. Each session can contain multiple links, and each link is connected to the sub equipment required in the image acquisition process. CRM also manages the request synchronization and distribution through this link.
  • CAM_ REQ_ MGR_ SCHED_ Req: once CSL starts issuing a request, it can inform KMD through this command. In KMD, CRM will store the request in the link_ In the Q array, when the sub device informs that it is ready to process the request, it informs the sub device to configure and process the request.
  • CAM_ REQ_ MGR_ ALLOC_ BUF/CAM_ REQ_ MGR_ RELEASE_ BUF: application and release of image buffer. Cam is used in CRM_ mem_ Table structure to manage the applied buffer.

Once CRM receives the request from CSL, it will process it internally, and a series of business processes will be completed through the following structures:

First, during initialization, a cam will be created_ req_ mgr_ device。
The structure has the following main members:

  • Video: stores the corresponding video_ device。
  • v4l2_ Dev: saves v4l2 created during initialization_ device。
  • subdev_ nodes_ Created: Flag subordinate to v4l2_ Whether the child devices of device have successfully created the device node.
  • cam_ The eventq: v4l2 file describes the structure in which the event event queue is maintained.

Then I will create a cam_ req_ mgr_ core_ Device, the structure is relatively simple and is mainly used to maintain a session linked list. After the CSL issues the action of creating a session, the created session will be put into the scale and passed through CRM_ Lock keeps the synchronization in business processing.

A session can contain many links, including the variable num_ Links stores the number of links, the array links stores all links, and the entry variable can be embedded into cam as the entity of the current session_ req_ mgr_ core_ The session linked list in device is managed uniformly.

Issue cam in CSL_ REQ_ MGR_ When using the link command, cam will be created_ req_ mgr_ core_ link。
The structure is complex. Next, we mainly introduce the following main variables:

  • link_ HDL: as the handle of this link, it is different from other links.
  • num_ Devs: indicates how many sub devices are connected to this link.
  • max_ Delay: indicates the maximum pipeline delay value of all sub devices on the link.
  • l_ Dev: stores all sub devices belonging to the link. Subsequent control of sub devices is carried out through this array.
  • Req: this member is mainly used to manage distributed requests.
  • State: indicates the status of the link, and the link status mainly includes cam_ CRM_ LINK_ STATE_ AVAILABLE/CAM_ CRM_ LINK_ STATE_ IDLE/CAM_ CRM_ LINK_ STATE_ READY/CAM_ CRM_ LINK_ STATE_ Err several states.

After creating the link, it will be stored in a storage cam_ req_ mgr_ core_ Global variable g of link_ Links for unified management.

And instant cam_ REQ_ MGR_ SCHED_ The req command will be parsed internally and stored in cam_ req_ mgr_ core_ Cam in link_ req_ mgr_ req_ Wait for subsequent flow in data.
Where in_ The Q variable is mainly used to store request, while L_ TBL is used to record the relevant information of pipeline delay, and apply_ The data array is used to store all the request information waiting to be processed.

2. Cam Sync

This module is essentially a software module used to keep the synchronization with UMD image data. It mainly uses the event mechanism of v4l2 framework to wait for events by CSL. Once the data processing is completed, the module can send events to the upper layer, and then notify CSL to take out the data for the next processing, including several main IOCTL commands:

  • CAM_ SYNC_ Create: once the CSL part needs to create an entity for synchronization, this command will be issued. In cam sync, the incoming information will be stored in the internal sync_ table_ Row array, and the generated sync_ Obj is passed into the upper layer.
  • CAM_ SYNC_ Destroy: destroy the sync entity used for synchronization.
  • CAM_ SYNC_ REGISTER_ Payload: use this command to register some synchronous callback methods in cam sync, so that when the data processing is completed, cam sync can be used by the previously created sync_ Obj to find the corresponding callback method, and then call the callback method for subsequent processing.
  • CAM_ SYNC_ DEREGISTER_ Payload: release the information of the previously registered synchronization entity, including its callback method.
  • CAM_ SYNC_ Signal: this command is mainly used to notify cam sync for subsequent processing after the software node in camx-chi processes the data.

It includes several important structures. First, sync will be created during initialization_ The main variables of the device structure are as follows:

  • Vdev: created video_ device。
  • v4l2_ Dev: created v4l2_ Device.
  • sync_ Used to store Sync: table_ table_ Row.
  • cam_ sync_ Eventq: v4l2 device descriptor structure, in which event event queue is maintained.

The most important one is sync_ Sync stored in table_ table_ Row structure, which represents the whole corresponding to the sync object in CSL. The meanings of the more important variables are as follows:

  • sync_ ID: the unique ID of the sync object, which is synchronized with the CSL.
  • State: represents the state of the current sync object.
  • user_ payload_ List: stores the payload from UMD corresponding to the sync object. The payload is not used in KMD, but only stored in KMD. Once the current sync object is triggered, it will be directly transferred to UMD again.

Three. Module initialization

At the initial stage of system startup, each module in the whole camera driver starts to load. Next, we will introduce it in turn:

The first is the initialization of CRM. According to the standard method of Linux driver module, you will go to module_ The probe method in the drive structure declared by init macro, here is cam_ req_ mgr_ Probe method, which mainly does the following things:

  • Call cam_ v4l2_ device_ Setup method to create and register v4l2 for managing all sub devices with the system_ device。
  • Call cam_ media_ device_ Setup method to create and register media with the system_ Device, and a media device node is created for CSL to enumerate all devices in KMD.
  • Call cam_ video_ device_ Setup method to create a video_ Device and set v4l2_ Device is embedded in the structure. Then, using the standard video registration method, a video0 device node is created, where G_ cam_ ioctl_ The OPS method set is used as an extension method of video0. Many operations related to session / link / request issued by CSL are distributed through this method set. Finally, video0 media_ Function assignment in entity_ VNODE_ DEVICE_ Type, so that CSL can judge that this node is CRM through this function.
  • Call cam_ req_ mgr_ util_ Init method, where a cam is initialized_ req_ mgr_ util_ hdl_ TBL, there is a handle array in this structure, and each handle is mainly used to store the relevant information of session, link and each sub device. Later, in the whole process of image acquisition, it is through this structure to find the corresponding operation entity and take corresponding actions.
  • Call cam_ req_ mgr_ core_ device_ Init method, in which a cam is created and initialized_ req_ mgr_ core_ Device structure as global variable G_ crm_ core_ Dev exists in the whole framework, and this structure mainly contains the session used to store the created session_ Head linked list and CRM for protecting session critical resources_ lock。

Secondly, the initialization of cam sync. The whole process will eventually go to the probe method in the drive structure. Here is cam_ sync_ Probe method, which mainly does the following things:

  • Create sync_ Dev structure, in which a sync_ table_ Row array to maintain all sync objects.
  • Call cam_ sync_ media_ controller_ Init method for creating media_ Deivce device and create a media device node to provide CSL with the ability to enumerate child devices.
  • Call v4l2_ device_ Register method, create and register a v4l2 as the system_ Device struct, where the set of methods used for IOCTL is directed to g_ cam_ sync_ ioctl_ Ops, once CSL needs to create / register sync objects, it will finally go to this method to realize the corresponding functions.
  • Call video_ register_ The device method generates a Video1 device node and exposes the control interface to the CSL.
  • Call cam_ sync_ init_ Entity method, and the Meida in Video1_ Assignment of function field in entity_ SYNC_ DEVICE_ Type, so that the module can be listed through the corresponding media node in UMD.

The above two modules have independent video device nodes, but for the sub devices, they represent the corresponding hardware devices and need to be embedded into the whole framework to operate normally, so Qualcomm abstracts them into v4l2_ Subdev for management. Here we mainly introduce two representative sub modules, ISP and sensor.

First, let’s take a look at the initialization phase of the ISP, in its corresponding probe method cam_ isp_ dev_ The probe does the following:

  • Call cam_ subdev_ Probe method, in which a v4l2 is registered_ Subdev and mount it to v4l2 in CRM_ On device, a node is also created and stored in v4l2_ In the token in subdev, it is convenient to read later. In addition, the method set is assigned cam_ subdev_ Ops, and finally, create the v4l2_ Media inside subdev_ Entity and assign its function field cam_ IFE_ DEVICE_ Type, which is also convenient to distinguish that the current node represents the ISP module when enumerating sub devices.
  • Call cam_ isp_ hw_ mgr_ Init method, which is used to initialize the hardware module in the ISP.
  • Call cam_ isp_ context_ Init method, which initializes the node, creates a certain number of contexts inside the node for later state maintenance, and configures state machines and sub state machines for each context to manage the whole ISP module.

Next, let’s take a look at the initialization of the sensor module, in its corresponding probe method cam_ sensor_ driver_ i2c_ Probe mainly does the following things:

  • Call cam_ sensor_ parse_ The DT method obtains the hardware information defined in the DTS.
  • Call cam_ sensor_ init_ subdev_ Params method, in which v4l2 is created_ Subdev, and then mount it to v4l2 in CRM_ Device, and the sensor’s private method set cam_ sensor_ internal_ Ops assigned to v4l2_ The OPS in the subdev structure, so that once the corresponding sub device node is operated, it will eventually go to the method set, and some operations on the sensor can be put into it for processing. The v4l2 that will eventually be created_ Media in subdev_ Functon in entity is assigned as cam_ SENSOR_ DEVICE_ Type to facilitate CSL to enumerate sensor devices.

By combing the initialization codes of the above two sub devices, it is not difficult to find that the device node has not been created. At which stage does the node creation action take place? In order to solve this problem, we have to introduce two macro definitions of Linux, one is module_ Init, the other is late_ Initcall, both of which are used to declare the initialization function, but the execution time has a sequence, not late_ Initcall is generally used in all modules_ The methods defined by init will not be run until they are run, and the creation of nodes for all child devices is completed here. In this method, the following work is mainly done:

  • Call cam_ dev_ mgr_ create_ subdev_ Nodes method, in which the v4l2 standard method v4l2 will be called_ device_ register_ subdev_ Nodes to uniformly create and mount in CRM v4l2_ The child device node under device.

So far, the whole KMD framework has been initialized, and now it will quietly wait for the CSL to issue a request.

4、 Processing UMD CSL requests

The initialization of the whole KMD is completed when the Linux kernel is started, which is earlier than the initialization of the whole camx-chi framework. Therefore, when camx-chi is initialized, all resource nodes of the KMD framework are ready. Next, we will start with the initialization of camx-chi and describe in detail the process of the whole KMD processing requests from CSL.

1. Obtain module resources

When camx-chi is initialized, it does not know the status of the kernel driver, so it is necessary to open all media device nodes to enumerate and query each driver module.

First, open Media0 according to cam_ VNODE_ DEVICE_ Type enumerates and finds the CRM module in the KMD framework, and calls the standard open method to open the device. This action will eventually call cam_ req_ mgr_ Open method, which mainly does the following work:

  • Call v4l2_ fh_ Open method to open v4l2 file.
  • Call cam_ mem_ mgr_ Init method initializes the memory management module to prepare for the subsequent application and release of the buffer.
  • Update CRM status to cam_ MEM_ MGR_ INITIALIZED。

After opening video0, another thread will be started to listen for video events, so as to establish two-way communication with the underlying layer. Before that, the events to be monitored by CSL need to be sent to the driver layer through IOCTL method, including the following events:

  • V4L_ EVENT_ CAM_ REQ_ MGR_ SOF/V4L_ EVENT_ CAM_ REQ_ MGR_ SOF_ BOOT_ TS: once an sof event is generated at the bottom, it will be sent to the CSL.
  • V4L_ EVENT_ CAM_ REQ_ MGR_ Error: once an error occurs at the bottom, the event will be thrown upward.

Once the CSL has successfully obtained the CRM module information, it will start to enumerate and find each sub module. First, it will open the sensor sub device, obtain the hardware information and store it in the CSL, and then successively obtain other hardware sub modules such as ife / IPE, obtain their own information and store it in the CSL to prepare for the subsequent data flow.

After the above actions are completed, you can start to query the cam sync module. The basic process is roughly the same as that of CRM:

  • Call the open method to open Video1, which will eventually call the cam of the kernel part_ sync_ Open method, in which v4l2 is called_ fh_ Open method to open the v4l2 file.
  • Call IOCTL method to subscribe to cam_ SYNC_ V4L_ EVENT_ ID_ CB_ Listening to trig event. For this event, cam sync will be triggered to send the event to the upper layer after the data processing of the sub module is completed.

2. Open session

Well, here, the entire CAMX initialization process has completed the underlying request. Once the user opens the camera application, after layers of calls, he will finally open the session, and then call the corresponding IOCTL method of video0 to transfer it to cam_ REQ_ MGR_ CREATE_ The session command starts the operation of opening session in the driver layer, and in the driver part, it will call cam in CRM_ req_ mgr_ create_ Session method, in which a handle representing the session will be created and stored in the global static variable HDL_ TBL. Next, the link in the session will be initialized. The session manages two link arrays, one is the links used for initialization_ Init array, an array of links used after running. Here, all links will be initialized first_ When using the link in init, an idle link will be taken from the array and put into links for management.

3. Turn on the device

After opening the session, with the creation of pipeline, CAMX will issue cam by calling the IOCTL method of the corresponding node in CSL_ ACQUIRE_ Dev command to open the underlying hardware devices in turn. Here, we still take ISP as an example:

  • Once the CSL calls the IOCTL of the ISP device node and issues the cam_ ACQUIRE_ Dev command, and will be called layer by layer until__ cam_ node_ handle_ acquire_ Dev method, in which a context is first obtained from the queue storing the idle context in the node corresponding to the ISP.
  • Then, cam is called_ context_ handle_ acquire_ Dev method to call acquire in the state machine method set for the context obtained before_ Dev method to open the ISP device, and in this method, cam is called_ create_ device_ HDL method, which stores the current session handle and ISP operation method set into HDL_ In TBL, CRM will then operate the ISP module through this method set. The current ISP context status will then be updated to cam_ CTX_ Requested, and active for managing requests is initialized_ req_ list/wati_ req_ list/pending_ req_ list/pending_ req_ list/free_ req_ List linked list, and req will be initialized_ Lists are attached to the free linked list.

In addition to ISP, different sub devices will be opened according to different image acquisition requirements. The basic process is almost the same. Cam is distributed_ ACQUIRE_ The dev command is completed, so we won’t repeat it here.

4. Create link

After opening all the sub devices, they need to be linked to form a topology to facilitate the management of each sub module. This action is to issue cam by calling IOCTL corresponding to CRM_ REQ_ MGR_ Link command. This action will be called layer by layer until cam in CRM is called_ req_ mgr_ Link method. Next, let’s introduce the main actions of this method:

  • Call__ cam_ req_ mgr_ reserve_ Link method, in which links in the current session will be retrieved first_ Take a free link from the init array, store it in the links array, and initialize the in used to manage all requests_ Q queue.
  • Call cam_ create_ device_ HDL, create the handle corresponding to the link and store it in HDL_ TBL.
  • Call__ cam_ req_ mgr_ create_ The subdevs method is initialized to store all the subdevices in the current link.
  • Call__ cam_ req_ mgr_ setup_ link_ Info method, which will first call the get of all child devices in the link_ dev_ Info method to obtain device information, and then call HDL in turn_ The link in TBL is the setup of all sub devices on this link_ Link method to connect the sub equipment. At the same time, some callback methods of CRM are injected into the sub equipment in this way, so that it has the ability to notify CRM.
  • Update the link status to cam_ CRM_ LINK_ STATE_ Ready, and a work queue is created for asynchronous processing of operations.

5. Start data flow

Once the entire link is created, the data flow can be started. This action is completed by CSL controlling each sub device. Here, take ISP as an example:

Since there are already open ISP file handles in the process of CAMX initialization, all users issue cam by calling the iotcl method_ START_ The DEV command tells the underlying ISP module to start the data flow transmission. The command first goes to node, then sends it to context through node, and then calls the start_ corresponding to the state machine of the current context. Dev method, in which the current context status will be updated to cam first_ CTX_ Activated, and then start the data flow processing by operating the underlying hardware management module.

In addition to ISP, sensor / flush and other modules also need to start data flow to prepare for subsequent request issuance.

6. Issue request

Once the whole data processing process is started, the request can be received, and the action is still completed through CRM. Call its IOCTL method and pass it into CRM_ WORKQ_ TASK_ SCHED_ Req command, the action will eventually reach cam in the kernel CRM_ req_ mgr_ schedule_ Request method, which encapsulates the task into a task and sends it to the work queue for asynchronous processing, and finally calls its callback method cam in the work queue_ req_ mgr_ process_ sched_ Req, the main work of this method is as follows:

  • Take out the dependent link of the request, and put in it_ Q, find an idle slot, and take the slot as the entity of the request in the kernel.
  • Update the status of the slot to CRM_ SLOT_ STATUS_ REQ_ Add, and open in link_ req_ CNT count plus 1.

It is not difficult to see from the above combing that the operation of issuing requests is not complex. There is no actual action of issuing requests to sub devices, so naturally there will be a question. Without the action of issuing requests, how does CRM drive the flow of the whole request? So let’s further introduce the whole request flow mechanism.

7. Sub equipment processing data

After CSL sends a request to KMD, it will enter the DRQ for flow. Through the previous study of CAMX, you must be familiar with the operation mechanism of the whole DRQ. Each node of the DRQ will have a certain dependency. Once a node meets the dependency, it will call its processrequest to start the request processing, This action will package the image data and configuration information, and issue cam by calling IOCTL method_ CONFIG_ Dev writes the configuration to the KMD child device by sending it to the specific child device node. Once the child device receives the request, it will call the config corresponding to the state machine of the current context_ Dev method. Next, let’s introduce the actions in it:

  • Put the configuration information including image data into the hardware management module, but do not process it at this time and wait for the processing instruction.
  • Encapsulate the request information and call the previous setup_ Link the add in the callback method set passed in_ The req method notifies CRM. In CRM, a series of judgments will be made first. If the conditions are met, the slot status corresponding to the request will be updated to CRM_ REQ_ STATE_ Ready and store the request in the pending queue.

According to the above analysis, it is found that there is no actual hardware configuration or processing in this process. At this time, it is necessary to wait for the sof event to drive the next operation. The ISP notifies CRM of the sof event. The specific process is as follows:

  • The epoch interrupt is generated and the callback method is triggered__ cam_ isp_ ctx_ notify_ sof_ in_ activated_ State, in which the event will be encapsulated, and notify will be sent by calling the callback method passed in CRM_ Trigger sends the event to CRM.
  • Once CRM receives the sof event, it will find the corresponding request that meets the requirements and call__ cam_ req_ mgr_ process_ The req method notifies the corresponding sub devices to configure.
  • Finally, ISP will send this sof event to UMD through v4l2 event mechanism and notify CSL.

8. Data operation completed

After each node in CAMX completes the operation of sending a request, it will wait for the data processing to complete. Once completed, it will trigger buf_ Done interrupts and informs the context that cam will eventually be called_ sync_ Signal method to notify cam sync, and cam sync will be called through sub devices in cam sync_ sync_ Sync passed in during signal_ ID in sync_ table_ Row finds the corresponding sync object, and finally passes the processed event to UMD CSL through the event mechanism for subsequent processing.

After the processing of the last node is completed, the processing of this request will be declared complete.

The camera driver used in the previous qcamera & mm camera architecture is relatively simple, which mainly undertakes the tasks of hardware power on and off and reading and writing registers, and the control direction is from top to bottom, and the control logic is in the charge of UMD. However, with the development of the times, the camera hardware modules become more and more complex, so the driver layer used to directly control the hardware also needs to undertake more complex control tasks. Through the above analysis, we can see that Qualcomm has redesigned a set of excellent KMD framework and added more complex control logic to achieve the purpose of fine control of the underlying hardware modules, After that, it is very important to send the horizontal control request to the KMD in the bottom CRM sub framework. In this way, it is necessary to uniformly control the UMD in the bottom CRM sub framework, so as to reduce the difficulty of controlling the UMD in the bottom CRM sub framework.

So far, this article has ended. Reprint the articles on the network. Xiaobian feels very excellent. You are welcome to click to read the original text and support the original author. If there is infringement, please contact Xiaobian to delete it. Your suggestions and corrections are welcome. At the same time, we look forward to your attention. Thank you for reading. Thank you!

Recommended Today

Vue2 technology finishing 3 – Advanced chapter – update completed

3. Advanced chapter preface Links to basic chapters: Link to component development: 3.1. Custom events of components 3.1.1. Binding custom events There are two implementation methods here: one is to use v-on with vuecomponent$ Emit implementation [PS: this method is a little similar to passing from child to parent]; The other is to use ref […]