Disable timing estimation based pacing by default, as it might not work
well across drivers, and might have subtle bugs.
You can try setting `PICOM_DEBUG=smart_frame_pacing` if you want to try
it out.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Factored out vblank event generation, add abstraction over how vblank
events are generated. The goal is so we can request vblank events in
different ways based on the driver we are running on.
Tried to simplify the frame scheduling logic, we will see if I succeeded
or not.
Also, the logic to exclude vblank events for vblank interval estimation
when the screen off is dropped. It's too hard to get right, we need to
find something robust.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This is where we keep temporary, short living, private debug options.
Adding and removing command line and config file options are
troublesome, and we don't want people adding these to their config
files.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
We unredirect because we receive bad vblank events, and also vblank
events at a different interval compared to when the screen is on. But it
is enough to just not record the vblank interval statistics when the
screen is off.
Although, unredirecting when display is off can also fix the problem
where use-damage causes the screen to flicker when the display is turned
off then back on. So we need something else for that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously everytime we receive a vblank event, we always request a new
one. This made the logic somewhat simpler. But this generated many
useless vblank events, and wasted power. We only need vblank events for
two things:
1. after we rendered a frame, we need to know when it has been displayed
on the screen.
2. estimating the refresh rate.
This commit makes sure we only request vblank events when it's actually
needed.
Fixes#1079
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make it simpler to stop requesting PresentCompleteNotify when there is
nothing to render.
Related: #1079
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
I mistakenly assumed that PresentCompleteNotify event signifies the end
of a vblank (or the start of scanout). But actually this event can in
theory in sent at any point during a vblank, with its timestamp pointing
to when the end of vblank is. (that's why we often find the timestamp to
be in the future).
Add a delay so schedule_render is actually called at the end of vblank,
so it doesn't mistakenly think the render is too slow to complete.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
paint_process would return NULL for both of these cases, but we should exit in
the failure case, and continue going in the other.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This usually means there is another compositor running. If we don't do
this picom will spin forever.
Fixes#1104
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
One annoying thing is C23 still defines auto as a storage class despite
it now being used for type inference. As a consequence we must write
"auto const" instead of the more natural "const auto".
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
the corresponding regions need to be resized once for each window in the
stack above the damaged window including the damaged window itself. we
were off by one.
