WO2021056364A1

WO2021056364A1 - Methods and apparatus to facilitate frame per second rate switching via touch event signals

Info

Publication number: WO2021056364A1
Application number: PCT/CN2019/108316
Authority: WO
Inventors: Nan Zhang; Yongjun XU; Zhiguo Li
Original assignee: Qualcomm Incorporated
Priority date: 2019-09-26
Filing date: 2019-09-26
Publication date: 2021-04-01

Abstract

The present disclosure relates to methods and apparatus for display processing. For example, disclosed techniques facilitate frame per second rate switching via touch event signals. Aspects of the present disclosure can receive, at a display driver outside of a user space, an indication of a touch event from a touch sensor via a general-purpose input/output (GPIO) signal. Aspects of the present disclosure can also determine a frame per second (FPS) rate of a display client based on the received indication. Further, aspects of the present disclosure can cause a change in the FPS rate of the display client based on the determined FPS rate.

Description

METHODS AND APPARATUS TO FACILITATE FRAME PER SECOND RATE SWITCHING VIA TOUCH EVENT SIGNALS

TECHNICAL FIELD

The present disclosure relates generally to processing systems and, more particularly, to one or more techniques for display or graphics processing.

INTRODUCTION

Computing devices often utilize a graphics processing unit (GPU) to accelerate the rendering of graphical data for display. Such computing devices may include, for example, computer workstations, mobile phones such as so-called smartphones, embedded systems, personal computers, tablet computers, and video game consoles. GPUs execute a graphics processing pipeline that includes one or more processing stages that operate together to execute graphics processing commands and output a frame. A central processing unit (CPU) may control the operation of the GPU by issuing one or more graphics processing commands to the GPU. Modern day CPUs are typically capable of concurrently executing multiple applications, each of which may need to utilize the GPU during execution. A device that provides content for visual presentation on a display generally includes a GPU.

A display refresh rate refers to the rate at which a display processor replaces the image frame currently being displayed with a new image frame. However, with the advent of wireless communication, smaller handheld devices, and different refresh rates, there has developed an increased need for improved display processing.

SUMMARY

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a display processor, a display processing unit (DPU) , a graphics processing unit (GPU) , or a video processor. The apparatus can determine a refresh offset for at least one group of lines in a first display based on at least one group of lines in a second display. The apparatus can also apply the refresh offset for the at least one group of lines in the first display based on the at least one group of lines in the second display. Additionally, the apparatus can adjust a combined instantaneous bandwidth corresponding to each of the at least one group of lines in the first display and each of the at least one group of lines in the second display based on the applied refresh offset. The apparatus can also determine one or more overlapping layer regions based on the first display and the second display. The apparatus can also calculate an instantaneous bandwidth for each of the at least one group of lines in the first display and each of the at least one group of lines in the second display and/or calculate a combined instantaneous bandwidth for each of the one or more overlapping layer regions. Further, the apparatus can calculate a difference between a frame retirement duration for the first display and a frame retirement duration for the second display. The apparatus can also reduce the combined instantaneous bandwidth corresponding to each of the at least one group of lines in the first display and each of the at least one group of lines in the second display. The apparatus can also map the refresh offset to each of the at least one group of lines in the first display and each of the at least one group of lines in the second display, where the combined instantaneous bandwidth is based on the mapped refresh offset.

The details of one or more examples of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram that illustrates an example content generation system, in accordance with one or more techniques of this disclosure.

FIG. 2 illustrates an example display processing timeline.

FIG. 3 is a block diagram illustrating the example processing unit of FIG. 1, the example display processor of FIG. 1, the example display client of FIG. 1, and an example touch sensor, in accordance with one or more techniques of this disclosure.

FIG. 4 illustrates an example display processing timeline, in accordance with one or more techniques of this disclosure.

FIGs. 5 to 7 illustrate example flowcharts of example methods, in accordance with one or more techniques of this disclosure.

DETAILED DESCRIPTION

In general, examples disclosed herein provide techniques for controlling a display refresh rate for display processing. In some examples, a touch controller generates a touch event signal based on a detected touch event. The touch event may include a touching, a swiping, a pinching, etc. of a touch panel. A display driver receives the touch event signal directly from the touch controller and is able to process the touch event signal relatively quickly, as explained in further detail below. For example, the display driver may determine a change in the display refresh rate of a display client based on the touch event signal. The display driver may then instruct a display processor to change the display refresh rate (or “FPS rate” ) of the display client accordingly.

As described above, the display driver may receive the touch event signal directly from the touch controller. For example, the display driver may receive the touch event signal via a general-purpose input-output (GPIO) pin. As a result, the display driver may determine a change in the display frame per second (FPS) rate based on the touch event signal directly from the touch controller (i.e., not received from an application and/or a hardware abstraction layer (HAL) associated with the display client) . In this way, the display driver may be able to more quickly determine a change in FPS rate, rather than waiting on information from the application and/or the HAL.

Various aspects of systems, apparatuses, computer program products, and methods are described more fully hereinafter with reference to the accompanying drawings. This disclosure may, however, be embodied in many different forms and should not be construed as limited to any specific structure or function presented throughout this disclosure. Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of this disclosure to those skilled in the art. Based on the teachings herein one skilled in the art should appreciate that the scope of this disclosure is intended to cover any aspect of the systems, apparatuses, computer program products, and methods disclosed herein, whether implemented independently of, or combined with, other aspects of the disclosure. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method which is practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the disclosure set forth herein. Any aspect disclosed herein may be embodied by one or more elements of a claim.

Although various aspects are described herein, many variations and permutations of these aspects fall within the scope of this disclosure. Although some potential benefits and advantages of aspects of this disclosure are mentioned, the scope of this disclosure is not intended to be limited to particular benefits, uses, or objectives. Rather, aspects of this disclosure are intended to be broadly applicable to different wireless technologies, system configurations, networks, and transmission protocols, some of which are illustrated by way of example in the figures and in the following description. The detailed description and drawings are merely illustrative of this disclosure rather than limiting, the scope of this disclosure being defined by the appended claims and equivalents thereof.

