A method, system and medium for implementing an SPI ink screen screenshot function based on a Linux DRM framework

Abstract

The application relates to a method, system and medium for realizing an SPI ink screen screenshot function based on a Linux DRM framework, which comprises the following steps: reconstructing an SPI ink screen driver based on a DRM framework in a Linux kernel, and abstracting the SPI ink screen into a standard display device; managing a frame buffer through a GEM / DMA mechanism of the DRM framework, and acquiring UI frame data synthesized by an Android system; selectively executing a manual refreshing module or an automatic refreshing mode in response to user configuration or a system call, wherein in the manual refreshing mode, UI frame data is cached and sent in response to a user trigger instruction, and in the automatic refreshing mode, UI frame data is automatically sent at a preset time interval after frame data is detected to be updated; and the UI frame data is sent to the SPI ink screen through a reconstructed SPI communication protocol for display, so that system-level screenshot is realized. The application improves data transmission efficiency and overall system performance, and realizes efficient screenshot display of the SPI ink screen.

Description

Technical Field

[0001] This invention relates to the field of display technology, and in particular to a method, system, and medium for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework. Background Technology

[0002] E-paper displays, due to their bistable characteristics, can continue to display images even when power is off, offering the advantage of ultra-low power consumption. They are widely used in electronic tags, smart wearables, and e-readers. Traditional SPI interface e-paper driver implementations suffer from the following technical drawbacks: 1. Outdated software architecture, resulting in numerous memory copy operations: Existing solutions mostly employ traditional character device driver frameworks. User-space applications need to allocate a buffer first, copy image data from user space to kernel space using copy_from_user, and then send it to the hardware via the SPI driver. The entire process involves at least two memory copies, resulting in high CPU utilization and low data transfer efficiency in high-resolution scenarios (such as 1920x1080).

[0003] 2. Fixed data format, lacking flexibility: Traditional drivers typically only support fixed RGB565 or monochrome data formats, which cannot adapt to the diverse image formats of upper-layer applications (such as XRGB8888). This results in the application layer needing to perform additional format conversions, increasing system complexity and processing latency.

[0004] 3. The simple refresh mechanism is not suitable for the physical characteristics of e-ink screens: Traditional drivers often borrow from the MIPI DBI (Display Bus Interface) protocol, whose refresh mechanism is "instantaneous and continuous." Once the frame buffer is updated, the driver immediately sends the data to the panel via SPI. This mechanism is suitable for LCD screens with fast response times, but for e-ink screens with slow refresh rates (seconds) and lifespan sensitivity, frequent and uncontrolled refreshes will significantly reduce screen lifespan and cannot meet users' fine-grained needs for "manual control of refresh timing."

[0005] 4. Rigid communication protocols make timing control difficult: Existing solutions strictly adhere to the MIPI DBI protocol, using a fixed command format and hardware auto-select (CS). However, many commercial e-ink displays employ custom SPI frame formats (such as "control byte + 32-bit address + 16-bit length + data"), and have strict requirements on the chip select setup / hold time. Hardware auto-select struggles to meet these specific timing requirements, leading to unstable communication.

[0006] 5. The application is highly coupled and cannot implement the "screenshot" function: Due to the lack of a unified memory management and display framework, traditional drivers often require applications to actively "push" pattern files in a specific format, making it difficult to conveniently "capture" and display the current Android system's UI interface on the e-ink screen in real time and completely, resulting in a poor user experience. Summary of the Invention

[0007] This invention provides a method, system, and medium for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework, aiming to improve data transmission efficiency and overall system performance, and achieve efficient screenshot display of SPI e-ink screen.

[0008] This invention provides a method for implementing SPI e-screen screenshot functionality based on the Linux DRM framework, the method comprising the following steps: Step S10: Reconstruct the SPI e-ink screen driver based on the DRM framework in the Linux kernel, and abstract the SPI e-ink screen as a standard display device. Step S20: Manage the frame buffer through the GEM / DMA mechanism of the DRM framework and obtain the UI frame data synthesized by the Android system; Step S30: In response to user configuration or system call, selectively execute manual refresh module or automatic refresh mode. In manual refresh mode, the UI frame data is cached and sent in response to user trigger command. In automatic refresh mode, the UI frame data is automatically sent at preset time intervals after frame data update is detected. Step S40: The UI frame data is sent to the SPI e-screen for display via the reconstructed SPI communication protocol to achieve system-level screenshot.

[0009] A further technical solution of the present invention is that step S10 includes: Step S101: Based on the mipi-dbi driver foundation of the DRM framework, reconstruct the driver core of the SPI e-ink screen, add a private data structure for the e-ink screen, and reconstruct the SPI communication method and refresh mechanism.

[0010] A further technical solution of the present invention is that the step of adding a private data structure for the e-ink screen in step S101 includes: Define struct ink_display_priv, which includes a transmission mutex, a stop transmission flag, a frame address / command code, a dynamic SPI transmit buffer, a GPIO CS enable flag, a refresh mode flag, a refresh completion semaphore, and automatic refresh delay core parameters to achieve independent management of the ink screen's characteristics.

