I found an 8 years old bug in Xorg | Hacker News Reader

I found an 8 years old bug in Xorg

trace.yshui.dev

124 pointsyshui34 comments

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.

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

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...)

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 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.

Poor audio systems are also to blame for this

You want a 3.1 system (at least) and increase the 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.

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):

   aformat=channel_layouts=stereo, compand=0 0:1 1:-90/-900 -70/-70 -30/-9 0/-3:6:0:0:0

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

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.

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.

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.

In Xorg timescales that's probably one of the youngest bugs :D

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!

Reply on news.ycombinator.com