Several aspects are presented with reference to various apparatus and methods. These apparatus and methods are described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, and the like (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

By way of example, an element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors (which may also be referred to as processing units) . Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , general purpose GPUs (GPGPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems-on-chip (SOC) , baseband processors, application specific integrated circuits (ASICs) , field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software can be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The term application may refer to software. As described herein, one or more techniques may refer to an application, i.e., software, being configured to perform one or more functions. In such examples, the application may be stored on a memory, e.g., on-chip memory of a processor, system memory, or any other memory. Hardware described herein, such as a processor may be configured to execute the application. For example, the application may be described as including code that, when executed by the hardware, causes the hardware to perform one or more techniques described herein. As an example, the hardware may access the code from a memory and execute the code accessed from the memory to perform one or more techniques described herein. In some examples, components are identified in this disclosure. In such examples, the components may be hardware, software, or a combination thereof. The components may be separate components or sub-components of a single component.

Accordingly, in one or more examples described herein, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise a random access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

In general, examples disclosed herein provide techniques for changing the FPS rate of a device client relatively quickly. For example, example techniques disclosed herein enable a display driver to directly receive a touch event signal from a touch controller (e.g., via a GPIO signal received via a GPIO pin) and determine a change in the FPS rate. In some examples, a GPIO pin is a digital signal pin that is not associated with a dedicated purpose, but may be provided a purpose during operation. For example, example techniques disclose using the GPIO pin to transmit the touch event signal (e.g., the GPIO signal) from the touch controller to the display driver (e.g., the GPIO pin is configured to transmit, via the GPIO signal, the touch event signal from the touch controller to the display driver) . In some examples, the GPIO signal may be any signal that is configured to transmit information from the touch controller to the display driver without passing through a user space. In this manner, the display driver may more quickly determine the change in the FPS rate, rather than waiting on information from a user space (e.g., an application and/or an application framework) and/or a hardware abstraction layer associated with the display client. Other example benefits are described throughout this disclosure.

As used herein, instances of the term “content” may refer to “graphical content, ” “image, ” and vice versa. This is true regardless of whether the terms are being used as an adjective, noun, or other parts of speech. In some examples, as used herein, the term “graphical content” may refer to a content produced by one or more processes of a graphics processing pipeline. In some examples, as used herein, the term “graphical content” may refer to a content produced by a processing unit configured to perform graphics processing. In some examples, as used herein, the term “graphical content” may refer to a content produced by a graphics processing unit. In some examples, as used herein, the term “display content” may refer to content generated by a processing unit configured to perform displaying processing. In some examples, as used herein, the term “display content” may refer to content generated by a display processing unit. Graphical content may be processed to become display content. For example, a graphics processing unit may output graphical content, such as a frame, to a buffer (which may be referred to as a framebuffer) . A display processing unit may read the graphical content, such as one or more frames from the buffer, and perform one or more display processing techniques thereon to generate display content. For example, a display processing unit may be configured to perform composition on one or more rendered layers to generate a frame. As another example, a display processing unit may be configured to compose, blend, or otherwise combine two or more layers together into a single frame. A display processing unit may be configured to perform scaling, e.g., upscaling or downscaling, on a frame. In some examples, a frame may refer to a layer. In other examples, a frame may refer to two or more layers that have already been blended together to form the frame, i.e., the frame includes two or more layers, and the frame that includes two or more layers may subsequently be blended.

FIG. 1 is a block diagram that illustrates an example content generation system 100 configured to implement one or more techniques of this disclosure. The content generation system 100 includes a device 104. The device 104 may include one or more components or circuits for performing various functions described herein. In some examples, one or more components of the device 104 may be components of an SOC. The device 104 may include one or more components configured to perform one or more techniques of this disclosure. In the example shown, the device 104 may include a processing unit 120 and a system memory 124. In some aspects, the device 104 can include a number of optional components, e.g., a communication interface 126, a transceiver 132, a receiver 128, a transmitter 130, a display processor 127, and a display client 131. Reference to the display client 131 may refer to one or more displays. For example, the display client 131 may include a single display or multiple displays. The display client 131 may include a first display and a second display. In further examples, the results of the graphics processing may not be displayed on the device, e.g., the first and second displays may not receive any frames for presentment thereon. Instead, the frames or graphics processing results may be transferred to another device. In some aspects, this can be referred to as split-rendering.

The processing unit 120 may include an internal memory 121. The processing unit 120 may be configured to perform graphics processing, such as in a graphics processing pipeline 107. In some examples, the device 104 may include a display processor, such as the display processor 127, to perform one or more display processing techniques on one or more frames generated by the processing unit 120 before presentment by the display client 131. The display processor 127 may be configured to perform display processing. For example, the display processor 127 may be configured to perform one or more display processing techniques on one or more frames generated by the processing unit 120. The display client 131 may be configured to display or otherwise present frames processed by the display processor 127. In some examples, the display client 131 may include one or more of: a liquid crystal display (LCD) , a plasma display, an organic light emitting diode (OLED) display, a projection display device, an augmented reality display device, a virtual reality display device, a head-mounted display, or any other type of display device.

Memory external to the processing unit 120, such as system memory 124, may be accessible to the processing unit 120. For example, the processing unit 120 may be configured to read from and/or write to external memory, such as the system memory 124. The processing unit 120 may be communicatively coupled to the system memory 124 over a bus. In some examples, the processing unit 120 and the system memory 124 may be communicatively coupled to each other over the bus or a different connection.

It should be appreciated that in some examples, the device 104 may include a content encoder/decoder configured to receive graphical and/or display content from any source, such as the system memory 124 and/or the communication interface 126. The system memory 124 may be configured to store received encoded or decoded graphical content. In some examples, the content encoder/decoder may be configured to receive encoded or decoded graphical content, e.g., from the system memory 124 and/or the communication interface 126, in the form of encoded pixel data. In some examples, the content encoder/decoder may be configured to encode or decode any graphical content.

The internal memory 121 or the system memory 124 may include one or more volatile or non-volatile memories or storage devices. In some examples, internal memory 121 or the system memory 124 may include RAM, SRAM, DRAM, erasable programmable ROM (EPROM) , electrically erasable programmable ROM (EEPROM) , flash memory, a magnetic data media or an optical storage media, or any other type of memory.

The internal memory 121 or the system memory 124 may be a non-transitory storage medium according to some examples. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted to mean that internal memory 121 or the system memory 124 is non-movable or that its contents are static. As one example, the system memory 124 may be removed from the device 104 and moved to another device. As another example, the system memory 124 may not be removable from the device 104.

The processing unit 120 may be a central processing unit (CPU) , a graphics processing unit (GPU) , a general purpose GPU (GPGPU) , or any other processing unit that may be configured to perform graphics processing. In some examples, the processing unit 120 may be integrated into a motherboard of the device 104. In some examples, the processing unit 120 may be present on a graphics card that is installed in a port in a motherboard of the device 104, or may be otherwise incorporated within a peripheral device configured to interoperate with the device 104. The processing unit 120 may include one or more processors, such as one or more microprocessors, GPUs, application specific integrated circuits (ASICs) , field programmable gate arrays (FPGAs) , arithmetic logic units (ALUs) , digital signal processors (DSPs) , discrete logic, software, hardware, firmware, other equivalent integrated or discrete logic circuitry, or any combinations thereof. If the techniques are implemented partially in software, the processing unit 120 may store instructions for the software in a suitable, non-transitory computer-readable storage medium, e.g., internal memory 121, and may execute the instructions in hardware using one or more processors to perform the techniques of this disclosure. Any of the foregoing, including hardware, software, a combination of hardware and software, etc., may be considered to be one or more processors.

In some aspects, the content generation system 100 can include a communication interface 126. The communication interface 126 may include a receiver 128 and a transmitter 130. The receiver 128 may be configured to perform any receiving function described herein with respect to the device 104. Additionally, the receiver 128 may be configured to receive information, e.g., eye or head position information, rendering commands, or location information, from another device. The transmitter 130 may be configured to perform any transmitting function described herein with respect to the device 104. For example, the transmitter 130 may be configured to transmit information to another device, which may include a request for content. The receiver 128 and the transmitter 130 may be combined into a transceiver 132. In such examples, the transceiver 132 may be configured to perform any receiving function and/or transmitting function described herein with respect to the device 104.

In some examples, the graphical content from the processing unit 120 for display via the display client 131 is not static and may be changing. Accordingly, the display processor 127 may periodically refresh the graphical content displayed via the display client 131. For example, the display processor 127 may periodically retrieve graphical content from the system memory 124, where the graphical content may have been updated by the execution of an application (and/or the processing unit 120) that outputs the graphical content to the system memory 124.

The rate at which the display processor 127 refreshes the graphical content displayed via the display client 131 may be referred to as the frames per second (FPS) rate or the “display refresh rate. ” Examples of the display refresh rate include 30fps, 60fps, 90fps, 120fps, 240fps, etc.

There may be various factors that affect the display refresh rate. For example, if the processing unit 120 is executing a video game application, then the processing unit 120 (and/or the GPU) may be generating graphical content (e.g., a computer-generated animation) at a relatively high rate. For smooth playback of the animations, the display processor 127 may attempt to refresh the graphical content displayed via the display client 131 at a relatively high display refresh rate (e.g., 90fps) . In some examples, if the display refresh rate is too slow, then the graphical content displayed may appear laggy or jumpy (also referred to as “jank” ) . For example, if the display refresh rate is slower than the change in frames of the animation, then the animation may appear laggy or jumpy. It should be appreciated that in some examples, the display refresh rate of the display client may be relatively slow because the display client is operating in an idle state. For example, the display client may switch to an idle state to conserve power (e.g. while there is no user interaction) .

In some examples, an application that generated the graphical content that a display processor is accessing may be configured to determine a display refresh rate. In some examples, a display hardware abstraction layer (HAL) application may be configured to determine the display refresh rate. The display HAL application may be an application that enables applications that generate graphical content to communicate with a display driver. However, there may be a delay associated with the application or the display HAL application determining that there was a touch event, determining that the display refresh rate is to be changed, and then instructing the display drive to change the display refresh rate.

As disclosed herein, example techniques disclose the display driver directly receiving a touch event signal (e.g., via a GPIO signal) . The display driver may then more quickly determine a change to the display refresh rate (e.g., without waiting for the application to provide the display refresh rate and/or the display HAL application to provide the display refresh rate) and, therefore, avoid the jank caused by the low display refresh rate.

Referring again to FIG. 1, in certain aspects, the processing unit 120 may include an FPS changing handling component 198 configured to determine refresh rate information for the display client 131. For example, the FPS handling component 198 may be configured to determine a new FPS rate of the display client 131 and/or a change in the FPS rate of the display client 131. The FPS handling component 198 may be configured to receive, at a display driver outside of a user space, an indication of a touch event from a touch sensor via a general-purpose input/output (GPIO) signal. The FPS handling component 198 may also be configured to determine a frame per second (FPS) rate of the display client 131 (sometimes referred to as a “display panel” ) based on the received indication. The FPS handling component 198 may also be configured to cause a change in the FPS rate of the display client based on the determined FPS rate.

In some examples, the FPS handling component 198 may also be configured so that the display driver is included in a kernel space of a processing unit, and the kernel space is different than the user space. In some examples, the FPS handling component 198 may also be configured so that the display driver may receive the GPIO signal directly from a touch controller of the sensor. In some examples, the FPS handling component 198 may also be configured to request a display processor to change the FPS rate of the display client based on the determined FPS rate. In some examples, the FPS handling component 198 may also be configured to cause the change in the FPS rate of the display client by initiating an interrupt service request (ISR) within the display driver based on the indication of the touch event, and transmitting ISR to a display processor. In some examples, the FPS handling component 198 may also be configured to adjust a vertical synchronization (Vsync) pulse based on the determined FPS rate. In some examples, the FPS handling component 198 may also be configured to adjust the Vsync pulse within a timeframe of two frames. In some examples, the FPS handling component 198 may also be configured to determine whether to change a current FPS rate of the display client based on the indication of the touch event, and where the determining of the FPS rate of the display client is performed in response to a determination to change the current FPS rate of the display client. In some examples, the FPS handling component 198 may also be configured to determine whether to change the current FPS rate of the display client by determining an operating state of the display client. In some examples, the FPS handling component 198 may also be configured to determine to change the current FPS rate of the display client when the display client is operating in an idle state. In some examples, the FPS handling component 198 may also be configured to display an animation via the display client, and wherein the causing of the change in the FPS rate of the display client occurs prior to a start of the displaying of the animation.

As described herein, a device, such as the device 104, may refer to any device, apparatus, or system configured to perform one or more techniques described herein. For example, a device may be a server, a base station, user equipment, a client device, a station, an access point, a computer, e.g., a personal computer, a desktop computer, a laptop computer, a tablet computer, a computer workstation, or a mainframe computer, an end product, an apparatus, a phone, a smart phone, a server, a video game platform or console, a handheld device, e.g., a portable video game device or a personal digital assistant (PDA) , a wearable computing device, e.g., a smart watch, an augmented reality device, or a virtual reality device, a non-wearable device, a display or display device, a television, a television set-top box, an intermediate network device, a digital media player, a video streaming device, a content streaming device, an in-car computer, any mobile device, any device configured to generate graphical content, or any device configured to perform one or more techniques described herein. Processes herein may be described as performed by a particular component (e.g., a GPU) , but, in further embodiments, can be performed using other components (e.g., a CPU) , consistent with disclosed embodiments.

FIG. 2 illustrates an example display processing timeline 200. As shown in FIG. 2, a touch event is detected at time T0. For example, a touch panel may detect the touch event and generate touch event data based on the detected touch event. The touch event data may then be provided to a touch driver for interpreting the touch event data, provided to a touch service (e.g., in a kernel space) for determining how to process the touch event data, provided to one or more services of the user space (e.g., the application, the display HAL application, etc. ) to determine how to update the display based on the touch event data, and provided to a kernel display driver to request changing the FPS rate of the display client 131. The change in FPS rate may then be performed the display client 131 at time T2. In some examples, it may take approximately 440ms from the touch event (at time T0) to when the FPS rate change is performed (at time T2) .

As shown in FIG. 2, an animation (such as a scrolling of the display, etc. ) may be started at time T1 and the animation may end at time T4. In the illustrated example of FIG. 2, the animation is started before the change in FPS rate is performed at time T2. Thus, the period between T1 and T2 may be associated with a period during which the FPS rate associated with the display client 131 is not based on the change in FPS rate associated with the touch event (e.g., at time T0) . For example, the FPS rate may be associated with an idle state of the display client 131 and/or a power-saving mode of the display client 131.

Furthermore, it should be appreciated that there may be a delay between the switching of the FPS rate (at time T2) and when the Vsync pulse is re-synched based on the updated FPS rate (at time T3) . For example, there may be a delay in processing by the display processor 127 in adjusting the period of the Vsync pulse for refreshing image frame currently being displayed by the display client 131 with a new image frame. For example, it may take approximately 100ms (or 6 frames) to adjust the period of the Vsync pulse. In particular, the images (including part of the animation between T1 and T4) displayed during this period (e.g., between time T2 and time T3) may be associated with jank and general lack of smoothness (e.g., delays or pauses in frame rendering or composition, which may be, for example, a perceptible pause in the rendering of a displayed interface) . Jank (e.g., stuttering, choppiness, or general lack of smoothness) may be result of a number of factors, such as, for example, a lack of synchronization between frame rendering and the display refresh rate. It should be appreciated that jank reduction is beneficial for display processing because if the display refresh latency is not stable, user experience may be negatively impacted. The animation may then end at time T4.

FIG. 3 is a block diagram 300 illustrating the example processing unit 120 of FIG. 1, the example display processor 127 of FIG. 1, and the example display client 131 of FIG. 1. In the illustrated example of FIG. 3, the processing unit 120 includes a user space 320 and a kernel space 325. The example kernel space 325 of FIG. 3 includes a display driver 330. The example display processor 127 includes a display control block 335 and a display interface 340. The example display client 131 includes display controller 345, a buffer 350, and a display 355.

The example block diagram 300 also includes a touch panel 305 including a touch controller 310 and one or more sensor (s) 315. Although shown separately in FIG. 3, it should be appreciated that in some examples, the touch panel 305 may be incorporated as a part of the display client 131. In the illustrated example of FIG. 3, the sensor (s) 315 may be configured to sense interactions between the user and the touch panel (e.g., via the display client 131) . As the user interacts with the display client 131, the sensor (s) 315 output signals to the touch controller 310 that indicate which sensor (s) were activated, how long a sensor was activated, a pressure associated with the sensor activation, etc. The example touch controller 310 may use the sensor output signals to determine that the user interacted with the touch panel 305 /display client 131. The touch controller 310 may then output a signal indicating the touch event. In an example, the touch controller 310 signals the touch event via a general purpose input/output (GPIO) pin. For example, a GPIO pin may be configured to transmit, via a GPIO signal, the touch event signal from the touch controller 310 to the display driver 330.

In the illustrated example of FIG. 3, the processing unit 120 includes the user space 320 and the kernel space 325. The user space 320 (sometimes referred to as an “application space” ) may include software application (s) and/or application framework (s) . For example, software application (s) may include operating systems, media applications, graphical applications, office suite applications, etc. Application framework (s) may include frameworks that may be used with one or more software applications, such as libraries, services (e.g., display services, input services, etc. ) , application program interfaces (APIs) , etc.

In the illustrated example of FIG. 3, the kernel space 325 includes the display driver 330. The display driver 330 may be configured to control the display processor 127. For example, the display driver 330 may determine one or more user input events based on user interactions with the touch panel 305. In some examples, the display driver 330 may cause the display processor 127 to change FPS rates based on, for example, the touch event signal.

In the illustrated example of FIG. 3, the display processor 127 includes the display control block 335 and the display interface 340. The display processor 127 may be configured to operate functions of the display client 131 based on the display driver 330. For example, the display control block 335 may be configured to receive instructions from the display driver 330 to change the FPS rate of the display client 131. In some examples, the display control block 335 may additionally or alternatively perform post-processing of image data provided by the processing unit 120.

The display interface 340 may be configured to cause the display client 131 to display image frames and to display the image frames at a particular rate (e.g., a particular FPS rate) . The display interface 340 may output image data to the display client 131 according to an interface protocol, such as, for example, the MIPI DSI (Mobile Industry Processor Interface, Display Serial Interface) .

In the illustrated example of FIG. 3, the display client 131 includes the display controller 345, the buffer 350, and the display 355. The display controller 345 may receive image data from the display interface 340 and store the received image data in the buffer 350. In some examples, the display controller 345 may output the image data stored in the buffer 350 to the display 355. Thus, the buffer 350 may represent a local memory to the display client 131. In some examples, the display controller 345 may output the image data received from the display interface 340 to the display 355.

In an example operation, the touch panel 305 detects a touch event via the sensor (s) 315 of the touch panel 305. The touch controller 310 generates a touch event signal based on the detected touch event. The touch controller 310 then outputs the touch event signal. In an example, the touch controller 310 outputs the touch event signal via a GPIO pin.

In the illustrated example, the touch event signal is provided directly from the touch controller 310 to the display driver 330. The display driver 330 may then determine to change the FPS rate of the display client 131 and without having to wait for the touch event signal to pass through different drivers, user spaces, and/or services (e.g., an application and/or a display HAL application) . In this way, the display driver 330 may determine the FPS rate (and/or the change in FPS rate) relatively quickly without waiting for other components of the device 104 to process the touch event signal (as shown in the example timeline 200 of FIG. 2) and the display refresh rate of the display client 131 may be updated relatively quickly. For example, providing the touch event signal directly from the touch controller 310 to the display driver 330 may be faster than a system that provides touch event data to a touch driver for interpreting the touch event data, provides the touch event data to a touch service for determining how to process the touch event data, provides the touch event data to one or more services of the user space to determine how to update the display based on the touch event data, and provides the touch event data to a kernel display driver to request changing the FPS rate of the display client 131. That is, it should be appreciated that the illustrated example provides example techniques for updating the display refresh rate without passing touch event data through a touch driver, a user space (e.g., an operating system, an application, and/or a display HAL application) , and then to the display driver.

In some examples, display driver 330 may generate an interrupt service routine (ISR) in response to the touch event signal. More specifically, for example, after receiving the touch event signal (via the GPIO signal) , the display driver 330 may output an ISR for use by the display driver 330 and/or the display control block 335 to determine whether to change the FPS rate of the display client 131. The display control block 335 may then change the FPS rate based on, for example, the ISR. That is, the ISR may trigger the change in the FPS rate of the display client 131. It should be appreciated that the determining of whether to change the FPS rate of the display client 131 may be performed by the touch controller 310, the display driver 330, the display control block 335, and/or the display controller 345.

The display control block 335 may be configured to output image frames to the display client 131 based on the display refresh rate determined by the display driver 330. The display driver 330 may output refresh rate information indicating the new display refresh rate (and/or a change in the display refresh rate) . The display control block 335 may receive the refresh rate information and cause the display interface 340 to output image frames to the display client 131 based on the refresh rate information (e.g., based on a new display refresh rate and/or a change in the display refresh rate) .

Furthermore, as disclosed above, the display client 131 may be configured in accordance with MIPI DSI standards. The MIPI DSI standard supports a video mode and a command mode. In examples where the display client 131 is operating in video mode, the display processor 127 may continuously refresh the graphical content of the display client 131. For example, the entire graphical content may be refreshed per refresh cycle (e.g., line-by-line) . In examples where the display client 131 is operating in command mode, the display processor 127 may write the graphical content of a frame to the buffer 350. In some such examples, the display processor 127 may not continuously refresh the graphical content of the display client 131. Instead, the display processor 127 may use a vertical synchronization (Vsync) pulse to coordinate rendering and consuming of graphical content at the buffer 350. For example, when a Vsync pulse is generated, the display processor 127 may output new graphical content to the buffer 350. Thus, the generating of the Vsync pulse may indicate when current graphical content at the buffer 350 has been rendered.

However, it should be appreciated that the generating of the Vsync pulse may include a period based on, for example, the current FPS rate of the display client 131. Thus, it should be appreciated that by the display driver 330 directly receiving the touch event signal (e.g., via the GPIO signal) from the touch controller 310, rather than via an application and/or a display HAL application, the disclosed techniques may more quickly re-synchronize the period of the Vsync pulses (e.g., within two frames) , which may also result in fewer frames being dropped due to, for example, a delay in the display driver 330 instructing the display processor 127 to change to a new FPS rate.

FIG. 4 illustrates an example display processing timeline 400, in accordance with one or more techniques of this disclosure. As shown in FIG. 4, with the disclosed techniques for processing a touch event (at time T0) , the performing of the FPS switching (at time T1) and the re-synchronizing of the Vsync pulse (at time T2) can be performed prior to the start of the animation (at time T3) . For example, it may take 1/60 of a second (e.g., 16.6ms) to receive the touch event (at time T0) , determine the new FPS, and perform the FPS switching (at time T1) . It may also take 2/60 of a second (e.g., 33ms) to perform the re-synchronizing of the Vsync pulse (at time T2) . Thus, the approximate time between receiving the touch event (at time T0) and the performing of the re-synchronizing of the Vsync pulse (at time T2) may be approximately 50ms, which may be less time than it takes to start the animation (at time T3) . Accordingly, the jank shown in FIG. 2 may not occur using the techniques disclosed herein.

Accordingly, the disclosed techniques facilitate refreshing the images on the display client 131 using the updated FPS rate and in synchronization with the corresponding Vsync pulse. As a result, the animation displayed by the display client 131, from the start of the animation (at time T3) to the end of the animation (at time T4) is relatively smooth.

Furthermore, the disclosed techniques facilitate adjusting the timing of the Vsync pulse within, for example, a timeframe of two frames. For example, the duration between the FPS switching (at time T1) and the re-synchronization of the Vsync pulse (at time T2) may correspond to two frames.

FIG. 5 illustrates an example flowchart 500 of an example method, in accordance with one or more techniques of this disclosure. The method may be performed by an apparatus, such as the device 104 of FIG. 1, the processing unit 120 of FIGs. 1 and/or 3, the display processor 127 of FIGs. 1 and/or 3, a GPU, and/or a video processor.

At 502, the apparatus may receive an interrupt indication of a touch event from a touch sensor via a GPIO signal, as described in connection with the example of FIG. 3. For example, the display driver 330 of the kernel space 325 may receive the GPIO signal directly from the touch controller 310 of the touch panel 305.

At 504, the apparatus may request a display processor to change an FPS rate of a display client based on the interrupt indication, as described in connection with the example of FIG. 3. In some examples, the request may be based on the received interrupt indication. For example, the display driver 330 may request the display processor 127, via the display control block 335, to change the display refresh rate of the display client 131.

At 506, the apparatus may change the FPS rate based on the request, as described in connection with the example of FIG. 3. For example, the display control block 335 of the display processor 127 may facilitate the change in the FPS rate based on the request. In some examples, the apparatus may change the FPS rate by adjusting the display refresh rate of the display client 131.

In some examples, the apparatus may change the FPS rate by, at 508, initiating an ISR within a kernel display driver, as described in connection with the example of FIG. 3. For example, the apparatus may initiate an IRS within the display driver 330 of the kernel space 325 based on the interrupt indication of the touch event and the GPIO signal.

In some examples, the apparatus may change the FPS rate by, at 510, triggering the change in the FPS rate, as described in connection with the example of FIG. 3. For example, the display driver 330 of the kernel space 325 may trigger the display control block 335 of the display processor 127 to change the FPS rate.

At 512, the apparatus may adjust a Vsync pulse based on the change in the FPS rate, as described in connection with the example of FIG. 3. For example, the display control block 335 of the display processor 127 may facilitate adjusting the Vsync pulse based on the change in the FPS rate. In some examples, the adjusting of the Vsync pulse may be performed within two frames, thereby reducing the associated with jank and/or lack of display smoothness.

FIG. 6 illustrates an example flowchart 600 of an example method, in accordance with one or more techniques of this disclosure. The method may be performed by an apparatus, such as the device 104 of FIG. 1, the processing unit 120 of FIGs. 1 and/or 3, the display processor 127 of FIGs. 1 and/or 3, a GPU, and/or a video processor.

At 602, the apparatus may receive an interrupt indication of a touch event from a touch panel via a GPIO signal, as described in connection with the example of FIG. 3. For example, the display driver 330 of the kernel space 325 may receive the GPIO signal directly from the touch controller 310 of the touch panel 305.

At 604, the apparatus may determine whether to change a current FPS rate of a display client based on the touch event, as described in connection with the example of FIG. 3. For example, the touch controller 310, the display driver 330, the display control block 335, and/or the display controller 345 may determine whether to change the current FPS rate of the display client 131. In some examples, the apparatus may determine whether to change the current FPS rate based on, for example, a duration or pressure associated with the touch event. For example, a soft touch (e.g., with relatively low pressure) may indicate a pausing of video content and, thus, it may not be beneficial to refresh the display client 131 at a relatively high rate. A hard touch (e.g., with relatively high pressure) may indicate a fast-forwarding or rewinding of the video content and, thus, it may be beneficial to refresh the display client 131 at a relatively high rate.

If, at 604, the apparatus determines not to change the current FPS rate of the display client, then, at 606, the apparatus may display frames via the display client at the current FPS rate.

If, at 604, the apparatus determines to change the current FPS rate of the display client, then, at 608, the apparatus may determine a new FPS rate in response to the indication, as described in connection with the example of FIG. 3. For example, the display driver 330 may determine the new FPS rate. In some examples, the current FPS rate may correspond to the display client 131 operating in the idle state. In some such examples, the apparatus may determine to increase the FPS rate of the display client 131 (e.g., from 30fps to 60fps) .

At 610, the apparatus may initiate a change in the FPS rate of the display client, as described in connection with the example of FIG. 3. For example, the display driver 330 may initiate the change in the FPS rate of the display client 131 based on the new FPS rate and transmit the request to the display processor 127.

At 612, the apparatus may adjust a Vsync pulse based on the change in the FPS rate, as described in connection with the example of FIG. 3. For example, the display control block 335 of the display processor 127 may facilitate adjusting the Vsync pulse based on the change in the FPS rate.

At 614, the apparatus may display frames via the display client at the new FPS rate, as described in connection with the example of FIG. 3. For example, the display client 131 may start displaying an animation at a display refresh rate based on the change in the FPS rate and the adjusted Vsync pulse.

FIG. 7 illustrates an example flowchart 700 of an example method, in accordance with one or more techniques of this disclosure. The method may be performed by an apparatus, such as the device 104 of FIG. 1 and/or the processing unit 120 of FIGs. 1 and/or 3.

At 702, the apparatus may receive an interrupt indication of a touch event from a touch panel via a GPIO signal, as described in connection with the example of FIG. 3. For example, the display driver 330 of the kernel space 325 may receive the GPIO signal directly from the touch controller 310 of the touch panel 305.

At 704, the apparatus may determine whether to change a current FPS rate of a display client based on the touch event, as described in connection with the example of FIG. 3. For example, the display driver 330 may determine whether to change the current FPS rate of the display client 131. In some examples, the apparatus may determine whether to change the current FPS rate based on a current operating state of the display client 131 and the touch event. For example, the current operating state of the display client 131 may be an idle state and the touch event may indicate that it would be beneficial to increase the display refresh rate.

If, at 704, the apparatus determines not to change the current FPS rate of the display client, then, at 706, the apparatus maintains the current FPS rate of the display client 131.

If, at 704, the apparatus determines to change the current FPS rate of the display client, then, at 708, the apparatus may determine a new FPS rate in response to the indication, as described in connection with the example of FIG. 3. For example, the display driver 330 may determine the new FPS rate. In some examples, the current FPS rate may correspond to the display client 131 operating in the idle state. In some such examples, the apparatus may determine to increase the FPS rate of the display client 131 (e.g., from 30fps to 60fps) .

At 710, the apparatus may initiate a change in the FPS rate of the display client, as described in connection with the example of FIG. 3. For example, the display driver 330 may initiate the change in the FPS rate of the display client 131 based on the new FPS rate and transmit the request (e.g., an ISR) to the display processor 127.

In one configuration, a method or apparatus for display processing is provided. The apparatus may be a display processor, a display processing unit (DPU) , a GPU, a video processor, or some other processor that can perform display processing. In some examples, the apparatus may be the processing unit 120 within the device 104, or may be some other hardware within the device 104, or another device. The apparatus may include means for receiving, at a display driver outside of a user space, an indication of a touch event from a touch sensor via a GPIO signal. The apparatus may further include means for determining an FPS rate of a display client based on the received indication. The apparatus may further include means for causing a change in the FPS rate of the display client based on the determined FPS rate. The apparatus may include means for the display driver receiving the GPIO signal directly from a touch controller of the touch sensor. The apparatus may further include means for requesting a display processor to change the FPS rate of the display client based on the determined FPS rate. The apparatus may further include means for initiating an ISR within the display driver based on the indication of the touch event. The apparatus may also include means for transmitting the ISR to a display processor. The apparatus may further include means for adjusting a Vsync pulse based on the determined FPS rate. The apparatus may also include means for determining whether to change a current FPS rate of the display client based on the indication of the touch event. The apparatus may also include means for determining an operating state of the display client. The apparatus may further include means for determining to change the current FPS rate of the display client when the display client is operating in an idle state. The apparatus may also include means for displaying an animation via the display client, and where the causing of the change in the FPS rate of the display client occurs prior to a start of the displaying of the animation.

The subject matter described herein can be implemented to realize one or more benefits or advantages. For instance, the described display and/or graphics processing techniques can be used by a display processor, a display processing unit (DPU) , a GPU, or a video processor or some other processor that can perform display processing to implement the FPS rate switching techniques disclosed herein. This can also accomplished at a low cost compared to other display or graphics processing techniques. Moreover, the display or graphics processing techniques herein can improve or speed up data processing or execution. Further, the display or graphics processing techniques herein can improve resource or data utilization and/or resource efficiency. For examples, aspects of the present disclosure can change an FPS rate without waiting for refresh rate information from an application and/or a display HAL application.

Further disclosure is included in the Appendix.

In accordance with this disclosure, the term “or” may be interrupted as “and/or” where context does not dictate otherwise. Additionally, while phrases such as “one or more” or “at least one” or the like may have been used for some features disclosed herein but not others, the features for which such language was not used may be interpreted to have such a meaning implied where context does not dictate otherwise.

In one or more examples, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. For example, although the term “processing unit” has been used throughout this disclosure, such processing units may be implemented in hardware, software, firmware, or any combination thereof. If any function, processing unit, technique described herein, or other module is implemented in software, the function, processing unit, technique described herein, or other module may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media may include computer data storage media or communication media including any medium that facilitates transfer of a computer program from one place to another. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, . Disk and disc, as used herein, includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. A computer program product may include a computer-readable medium.

The code may be executed by one or more processors, such as one or more digital signal processors (DSPs) , general purpose microprocessors, application specific integrated circuits (ASICs) , arithmetic logic units (ALUs) , field programmable logic arrays (FPGAs) , or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor, ” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Also, the techniques could be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC) or a set of ICs, e.g., a chip set. Various components, modules or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily need realization by different hardware units. Rather, as described above, various units may be combined in any hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.

Various examples have been described. These and other examples are within the scope of the following claims.

Appendix

Trigger FPS switching directly by touch IC GPIO interrupt to reduce FPS switching response time and solve frame drop

Introduction --High Frame Rate Display Panel Status in Mobile Devices

1.120 HZ display panels are applied to mobile devices since Jun e, 2017. Some smartphones use 120 HZ and 90 Hz panels to smartphones in 2017-2019. In current in-developing high tier smart phones projects, 120HZ is onebasic display configuration.

Introduction --High Frame Rate Display Panel Status in Mobile Devices

Benefits of High FPS :

a) Improvement intouch to photon latency. Some graphics system b asically use Vsync as pulse, speeding FPS pulse helped quite a lot.