[0011] A further technical solution of the present invention is that the step of reconstructing the SPI communication mode in step S101 includes: The system adopts a custom SPI frame format for e-ink displays. Each transmission includes a control byte, a 32-bit address, a 16-bit length, and data. This format is encapsulated using the `ink_write_spi_command()` function. The `ink_spi_write_with_gpio_cs()` function is implemented to manually pull the CS pin low / high before and after data transmission, and a 5µs delay is added to meet setup / hold time requirements.

[0012] A further technical solution of the present invention is that the step of reconstructing the refresh mechanism in step S101 includes: The DRM framework pipeline functions are adapted specifically for e-ink screens, skipping the initialization / exit sequence of ordinary screens and retaining only power management; a refresh mode judgment is added to fb_dirty(), in which only the frame data is buffered and not transmitted in manual mode, and the e-ink screen-specific refresh function is called in automatic mode.

[0013] A further technical solution of the present invention is that step S30 includes: In the refresh function, the pixel data in the DRM frame buffer is swapped byte by byte, and the CPU byte order is converted to the LSB-first transmission format required by the e-ink screen to ensure that the displayed data is correct.

[0014] A further technical solution of the present invention is that the method further includes: To address the physical characteristics of SPI e-ink displays and the adaptation requirements of the DRM framework, the device tree was modified to remove redundant configurations and add dedicated parameters, enabling the device tree to recognize SPI e-ink displays and adapt to DRM drivers.

[0015] A further technical solution of the present invention is that step S40 includes: Step S401: Connect to the Android system layer DRM-HWC2 component to enable the function of directly taking screenshots of the system layer UI and pushing them to the SPI e-ink screen.

[0016] To achieve the above objectives, the present invention also proposes a system for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework. The system includes a memory, a processor, and a program for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework stored on the processor. When the processor runs the program for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework, it executes the steps of the method described above.

[0017] To achieve the above objectives, the present invention also proposes a computer-readable storage medium storing a program that implements SPI e-ink screen screenshot functionality based on the Linux DRM framework. When the program implements SPI e-ink screen screenshot functionality based on the Linux DRM framework is run by a processor, the steps of the method described above are executed.

[0018] The beneficial effects of the method, system, and medium for implementing SPI e-ink screen screenshot function based on the Linux DRM framework of this invention are: 1. Unified Memory Management and Zero-Copy: Utilizing the DRM / GEM / DMA framework, the frame buffer is uniformly managed by the kernel, allowing user space and drivers to directly access the same physical memory, achieving true zero-copy. Compared to traditional drivers that perform at least two memory copies, this significantly reduces CPU load and memory bandwidth usage, improving overall system performance.

[0019] 2. Intelligent Refresh and Lifespan Protection: Innovatively introducing manual / automatic refresh modes and open control via the Sysfs interface. Users can flexibly choose the refresh strategy according to the application scenario, avoiding meaningless, high-frequency refreshes on the e-ink screen and effectively extending the screen's lifespan—a capability completely lacking in traditional drivers.

[0020] 3. Significantly Improved Performance and Resource Utilization: By employing zero-copy, large-block data transmission (maximum 64KB per transmission), and automatic damage area detection, the number of SPI interactions and CPU intervention is reduced. Real-world testing shows that in full-screen update scenarios, the number of SPI interactions is reduced from approximately 250 using traditional drivers to approximately 64; in partial update scenarios, the number of SPI interactions is reduced by over 95%, significantly improving SPI bus utilization and system response speed.

[0021] 4. Strong maintainability and portability: The driver code fully complies with the Linux kernel DRM subsystem specification, with clear logic, layered structure, and easy maintenance and submission to the upstream community. The driver is decoupled from specific hardware (such as resolution, timing, and commands) through a device tree. When porting to different models of e-ink screens, only the device tree file needs to be modified, without changing the core driver code, which greatly reduces development costs and time.

