FR: Private Mode 2026 to resolve 'flicker' in pw-top - Health risk to users, please respond.
- PipeWire version: Master
- Distribution and distribution version: openSUSE Tumbleweed
- Desktop Environment: KDE Plasma
- Kernel version: 6.5.4-1-default
Description of Problem:
Extreme flickering in pw-top
How Reproducible:
100%, though the severity depends on the terminal emulator or multiplexer which hosts pw-top
Steps to Reproduce:
- Use a fast, GPU accelerated Wayland terminal emulator like foot or kitty, or just konsole will also work if you are a KDE user
- Use a terminal multiplexer such as zellij (tmux will also do this, but it is far more evident in zellij)
- start pw-top, within zellij, wait a few seconds
Additionally/alternatively:
- Use foot terminal emulator.
- In foot.ini, add the following configuration, in order to disable delayed rendering and allow pw-top to draw at will:
[tweak]
delayed-render-lower=0
delayed-render-upper=0
- Start foot and run pw-top. Immediate, extreme flicker ensues.
Actual Results:
Extreme screen flicker to the degree of being health hazard as it is a potential migraine or epilepsy trigger.
Expected Results:
No flicker, happy epileptic PW users
Additional Info (as attachments):
TL;DR this is a feature request for private mode 2026 implementation in pw-top,
and/or some other approach to delay/synchronise/atomicise screen updates, in order to avoid potentially dangerous screen flicker.
2026, What is it?
This is the official specification: https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec by the original author. There is a good summary of the state and implementation of the feature here: https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036 with links following from there to various discussions working to officially standardise the feature.
Why though?
pw-top has a tendency to flicker somewhat when updating the screen. Since pw-top provides updates to data which can change quite rapidly and regularly, this results in the application drawing at a frequency which can be difficult or impossible for the terminal emulator to handle elegantly, resulting in segmented updates to the display that appear as 'flicker' or 'tearing'. I have not fully analysed the code, but on a quick look, I did not initially note any attempts to avoid screen flicker or control/limit the timing of updates to the screen.
Having spent some time in my career working in hospitals (as an IT guy, I am not a Doctor), I'm aware that these same optical effects which trigger my severe migraines, can be triggers for epilepsy, which is quite serious and, as a result of witnessing such events (a young boy who watched the wrong TV show and is in heaven now), I feel strongly compelled to try to mitigate this issue. I hope you can help me in this endeavour.
Is this really a problem?/Works for me!
I love Pipewire and everything about it so please, don't take this as an attack on pw-top, or feel bad for me, I'll be fine.... But I do worry for the sake of others. I initially logged this as an issue with zellij, since that was the application where I saw pw-top's flicker go from "mildly annoying thing I had noticed sometimes in various terminals" to "I just spent two days partially paralyzed and blind, in agony, and violently ill". My first thought was of that young boy, and I'm sure with the ubiquity of pipewire as it is, there will be a segment of the userbase who are sufferers of epilepsy.
zellij's developer was very kind about the whole experience, and foot's developer kindly dropped by to help share some insight into this. Being a terminal developer of high order (he makes the fastest terminal emulator on linux, if you haven't tried it I recommend it, you might really like it!) he was very well informed on the matter.
He explained to me that the reason why the flicker was worse in certain cases was due to different terminal emulators' and terminal multiplexers' handling of screen updates. Essentially, it rests upon the terminal emulator/muxer, to ensure that flicker from client applications does not occur, and without this feature I'm requesting, they must do so without having any awareness of the application's intent to begin or end an update.
Foot itself, in its default configuration. does not exhibit the flicker, as a result of an implementation of delaying updates by a configurable timeframe (up to a limit, to avoid lock-ups); nor is the flicker evident in kitty (I do not know the details of how kitty avoids the flicker but I gather that it is again some kind of delayed update mechanism) however running zellij within any of these terminal emulators I tested, the flicker from pw-top was quite unbearable and had serious effects on my physical wellbeing, which honestly just makes me worry about what it would do to somebody with a more serious illness than my own.
So what can we do about it?
Taking advice from foot's developer, he has suggested that the way to resolve this issue is a pending standard which has already become a de-facto standard though wide adoption among terminal emulators, that being 'private mode 2026'. The effect as I understand it is that the application signals its intentions to begin and to end a screen update, thus allowing the terminal emulator to display said updates appropriately.
I am not a terminal dev, this is a long way from my wheelhouse, but as far as I gather this may be as simple to implement, as sending an escape sequence near the start of pw-top's do_refresh() function, and another escape sequence near the end, respectively marking the beginning and end of the display update. Beyond that, it is up to the terminal emulator to support the feature or not (and as you can see from the link above, it is quite widely implemented among the top terminal emulators, and naturally, I have made a FR to zellij to add support for it also)
I very much hope you'll have some interest in adding this feature. If you are willing to have the feature added, while I'm not entirely experienced with this, I am very comfortable with the programming languages involved, so I would be happy to attempt to write the code and submit an MR if you would prefer it and it would avoid adding to your workload, or equally satisfied to step aside and get out of the way and let your team do your usual wonderful work. Anything that I can do to assist with this, just say the words and consider it done.
If you have any thoughts on this I would be very glad to hear it. Please let me know what you think.