b) Better UI smoothness.

1) High FPS display reduces motion blur which caused by slow response time of LCD and OLED.

2) High FPS makes animations or motions more clear to end users.

Shortcomings of High FPS :

a) Power costs

b) Content FPS mismatching. Most games are 60 HZ and most video clips are 30 FPS or 25 FPS. This mismatching will lead to visual jank.

Introduction--FPS switching , mandatory for High FPS mobile de vices

Dynamic FPS switching design:

a) To keep benefits and compensate shortcomings of High FPS disp lay panels , dynamic FPS switching is mandatory for High FPS mobile device.

The basic guidelines

For different use cases , use different FPS configs.

Visual Seamless real time FPS switching.

Above two guidelines affects each other sometimes while independent in some specific use cases.

FPS switching status -----------Example

a) Provide end user FPS settings options, 90 HZ and 60 HZ

b) Application dependent FPS setting. Launcher and Windows man ager detects active application and window.

If the application belongs to High FPS application lists, switch to 90 HZ . This list contains some specific 90 HZ games.

If the application or windows belong to normal FPS application lists, switch to 60 HZ , This lists contains most of 60 HZ popular games

System UI uses default 90 HZ FPS

c) FPS switch speed. UI setting trigger switch from 60 HZ to 90 HZ , it costs 206 ms.