[0022] 5. Implementing System-Level Screenshot Functionality: This invention registers the SPI e-ink screen as a standard DRM display device, enabling any display content submitted to the DRM framework (i.e., the Android system's UI interface) to be directly displayed on the e-ink screen via the driver. This means that users can take a screenshot of the current phone screen content with one click and display it on the e-ink screen without any additional processing at the application layer, achieving a deep system-level integration that traditional drivers cannot reach. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a preferred embodiment of the method for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework of the present invention. Figure 2 This is a schematic diagram of the overall process of the method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to the present invention; Figure 3 This is a hardware wiring diagram of the method for implementing SPI e-screen screenshot functionality based on the Linux DRM framework. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0025] This invention proposes a method for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework, such as... Figure 1 As shown, a preferred embodiment of the present invention includes the following steps: Step S10: Reconstruct the SPI e-ink screen driver based on the DRM framework in the Linux kernel, and abstract the SPI e-ink screen as a standard display device. Step S20: Manage the frame buffer through the GEM / DMA mechanism of the DRM framework and obtain the UI frame data synthesized by the Android system; Step S30: In response to user configuration or system call, selectively execute manual refresh module or automatic refresh mode. In manual refresh mode, the UI frame data is cached and sent in response to user trigger command. In automatic refresh mode, the UI frame data is automatically sent at preset time intervals after frame data update is detected. Step S40: The UI frame data is sent to the SPI e-screen for display via the reconstructed SPI communication protocol to achieve system-level screenshot.

[0026] Specifically, step S10 includes: Step S101: Based on the mipi-dbi driver foundation of the DRM framework, reconstruct the driver core of the SPI e-ink screen, add a private data structure for the e-ink screen, and reconstruct the SPI communication method and refresh mechanism.

[0027] The step of adding the private data structure for the e-ink screen in step S101 includes: Define struct ink_display_priv, which includes a transmission mutex, a stop transmission flag, a frame address / command code, a dynamic SPI transmit buffer, a GPIO CS enable flag, a refresh mode flag, a refresh completion semaphore, and automatic refresh delay core parameters to achieve independent management of the ink screen's characteristics.

[0028] The step of reconstructing the SPI communication mode in step S101 includes: The system adopts a custom SPI frame format for e-ink displays. Each transmission includes a control byte, a 32-bit address, a 16-bit length, and data. This format is encapsulated using the `ink_write_spi_command()` function. The `ink_spi_write_with_gpio_cs()` function is implemented to manually pull the CS pin low / high before and after data transmission, and a 5µs delay is added to meet setup / hold time requirements.

[0029] The steps in step S101 to reconstruct the refresh mechanism include: The DRM framework pipeline functions are adapted specifically for e-ink screens, skipping the initialization / exit sequence of ordinary screens and retaining only power management; a refresh mode judgment is added to fb_dirty(), in which only the frame data is buffered and not transmitted in manual mode, and the e-ink screen-specific refresh function is called in automatic mode.

[0030] In this embodiment, step S30 includes: In the refresh function, the pixel data in the DRM frame buffer is swapped byte by byte, and the CPU byte order is converted to the LSB-first transmission format required by the e-ink screen to ensure that the displayed data is correct.

[0031] In this embodiment, the method further includes: To address the physical characteristics of SPI e-ink displays and the adaptation requirements of the DRM framework, the device tree was modified to remove redundant configurations and add dedicated parameters, enabling the device tree to recognize SPI e-ink displays and adapt to DRM drivers.

[0032] In this embodiment, step S40 includes: Step S401: Connect to the Android system layer DRM-HWC2 component to enable the function of directly taking screenshots of the system layer UI and pushing them to the SPI e-ink screen.

[0033] The following combination Figure 2 and Figure 3 The present invention provides a detailed description of the method for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework.

[0034] To address the shortcomings of existing technologies, this invention provides an implementation method for SPI e-screen screenshot functionality based on the DRM (Direct Rendering Manager) framework, thereby solving the technical problems existing in traditional solutions. The specific objectives of this invention are as follows: 1. Achieve zero-copy and efficient memory management: Utilize the GEM / DMA (Graphics ExecutionManager / Direct Memory Access) mechanism of the DRM framework to enable unified management of the frame buffer by the kernel, achieving zero-copy transfer of display data between processes and devices, reducing CPU load and improving data transfer efficiency.

[0035] 2. Adapt to diverse data formats: Utilize the unified data format management capabilities of the DRM framework to automatically convert upper-layer applications (such as XRGB8888) to the format required by the e-ink screen (such as RGB565), shielding the differences in underlying hardware.

[0036] 3. Provides intelligent refresh mode to protect screen lifespan: Addressing the physical characteristics of e-ink screens, two modes, "manual refresh" and "automatic refresh," are introduced and made available to users via the Sysfs interface. Users can flexibly control the refresh timing, avoiding ineffective or high-frequency refreshes and extending screen lifespan.

[0037] 4. Reconstruct the SPI communication protocol to meet custom timing requirements: Abandon the standard MIPI DBI protocol and implement a custom SPI frame format according to the e-ink screen specifications. It also supports manual control of the chip select (CS) signal via GPIO to precisely meet the screen's special timing requirements.

[0038] 5. Implement system-level "screenshot" functionality to improve portability: Through the unified display architecture of the DRM framework, the SPI e-ink screen becomes a standard display output device. Any UI interface submitted to the DRM framework (i.e., the display content of the Android system) can be directly displayed on the e-ink screen through the driver layer's refresh mechanism, achieving a "what you see is what you get" screenshot effect. Simultaneously, the core driver logic is decoupled from the hardware; only the device tree needs to be modified to adapt to different e-ink screen models, resulting in strong portability.

[0039] This solution uses the RK3568 hardware platform as an example, built upon the DRM framework of the Linux 4.19 kernel. The solution's approach focuses on core hardware support, customized device tree adaptation, driver core reconstruction, refresh mode control, data transmission optimization, and screenshot functionality implementation. It leverages the collaborative working relationships between DRM frame buffer data, SPI bus transmission characteristics, and the physical requirements of the e-ink screen to achieve efficient screenshot display on the SPI e-ink screen. The specific functions and implementation logic are as follows: (1) Core hardware support This invention is based on the RK3568 embedded chip platform, which features rich peripheral interfaces and good Linux kernel compatibility. It provides the hardware foundation for DRM framework operation, SPI e-screen driver reconstruction, and screenshot functionality. Specific functions include: 1. DRM framework runtime environment: RK3568 supports Linux 4.19 kernel, is natively compatible with DRM subsystem, can directly call DRM's GEM / DMA memory management framework to realize kernel-level management of frame buffer data, and provide hardware support for zero-copy transmission; 2. SPI Bus Control: The RK3568's SPI controller supports SPI_MODE_0 mode and LSB priority transmission, which can directly drive the SPI e-ink screen, and supports GPIO manual chip select (CS) to meet the timing requirements of the e-ink screen; 3. Multi-pin adapter: The chip select, reset and other control pins of the e-ink screen can be flexibly configured, and it also supports DRM-HWC2 interface with the Android system layer to realize direct output of system layer UI screenshots; 4. Memory and computing power support: The RK3568 has ample memory space and can dynamically allocate SPI transmission buffers to meet the block transmission requirements of large resolution screenshot data such as 1920×1080. The chip's computing power can support lightweight operations such as format conversion and damaged area detection.

[0040] (2) Device tree customization and adaptation To address the physical characteristics of SPI e-ink displays and the compatibility requirements of the DRM framework, the device tree of the RK3568 was modified by removing redundant configurations and adding dedicated parameters. This enables the device tree to recognize SPI e-ink displays and adapt to the DRM driver. The specific implementation is as follows: 1. Pin configuration optimization: The DC and reset pins of the traditional SPI screen are removed because the e-ink screen uses a fixed command format and does not require a separate D / C line and hardware reset; a CS chip select is added, which can be manually controlled by GPIO to solve the problem that the hardware automatic chip select cannot meet the timing requirements of the e-ink screen. 2. Command sequence deletion: Remove panel-init-sequence and panel-exit-sequence, because the e-ink screen does not require complex MIPI command sequence initialization after power-on and directly enters the working state; 3. Added special parameters: Add frame-start-addr / frame-end-addr to specify the register address of the e-ink screen frame start / end command (example 0x00000400) to meet the frame transmission protocol requirements of the e-ink screen; 4. Compatibility Attribute Settings: Added device tree compatibility attributes rockchip, spi-ink-display, enabling the DRM driver to recognize SPI ink displays, automatically load dedicated driver logic, and achieve driver isolation from ordinary SPI displays.

[0041] (3) Drive core reconfiguration Based on the DRM framework's mipi-dbi driver foundation, the core driver for the SPI e-ink screen is reconstructed, adding a private data structure for the e-ink screen and reconstructing the SPI communication method and refresh mechanism. This is the core of implementing the screenshot function, and the specific implementation method is as follows: 1. Added a private data structure for e-ink display: Define struct ink_display_priv, which includes core parameters such as transmission mutex, stop transmission flag, frame address / command code, dynamic SPI transmit buffer, GPIO CS enable flag, refresh mode flag, refresh completion semaphore, and automatic refresh delay, to achieve independent management of e-ink display features; 2. SPI Communication Reconstruction: The traditional SPI communication based on the MIPI DBI protocol is abandoned, and a custom SPI frame format for the e-ink screen is adopted. Each transmission includes a control byte + 32-bit address + 16-bit length + data, and this format is encapsulated using `ink_write_spi_command()`. The `ink_spi_write_with_gpio_cs()` function is implemented, manually pulling the CS pin low / high before and after data transmission, and adding a 5µs delay to meet setup / hold time requirements. 3. Byte order adaptation: In the refresh function, the pixel data in the DRM frame buffer is swapped ((dst_buf[i]>>8) | (dst_buf[i]<<8)), which converts the CPU byte order to the LSB-first transmission format required by the e-ink screen to ensure that the displayed data is correct; 4. DRM Pipeline Function Adaptation: Adapt DRM pipeline functions such as enable() / disable() / fb_dirty() to be specifically designed for e-ink screens, skipping the initialization / exit sequence for ordinary screens and retaining only power management; add refresh mode judgment to fb_dirty(), in manual mode only buffering frame data without transmission, and in automatic mode calling the e-ink screen-specific refresh function; 5. Resource management optimization: Dynamically allocate SPI transmit buffers (kmalloc / vmalloc) based on the actual size of the screenshot data to avoid resource waste caused by pre-allocating too much memory; complete buffer initialization during the driver probe stage, with a default initial buffer allocation of 8KB, which is automatically expanded when transmitting high-resolution data.

[0042] (4) Refresh mode control Considering the slow refresh rate and sensitive physical lifespan of e-ink screens, a manual / automatic dual refresh mode is designed, and flexible user-mode control is achieved through the Sysfs interface. Customizable automatic refresh intervals are also supported. Specific implementation details are as follows: 1. New Sysfs interface feature: Create two Sysfs property files in the driver to implement read / write control in refresh mode. 2. manual_refresh: Writing 1 triggers a manual refresh; reading returns whether the current mode is manual. 3. auto_refresh: Writing 0 disables automatic refresh and switches to manual mode; writing a positive number N enables automatic refresh and sets a delay of N seconds. 4. Manual refresh mode: After the screenshot data in the DRM frame buffer is updated, it is only cached in memory and not transmitted via SPI. The user triggers a complete screenshot display process by writing manual_refresh. After the refresh is completed, the user space is notified through the refresh_completion semaphore. 5. Automatic refresh mode: When the frame buffer data is updated (such as when the system UI changes), the screenshot display process is automatically triggered, and the driver is forced to sleep for auto_refresh_delay seconds after the refresh to avoid high-frequency refresh damaging the e-ink screen or increasing power consumption. 6. Emergency stop mechanism: An atomic variable stop_transfer is set as a stop transfer flag. This flag can be detected in real time during the block transfer process, supporting mid-process cancellation of refresh and improving the applicability of the driver.

[0043] (5) Data transmission optimization Based on the DRM framework, a GEM / DMA memory management mechanism is implemented to achieve zero-copy transmission of screenshot data. Furthermore, the block transmission strategy is optimized, and damaged area detection is added, significantly improving the transmission efficiency of the SPI bus. Specific implementation details are as follows: 1. Zero-copy transmission implementation: The physical address of the DRM frame buffer is obtained directly through dma_obj->vaddr. The screenshot data is copied to the dynamic buffer and sent directly, eliminating the memory copy from user space to kernel space in the traditional solution and achieving zero copy. At the same time, it supports GPU direct rendering to GEM objects, and the screenshot data can be sent to the SPI device without CPU intervention. 2. Chunked Transmission Optimization: For high-resolution screenshot data (e.g., 1920×1080×2≈4MB), due to the limited length of a single SPI transmission (maximum 0xFFFF bytes), cyclic chunked transmission is implemented, automatically adjusting the block size to 64KB, reducing the number of SPI interactions (from the traditional 250 times to 64 times). 3. Damage area detection: Utilizing the drm_atomic_helper_damage_merged function of the DRM framework, damage areas updated by multiple windows are automatically merged, and only the actually changed parts (dirty rectangles) in the screenshot are transmitted. The number of SPI interactions during local updates is reduced by more than 95%, which greatly saves bandwidth. 4. Frame transmission protocol implementation: Design a complete frame transmission process. Before refreshing, call ink_send_frame_start() to send a frame start command (write 0xEA to the specified address, then write 1 / 0 to 0x80 to trigger the refresh). After the block transmission is completed, call ink_send_frame_end() to send a frame end command to ensure that the e-ink screen correctly receives the screenshot data.

[0044] (6) Screenshot function implementation By interfacing with the Android system-level DRM-HWC2 component, the system-level UI can be directly screenshotted and pushed to the SPI e-ink screen, eliminating reliance on third-party applications. Specific implementation details are as follows: 1. DRM-HWC2 Framework Integration: The reconstructed DRM-SPI e-ink screen driver is integrated into the DRM-HWC2 part of the Android system, enabling the system layer to recognize the SPI e-ink screen as a display output device and directly use the frame buffer data of the current UI rendering as the screenshot data source; 2. DMA memory size adjustment: Adjust the DMA memory size of DRM according to the resolution of the e-ink screen (e.g., 1920×1080) to ensure that it can accommodate complete screenshot data and avoid memory overflow when refreshing the screen; 3. Direct output of screenshot data: The DRM framework captures UI frame buffer data from the Android system layer in real time. After format conversion (only RGB565 is supported, and other formats are automatically detected and prompted) and byte order processing, the data is transmitted to the e-screen via the optimized SPI bus, realizing the integration of screenshot-transmission-display. 4. Full-screen screenshot adaptation: The driver sets the full-screen refresh area by default. When the refresh is triggered, the system full-screen UI is directly captured and displayed without the need for user cropping or preprocessing.

[0045] The implementation flowchart of this solution is as follows: Figure 2 As shown, the hardware wiring diagram is as follows: Figure 3 As shown.

[0046] Figure 2 This document presents the entire process of implementing an RK3568 platform + Android system + DRM framework + SPI e-ink screen solution, from system UI generation and user refresh control to driver processing, SPI transmission, and final e-ink screen display. The project implementation details for each step are as follows: I. Android System-Side Display Chain (Screen Generation → Driver Trigger, Flowchart Left Column) 1. Current screen of Android system This project directly uses all the visual content of the Android system (Launcher desktop, system settings, third-party App interfaces, etc.) as the display data source for the e-screen, without the need to develop additional third-party screenshot applications. It directly reuses the native rendering output of the Android graphics stack to achieve full-screen screenshot display of the system UI.

[0047] 2. Android system image buffer The graphics buffer is allocated based on the DRM / GEM DMA memory mechanism of RK3568. The buffer size is dynamically adjusted according to the actual resolution of the e-ink screen (such as 1920×1080) to ensure that it can accommodate a complete frame of screen data, providing a hardware memory foundation for subsequent zero-copy transmission.

[0048] 3. The Android system's frame composition service submits new frame data. The Android native SurfaceFlinger service is invoked to complete the compositing of all App / system UI layers and generate a complete frame. This composite frame directly serves as the "screenshot data source" for the e-ink screen, and the project does not need to perform additional screenshot acquisition processing, reusing the system's native compositing results.

[0049] 4. Android's Hardware Composition Abstraction Layer (HWC2) The reconstructed SPI e-ink screen DRM driver of this project is integrated into the Android HWC2 module, allowing the system to recognize the e-ink screen as a formal display output device. The frame data synthesized by SurfaceFlinger is directly passed to the kernel DRM driver through HWC2, realizing hardware acceleration docking from the system layer to the kernel layer and eliminating the dependence on third-party tools.

[0050] 5. The Display Driver Framework (DRM) triggers the dirty area callback function of the e-ink screen driver. We adapted the DRM framework of RK3568 specifically for e-ink screens. In the dirty area callback (corresponding to the fb_dirty() function), we skipped the initialization / exit sequence of ordinary displays and only retained power management. At the same time, we added refresh mode judgment logic. When triggered, it notifies the e-ink screen driver that there is a new screen that needs to be processed. This is the core trigger point for the driver to start working.

[0051] II. User-controlled branch (triggered by refresh mode, upper right two columns of the flowchart, merged into the middle node) 6. The user executes the manual refresh command for the e-ink screen. Create a manual_refresh Sysfs property file in the driver. Users can send a manual refresh trigger signal to the driver by executing commands via ADB / terminal (such as echo 1> / sys / class / drm / card0 / device / ink_display / manual_refresh). Upon receiving the signal, the driver will immediately set the manual refresh flag.

[0052] 7. Manual refresh function for e-ink screen driver A dedicated manual refresh handling function was developed. Upon receiving a trigger signal, the driver refresh process is activated, and only a single complete refresh is performed. After the refresh is completed, the user space is notified through the refresh_completion semaphore. In manual mode, when no trigger command is received, the frame data is only buffered and not transmitted via SPI to avoid invalid refresh and protect the lifespan of the e-ink screen.

[0053] 8. The user executes the automatic refresh command for the e-ink screen. Create an auto_refresh Sysfs property file. The user-input value X is the refresh interval (in seconds; X=0 disables automatic refresh). After parsing the value, the driver configures the kernel timer's timing period, thus enabling and setting the parameters for automatic refresh mode.

[0054] 9. Automatic refresh function for e-ink screen driver An automatic refresh function is implemented based on Linux kernel timers / work queues, which automatically triggers refresh at user-defined intervals of X seconds. After refreshing, the driver is forced to sleep for X seconds, and DRM dirty area detection is linked to ensure that actual transmission is only performed when there are changes in the image, thus avoiding damage to the e-ink screen and increased power consumption caused by high-frequency refresh.

[0055] 10. Frame buffer area processing for e-ink screen drivers The `drm_atomic_helper_damage_merged` function of the DRM framework is called to automatically merge multiple dirty rectangles (image change areas) in the frame buffer. Only the changed parts are processed, and no full-screen refresh is performed, which greatly reduces the amount of data transmitted in subsequent SPI. This node is the meeting point of two trigger sources: the system side (DRM callback) and the user side (manual / automatic refresh). Both trigger sources will enter this processing stage.

[0056] III. Driver Core Processing → SPI Transmission → E-Screen Display (Middle Column of Flowchart, Core Implementation of the Entire Link) 11. Obtain the virtual address of the DMA buffer and read the framebuffer. By directly obtaining the kernel virtual address of the DRM frame buffer via dma_obj->vaddr, the screen data is read with zero copy. There is no need for memory copying from user space to kernel space. The original pixel data is obtained directly. This is implemented based on the hardware support of DRM / GEMDMA of RK3568 and is the core of this solution for zero-copy transmission.

[0057] 12. Data copying and format conversion Completed two exclusive adaptations for e-ink screens: Data copy: Copy the frame data to the SPI transmission buffer dynamically allocated by the driver (default 8KB, automatically expands for high resolution to avoid pre-allocation and wasting memory). Format and byte order conversion: Convert the default Android RGBA8888 format to the RGB565 format supported by e-ink screens. At the same time, use bitwise operations (dst_buf[i]>>8) | (dst_buf[i]<<8) to convert the CPU byte order to the LSB priority format required by e-ink screens to ensure correct data parsing.

[0058] 13. SPI Transmission Start Frame Command According to the custom SPI protocol of the e-ink screen, call the ink_send_frame_start() function to send the frame start command: first write 0xEA to the frame-start-addr configured in the device tree (example 0x00000400), and then write 1 to address 0x80 to trigger the e-ink screen to prepare for reception; at the same time, manually pull the CS chip select pin low through GPIO and add a 5us delay to meet the timing requirements of the e-ink screen.

[0059] 14. Constructing SPI protocol packets by transmitting pixel data in blocks To address the SPI single-transmission maximum length limit (0xFFFF bytes), high-resolution frame data (e.g., 1920×1080≈4MB) is split into 64KB blocks and sent cyclically, reducing the number of SPI interactions from the traditional 250 to 64. Simultaneously, SPI protocol packets are constructed according to the format "control byte + 32-bit address + 16-bit length + pixel data," and transmitted using a custom `ink_spi_write_with_gpio_cs()` function. The CS is manually pulled low / high before and after each data block, with a 5µs delay added, adapting to the timing of the RK3568 SPI controller and e-ink screen.

[0060] 15. SPI transmission of end-of-frame command After all pixel data blocks are transmitted, the `ink_send_frame_end()` function is called to write the end code to the frame-end-addr configured in the device tree, notifying the e-ink screen that data transmission is complete; at the same time, the CS chip select pin is manually pulled high to end this SPI communication, ensuring that the e-ink screen correctly completes the refresh process.

[0061] 16. E-ink screen update display After receiving the complete frame data, the e-ink screen parses the pixel data according to the SPI protocol configured in the project, and drives the electronic ink particles to flip to complete the screen refresh. The project defaults to setting a full-screen refresh area, directly displaying a full-screen UI screenshot of the Android system without requiring additional cropping by the user, thus achieving the final screenshot display function of the solution.

[0062] This invention is based on the RK3568 hardware platform, Linux 4.19 kernel, and DRM framework. The overall implementation of the SPI e-screen screenshot function is achieved through five core stages: hardware architecture construction, device tree customization and adaptation, driver core reconstruction and development, DRM-HWC2 integration and optimization, and system testing and optimization. The core implementation steps of each stage are as follows: 1. Hardware Architecture Setup: Using the RK3568 development board as the main controller, a hardware system of "main controller - SPI e-ink screen - peripheral control pins" is built. The SPI controller of the RK3568 is connected to the SPI interface of the e-ink screen, and a dedicated GPIO pin is configured to realize the chip select control of the e-ink screen, ensuring that the hardware layer is compatible with the DRM framework and SPI transmission timing requirements.

[0063] 2. Device Tree Customization and Adaptation: Based on the original RK3568 device tree, the redundant dc / reset pin configurations and initialization / exit command sequences of the SPI screen are removed. A dedicated chip select GPIO and frame start / end address parameters for the e-ink screen are added. Exclusive compatibility attributes for the e-ink screen are added. After modifying the SPI transmission-related configurations, the customized device tree is compiled and programmed onto the RK3568 development board to make it effective.

[0064] 3. Driver Core Reconstruction and Development: Based on the mipi-dbi driver of the Linux kernel DRM and referencing the original SPI panel driver, a dedicated driver adapted for the SPI e-ink screen was reconstructed and developed. A private data structure for the e-ink screen was added, and core functions such as GPIO chip select control, custom SPI frame format encapsulation, and frame transmission commands were developed. Manual / automatic dual refresh modes and corresponding Sysfs control interfaces were designed and implemented. The e-ink screen-specific adaptation and dynamic resource management optimization of the DRM pipeline functions were completed. Finally, the driver was compiled into a kernel module and loaded onto the RK3568 platform.

[0065] 4. DRM-HWC2 Integration: The reconstructed DRM-SPI e-ink driver is integrated into the Android system kernel source code. The integration between the DRM-HWC2 component and the e-ink driver is completed at the Android hardware layer, enabling the system layer to recognize the SPI e-ink as a display output device. The DMA memory size of DRM is adjusted according to the e-ink resolution to ensure that it can accommodate complete screenshot data, so that the UI frame buffer data of the Android system layer can be directly output to the e-ink as the screenshot data source.

[0066] 5. System Testing and Optimization: Conduct multi-dimensional testing of the system's functionality, performance, and stability to verify the effectiveness of refresh mode switching, screenshot display integrity, and command response; test screenshot transmission efficiency and CPU utilization under different resolutions and UI scenarios to simulate complex operating scenarios and verify driver stability; optimize SPI transmission timing, refresh parameters, log output, etc. based on test results, and complete driver compatibility adaptation on different SPI e-ink screens to simplify the operation interface and improve the actual user experience.

[0067] By following the steps above, the SPI e-screen screenshot function based on the DRM framework can be quickly implemented, completing the entire development process from hardware adaptation to software implementation, and meeting the low-power and high-efficiency screenshot display requirements of RK3568 platform embedded devices.

[0068] The beneficial effects of the method for implementing SPI e-screen screenshot functionality based on the Linux DRM framework in this invention are: 1. Unified Memory Management and Zero-Copy: Utilizing the DRM / GEM / DMA framework, the frame buffer is uniformly managed by the kernel, allowing user space and drivers to directly access the same physical memory, achieving true zero-copy. Compared to traditional drivers that perform at least two memory copies, this significantly reduces CPU load and memory bandwidth usage, improving overall system performance.

[0069] 2. Intelligent Refresh and Lifespan Protection: Innovatively introducing manual / automatic refresh modes and open control via the Sysfs interface. Users can flexibly choose the refresh strategy according to the application scenario, avoiding meaningless, high-frequency refreshes on the e-ink screen and effectively extending the screen's lifespan—a capability completely lacking in traditional drivers.

[0070] 3. Significantly Improved Performance and Resource Utilization: By employing zero-copy, large-block data transmission (maximum 64KB per transmission), and automatic damage area detection, the number of SPI interactions and CPU intervention is reduced. Real-world testing shows that in full-screen update scenarios, the number of SPI interactions is reduced from approximately 250 using traditional drivers to approximately 64; in partial update scenarios, the number of SPI interactions is reduced by over 95%, significantly improving SPI bus utilization and system response speed.

[0071] 4. Strong maintainability and portability: The driver code fully complies with the Linux kernel DRM subsystem specification, with clear logic, layered structure, and easy maintenance and submission to the upstream community. The driver is decoupled from specific hardware (such as resolution, timing, and commands) through a device tree. When porting to different models of e-ink screens, only the device tree file needs to be modified, without changing the core driver code, which greatly reduces development costs and time.

[0072] 5. Implementing System-Level Screenshot Functionality: This invention registers the SPI e-ink screen as a standard DRM display device, enabling any display content submitted to the DRM framework (i.e., the Android system's UI interface) to be directly displayed on the e-ink screen via the driver. This means that users can take a screenshot of the current phone screen content with one click and display it on the e-ink screen without any additional processing at the application layer, achieving a deep system-level integration that traditional drivers cannot reach.

[0073] To achieve the above objectives, the present invention also proposes a system for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework. The system includes a memory, a processor, and a program for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework stored on the processor. When the processor runs the program for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework, it executes the steps of the method described above.

[0074] To achieve the above objectives, the present invention also proposes a computer-readable storage medium storing a program that implements SPI e-ink screen screenshot functionality based on the Linux DRM framework. When the program implements SPI e-ink screen screenshot functionality based on the Linux DRM framework is run by a processor, the steps of the method described above are executed.

[0075] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework, characterized in that, The method includes the following steps: Step S10: Reconstruct the SPI e-ink screen driver based on the DRM framework in the Linux kernel, and abstract the SPI e-ink screen as a standard display device. Step S20: Manage the frame buffer through the GEM / DMA mechanism of the DRM framework and obtain the UI frame data synthesized by the Android system; Step S30: In response to user configuration or system call, selectively execute manual refresh module or automatic refresh mode. In manual refresh mode, the UI frame data is cached and sent in response to user trigger command. In automatic refresh mode, the UI frame data is automatically sent at preset time intervals after frame data update is detected. Step S40: The UI frame data is sent to the SPI e-screen for display via the reconstructed SPI communication protocol to achieve system-level screenshot.

2. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 1, characterized in that, Step S10 includes: Step S101: Based on the mipi-dbi driver foundation of the DRM framework, reconstruct the driver core of the SPI e-ink screen, add a private data structure for the e-ink screen, and reconstruct the SPI communication method and refresh mechanism.

3. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 2, characterized in that, The step of adding the private data structure for the e-ink screen in step S101 includes: Define struct ink_display_priv, which includes a transmission mutex, a stop transmission flag, a frame address / command code, a dynamic SPI transmit buffer, a GPIO CS enable flag, a refresh mode flag, a refresh completion semaphore, and automatic refresh delay core parameters to achieve independent management of the ink screen's characteristics.

4. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 3, characterized in that, The step of reconstructing the SPI communication mode in step S101 includes: The system adopts a custom SPI frame format for e-ink displays. Each transmission includes a control byte, a 32-bit address, a 16-bit length, and data. This format is encapsulated using the `ink_write_spi_command()` function. The `ink_spi_write_with_gpio_cs()` function is implemented to manually pull the CS pin low / high before and after data transmission, and a 5µs delay is added to meet setup / hold time requirements.

5. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 4, characterized in that, The steps in step S101 to reconstruct the refresh mechanism include: The DRM framework pipeline functions are adapted specifically for e-ink screens, skipping the initialization / exit sequence of ordinary screens and retaining only power management; a refresh mode judgment is added to fb_dirty(), in which only the frame data is buffered and not transmitted in manual mode, and the e-ink screen-specific refresh function is called in automatic mode.

6. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 5, characterized in that, Step S30 includes: In the refresh function, the pixel data in the DRM frame buffer is swapped byte by byte, and the CPU byte order is converted to the LSB-first transmission format required by the e-ink screen to ensure that the displayed data is correct.

7. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 6, characterized in that, The method further includes: To address the physical characteristics of SPI e-ink displays and the adaptation requirements of the DRM framework, the device tree was modified to remove redundant configurations and add dedicated parameters, enabling the device tree to recognize SPI e-ink displays and adapt to DRM drivers.

8. The method for implementing SPI e-ink screen screenshot function based on Linux DRM framework according to claim 7, characterized in that, Step S40 includes: Step S401: Connect to the Android system layer DRM-HWC2 component to enable the function of directly taking screenshots of the system layer UI and pushing them to the SPI e-ink screen.

9. A system for implementing SPI e-ink screen screenshot functionality based on the Linux DRM framework, characterized in that, The system includes a memory, a processor, and a program stored on the processor that implements the SPI e-ink screen screenshot function based on the Linux DRM framework. The program that implements the SPI e-ink screen screenshot function based on the Linux DRM framework is executed by the processor to perform the steps of the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that implements the SPI e-ink screen screenshot function based on the Linux DRM framework. When the processor runs the program that implements the SPI e-ink screen screenshot function based on the Linux DRM framework, it executes the steps of the method described in any one of claims 1 to 8.

Images