That's not how that term works. Input latency/lag refers to the time differential between triggering some kind of input and the action of that input showing up on your screen.
you described end-to-end latency, input latency + processing latency + output latency.
input latency is a measure of latency between the human input and the computer receiving the input.
output latency measures the time between a computer commanding a certain pixel to change color on the screen and the color change actually taking place.
It's not my fault these terms are often used incorrectly.
Most of the time, what you see when you see someone test "input latency" is that person actually testing end-to-end latency, which is input latency + processing latency + output latency, as it is difficult (but not impossible) to test only one of these without special hardware. testing all three at once is easy.
A proper input latency test would be (for example) some external tool sending keypresses to a computer and measuring (via a hardware debugger or some other hardware-level tooling) how long it takes for the program you are interested in to receive that input.
As stated previously, output latency is the time between your program commanding something on the screen to change and that change actually happening.
there's a third latency in this stack, and that's your program itself. how long between the time it has received an input before it commands an output device to change its output. processing latency.
for the purposes of end-to-end latency testing hardware, the processing latency is effectively zero.
all three of those stack up to become "end-to-end latency" which is what most tooling available to end users measures.
None.
It introduces output latency, not input latency.
That's not how that term works. Input latency/lag refers to the time differential between triggering some kind of input and the action of that input showing up on your screen.
you described end-to-end latency, input latency + processing latency + output latency.
input latency is a measure of latency between the human input and the computer receiving the input.
output latency measures the time between a computer commanding a certain pixel to change color on the screen and the color change actually taking place.
It's not my fault these terms are often used incorrectly.
Most of the time, what you see when you see someone test "input latency" is that person actually testing end-to-end latency, which is input latency + processing latency + output latency, as it is difficult (but not impossible) to test only one of these without special hardware. testing all three at once is easy.
A proper input latency test would be (for example) some external tool sending keypresses to a computer and measuring (via a hardware debugger or some other hardware-level tooling) how long it takes for the program you are interested in to receive that input.
As stated previously, output latency is the time between your program commanding something on the screen to change and that change actually happening.
there's a third latency in this stack, and that's your program itself. how long between the time it has received an input before it commands an output device to change its output. processing latency.
for the purposes of end-to-end latency testing hardware, the processing latency is effectively zero.
all three of those stack up to become "end-to-end latency" which is what most tooling available to end users measures.