FPS switching status -----------Another example

The status analysis is from Android Q AOSP source codes + sm8150 MTP

a) The device configured to 90HZ , 60HZ , 30 HZ

b) Touch event boost and refresh idle fallback.

Video content dependent FPS switching

c) FPS switch speed. Touch event triggers switching from 60 HZ to 90 HZ , it costs 440 ms.

1)-----------FPS switching delay leads to many shortcomings

1. Real time FPS switching is essential to high FPS device. Th e FPS switching delay will reduce high FPS benefits. Both touch to photon latency and UI smoothness will be reduced by FPS switching delay. FPS switching long time delay will bring frame drop and UI jankside-effects as well.

2. In current devices , the UI setting trigger has shorter FPS s witching delay compared with touch event trigger FPS switching delay.

3. Touch event trigger bring in much better end user experiences benefiting from its automatic FPS control. The touch event trigger has quite longer FPS switching delay. In sm8150 , Android Q , its FPS switching delay is about 440 ms.

440ms FPS switching delay is not good and it brings in large touch delay and UI jank.

It would, thus, be beneficial to optimize and reduce touch trigger FPS switching delay!

2)-----------DFPS and PLL re-lock leads to frame drop

1. Both command mode and video mode needs to re-configure DSI PL L and switch DSI clock while FPS switching to get better power saving. For example , FPS switch from 30HZ to 120Hz , needs to re-config DSI PLL and bit clock from 0.25G+ to 1G+ bps. This dynamic DSI clock change with PLL turn off/turn on , needs 5 ms+ time.

