Yup, depending on how stressed the EPDC/PXP is, but since none of us are really doing anything heavy on that front, except possibly for the virtual keyboard, where a wait_for mechanism doesn't really have a place anyway
.
(The gist of the delay depends on the wfm mode, rather than the region size. And, of course, of the update mode for wfm modes that do flash).
Note that the ioctl itself generally returns "late", (i.e., the screen has already visually finished flashing for quite a few dozen ms at least).
IIRC, it's using the generic wait_for kernel macros, so the logic flow is mostly readable by mere mortals in the epdc sources.
----
FBInk prints the actual delay in an accurate-ish manner (because jiffies :/).
(/!\: Mk. 7 kernels use a smaller timeout, c.f., the _mk7 codepath).
----
It's generally only useful around FULL updates (either before, or after, or both), or before an A2 one you *really* don't want to let get merged w/ anything else.
IIRC, on Kobo, the stock reader does it *after* FULL updates, and possibly ony the full-screen ones at that.
----
Fun fact: Kindle kernels have a WAIT_FOR_SUBMISSION variant, which lets 'em do very fancy stuff with the virtual keyboard and A2 updates in general with much more accuracy.
----
FWIW, KOReader's emulator basically just sticks a configurable sleep in the codepath that emulates flashing updates.