Picom has an awesome feature [0] that, for the sake of all our eyes, should come by default on every device with a screen. It can continuously adjust the brightness of individual windows by averaging all the pixels in that window. It's great for defending against "flashbangs" (when a new tab burns your eyes with a blank white screen).
Yes!
It annoys me when a scene with characters shouting is much louder than a scene where characters are talking with hushed voices, as an example.
We know a shout was louder at the source, but the decibel level at our ears is proportional to 1/distance squared, meaning hushed voices aren't necessarily any quieter "in real life".
I'd prefer suspenseful and dramatic scenes both play at similar, comfortable levels.
I don't want to have to adjust the volume up and down so I can understand one scene and then not have it be disturbingly loud in the next.
In practice, I just use subtitles to circumvent the "difficult to understand" problem.
What you're describing is called dynamic range compression, and mpv can be configured to do this in multiple ways.
Back in the physical media days, it was pretty common for DVD/Bluray players to include this feature. Unfortunately it's not something that streaming app developers thought twice about. Your TV or streaming box also may or may not have the feature.
It's a problem for me between being half deaf anyway and Google not adjusting source streams to any sort of minimum decibel level. So listening to the local Pacifica station with no adjustment is about half the loudness of the local NPR station. Pleas to correct the audio level have fallen (heh) on deaf ears, so my donations and my listening has moved elsewhere. Sorry, local radio. I'd support you if you'd support me.
Doesn't that depends in the sound system setup ie hardware? I tried vehemently to fix it once with JamesDSP with no avail. My understanding then was the need for hardware support like Dolby or something. It was always an issue with music and dialog.
It's interesting that even podcasts, which you'd think would be more focused on audio considerations, don't do this, either. I'm mostly thinking of Dan Carlin's podcasts, where sometimes he goes a weee bit quiet. (And Shadows of Utopia, which I have to jack up the volume for the entirety of)
I'm watching a tv show, and while I'm sure a crying baby is appealing to a parent to the point they'll run at it, I'm now sufficiently annoyed that I'm just skipping past the crying baby storyline.
I have a 3.1 system and it's still terrible on many movies made after 2010ish.
P.S.
Even properly mastered content will not work well in a noisy environment (e.g. a car or if you have a dozen fans going because it's summer). Here's my ffmpeg filter for such situations (including a stereo downmix, for those without a center channel):
No: The problem is directors who love mumbling, audio people who have no idea how to record and balance audio properly, and media players that can't or aren't configured to properly downmix audio tracks as appropriate.
It is absolutely possible and honestly standard fare to have properly balanced audio playing on the $1 tin cans found in TVs and laptops.
No, you'd be surprised at all the random crap they put on the center channel nowadays. You just need an equalizer and use it to boost the frequencies of human speech. A lot of AVRs call this "dialogue enchancer", but you can do it easily in software
> Basically when a window is created, we receive an event. After getting that event, we lock the X server, then ask it about the new window. And sometimes, the window is just not there
Relying on this sounds like a race condition even if the lock is working. In the time between you process the event and getting the lock, the window could have been destroyed.
The immediate destruction of client resources even under server grab is not new functionality to the epoll port; it behaved the same under the old select-based loop, too. It might be a bug, but that's how it's always behaved.
It shouldn't be too hard to fix if you want to try, either; check client->ignoreCount > 0 when handling X_NOTIFY_ERROR before calling CloseDownClient.
Yeah, my honest reaction to the title was something like: that's a surprisingly young bug for that code base; I'm used to seeing headlines about finding X bugs that have been in there for literally decades.
> I could attach a debugger to the X server, however, debugging the X server pauses it, which would be a problem if I was debugging from inside that X session. Beside that, window destruction happens quite often, which can be prohibitive for manual debugging. It's still possible with a remote ssh connection, and gdb scripting, but it's inconvenient.
I will definitely look into eBPF and uprobe mentioned in the article, I don't know about them. But wouldn't something like XNest (or XWayland?) help with debugging X? You'd debug an X server running in a window comfortably from your real environment and display server without it being disrupted by the debugging session.
> It's still possible with a remote ssh connection, and gdb scripting, but it's inconvenient.
In this situation, don't gdb breakpoint command lists give you exactly what you need (printing stack traces at certain points) with minimal effort? Nothing wrong with using different tools, but it's not clear if that option was considered.
As they mention, the Window Manager, being the authority on which windows are displayed would obviously have that information. Picoms issue is that it is seperate from the WM and does not have access to that, it needs to go through the X server to discover the windows.
Picom has an awesome feature [0] that, for the sake of all our eyes, should come by default on every device with a screen. It can continuously adjust the brightness of individual windows by averaging all the pixels in that window. It's great for defending against "flashbangs" (when a new tab burns your eyes with a blank white screen).
0: https://github.com/yshui/picom/blob/ae73f45ad9e313091cdf720d...
Interesting feature! Wish I had that option on my devices, combined also with something similar for sounds.
Yes! It annoys me when a scene with characters shouting is much louder than a scene where characters are talking with hushed voices, as an example.
We know a shout was louder at the source, but the decibel level at our ears is proportional to 1/distance squared, meaning hushed voices aren't necessarily any quieter "in real life". I'd prefer suspenseful and dramatic scenes both play at similar, comfortable levels. I don't want to have to adjust the volume up and down so I can understand one scene and then not have it be disturbingly loud in the next. In practice, I just use subtitles to circumvent the "difficult to understand" problem.
What you're describing is called dynamic range compression, and mpv can be configured to do this in multiple ways.
Back in the physical media days, it was pretty common for DVD/Bluray players to include this feature. Unfortunately it's not something that streaming app developers thought twice about. Your TV or streaming box also may or may not have the feature.
It's a problem for me between being half deaf anyway and Google not adjusting source streams to any sort of minimum decibel level. So listening to the local Pacifica station with no adjustment is about half the loudness of the local NPR station. Pleas to correct the audio level have fallen (heh) on deaf ears, so my donations and my listening has moved elsewhere. Sorry, local radio. I'd support you if you'd support me.
Doesn't that depends in the sound system setup ie hardware? I tried vehemently to fix it once with JamesDSP with no avail. My understanding then was the need for hardware support like Dolby or something. It was always an issue with music and dialog.
Unfortunatly cinemas either don't use MPV or don't use this feature, so while dialog is audible, gunfire is often way too loud for me
Huh, I actually want this when I'm at the cinema, for immersion. Just not when I'm watching a movie at home at 11pm.
It's interesting that even podcasts, which you'd think would be more focused on audio considerations, don't do this, either. I'm mostly thinking of Dan Carlin's podcasts, where sometimes he goes a weee bit quiet. (And Shadows of Utopia, which I have to jack up the volume for the entirety of)
(insert caveats about: artistic effect; I have zero audio engineering experience; podcasters definitely do some things in this vein e.g. https://www.reddit.com/r/podcasting/comments/10oqvpm/podcast...)
I'm watching a tv show, and while I'm sure a crying baby is appealing to a parent to the point they'll run at it, I'm now sufficiently annoyed that I'm just skipping past the crying baby storyline.
Part of this is psychoacoustics... Our hearing sensitivity is peaked near a crying baby frequency regardless of dBa.
Poor audio systems are also to blame for this
You want a 3.1 system (at least) and increase the center channel
I have a 3.1 system and it's still terrible on many movies made after 2010ish.
P.S.
Even properly mastered content will not work well in a noisy environment (e.g. a car or if you have a dozen fans going because it's summer). Here's my ffmpeg filter for such situations (including a stereo downmix, for those without a center channel):
No: The problem is directors who love mumbling, audio people who have no idea how to record and balance audio properly, and media players that can't or aren't configured to properly downmix audio tracks as appropriate.
It is absolutely possible and honestly standard fare to have properly balanced audio playing on the $1 tin cans found in TVs and laptops.
No, you'd be surprised at all the random crap they put on the center channel nowadays. You just need an equalizer and use it to boost the frequencies of human speech. A lot of AVRs call this "dialogue enchancer", but you can do it easily in software
There is a preset for EasyEffects which can handle that: https://github.com/Digitalone1/EasyEffects-Presets
I haven't tried it for music, but for videos it works pretty well.
> Basically when a window is created, we receive an event. After getting that event, we lock the X server, then ask it about the new window. And sometimes, the window is just not there
Relying on this sounds like a race condition even if the lock is working. In the time between you process the event and getting the lock, the window could have been destroyed.
I don't know if it is sufficient to prevent the race, but the article does mention that they check for DestroyNotify events after the grab.
Ooh, that sounds good. I must have missed that part.
The immediate destruction of client resources even under server grab is not new functionality to the epoll port; it behaved the same under the old select-based loop, too. It might be a bug, but that's how it's always behaved.
It shouldn't be too hard to fix if you want to try, either; check client->ignoreCount > 0 when handling X_NOTIFY_ERROR before calling CloseDownClient.
By Xorg standards, "8 years old" is basically brand new.
Yeah, my honest reaction to the title was something like: that's a surprisingly young bug for that code base; I'm used to seeing headlines about finding X bugs that have been in there for literally decades.
> I could attach a debugger to the X server, however, debugging the X server pauses it, which would be a problem if I was debugging from inside that X session. Beside that, window destruction happens quite often, which can be prohibitive for manual debugging. It's still possible with a remote ssh connection, and gdb scripting, but it's inconvenient.
I will definitely look into eBPF and uprobe mentioned in the article, I don't know about them. But wouldn't something like XNest (or XWayland?) help with debugging X? You'd debug an X server running in a window comfortably from your real environment and display server without it being disrupted by the debugging session.
> It's still possible with a remote ssh connection, and gdb scripting, but it's inconvenient.
In this situation, don't gdb breakpoint command lists give you exactly what you need (printing stack traces at certain points) with minimal effort? Nothing wrong with using different tools, but it's not clear if that option was considered.
So, how has this been resolved? Has the bug been fixed now?
See for yourself:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1691
Thanks.
> To put it simply, picom needs to fetch the window tree from X. But there is no way to get the whole tree in one go
There are a lot of WMs who offer a window list (twm, fvwm). Maybe the guy shall take a look how they do it.
And requests to the X server are not syncroneus.
As they mention, the Window Manager, being the authority on which windows are displayed would obviously have that information. Picoms issue is that it is seperate from the WM and does not have access to that, it needs to go through the X server to discover the windows.
In Xorg timescales that's probably one of the youngest bugs :D
There are undoubtedly flaws in Xorg dating to this and each of the previous four decades.
Planning on fixing this bug? :-)
Interesting article, although it could use some more hyperlinks, e.g. to the bug.
I don’t understand why mention he was using .NET with Wine if not going to tell us why. Just silly
EDIT: Downvote but don't respond. Even sillier!