2. In current SW flow , this 5 ms+ will lead to 1 or 2 frame dro ps. This is because FPS switching 400 ms+ delay is too large compared with UI animation 60 ms+ to uch response time

3. Even DSI clock kept non-chang ed , the display panel doing FPS switching still needs 2ms -20ms . In high FPS , this will lead to frame drops as well.

4. In summary , performing physical display panel FPS switching during frame refreshing may lead to frame drops , janksand unsmooth.

Application based touch trigger solution

Example techniques for “Trigger FPS switching directly by touch GPIO interrupt ”

“Reduce SurfaceFlingerVsyncsample frames”

Example Benefits of example techniques -------solved problem 1 and 2

1. Example techniques provide FPS switching delay of 50 ms (typical value) . The FPS switching finished before animation starting. The FPS switching has no visual loss now

2. Frame drop and janksolved ! PL L turn off/turn on 5ms+ happens before frame starts to refresh , there is no jankor frame drop at all.

3. Using the disclosed techniqu es, physical display panel FPS switching happens before frame refreshing. So, during frame refreshing, the FPS switching is already finished. Therefore, the unsmooth shortcomings are solved. It is because during frame refreshing, there is no FPS switching.

Claims

A method of display processing, comprising:

receiving, at a display driver outside of a user space, an indication of a touch event from a touch sensor via a general-purpose input/output (GPIO) signal;

determining a frame per second (FPS) rate of a display client based on the received indication; and

causing a change in the FPS rate of the display client based on the determined FPS rate.
The method of claim 1, wherein the display driver is included in a kernel space of a processing unit, and the kernel space is different than the user space.
The method of claim 1, wherein the display driver receives the GPIO signal directly from a touch controller of the touch sensor.
The method of claim 1, wherein the indication of the touch event is an interrupt.
The method of claim 1, further comprising:

requesting a display processor to change the FPS rate of the display client based on the determined FPS rate.
The method of claim 1, wherein the causing of the change in the FPS rate of the display client includes:

initiating an interrupt service request (ISR) within the display driver based on the indication of the touch event; and

transmitting the ISR to a display processor.
The method of claim 1, further comprising:

adjusting a vertical synchronization (Vsync) pulse based on the determined FPS rate.
The method of claim 7, wherein the adjusting of the Vsync pulse is performed within a timeframe of two frames.
The method of claim 1, further comprising:

determining whether to change a current FPS rate of the display client based on the indication of the touch event, and

wherein the determining of the FPS rate of the display client is performed in response to a determination to change the current FPS rate of the display client.
The method of claim 9, wherein the determining of whether to change the current FPS rate of the display client includes determining an operating state of the display client.
The method of claim 9, further comprising:

determining to change the current FPS rate of the display client when the display client is operating in an idle state.
The method of claim 1, further comprising:

displaying an animation via the display client, and wherein the causing of the change in the FPS rate of the display client occurs prior to a start of the displaying of the animation.
An apparatus for display processing, comprising:

a memory; and

at least one processor coupled to the memory and configured to:

receive, at a display driver outside of a user space, an indication of a touch event from a touch sensor via a general-purpose input/output (GPIO) signal;

determine a frame per second (FPS) rate of a display client based on the received indication; and

cause a change in the FPS rate of the display client based on the determined FPS rate.
The apparatus of claim 13, wherein the display driver is included in a kernel space of a processing unit, and the kernel space is different than the user space.
The apparatus of claim 13, wherein the at least one processor is further configured to cause the display driver to receive the GPIO signal directly from a touch controller of the touch sensor.
The apparatus of claim 13, wherein the at least one processor is further configured to:

request a display processor to change the FPS rate of the display client based on the determined FPS rate.
The apparatus of claim 13, wherein the at least one processor is configured to cause the change in the FPS rate of the display client by:

initiating an interrupt service request (ISR) within the display driver based on the indication of the touch event; and

transmitting the ISR to a display processor.
The apparatus of claim 13, wherein the at least one processor is further configured to:

adjust a vertical synchronization (Vsync) pulse based on the determined FPS rate.
The apparatus of claim 18, wherein the at least one processor is further configured to adjust the Vsync pulse within a timeframe of two frames.
The apparatus of claim 13, the at least one processor is further configured to:

determine whether to change a current FPS rate of the display client based on the indication of the touch event, and

wherein the determining of the FPS rate of the display client is performed in response to a determination to change the current FPS rate of the display client.
The apparatus of claim 20, wherein the at least one processor is configured to determine whether to change the current FPS rate of the display client by determining an operating state of the display client.
The apparatus of claim 20, the at least one processor is further configured to:

determine to change the current FPS rate of the display client when the display client is operating in an idle state.
The apparatus of claim 13, the at least one processor is further configured to:

display an animation via the display client, and wherein the causing of the change in the FPS rate of the display client occurs prior to a start of the displaying of the animation.
A computer-readable medium storing computer executable code for display processing, comprising code to:

receive, at a display driver outside of a user space, an indication of a touch event from a touch sensor via a general-purpose input/output (GPIO) signal;

determine a frame per second (FPS) rate of a display client based on the received indication; and

cause a change in the FPS rate of the display client based on the determined FPS rate.