Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I found an 8 years old bug in Xorg

trace.yshui.dev

Post reply on HN
Print view View original

1–10 of 37 posts

Re: I found an 8 years old bug in Xorg

#2

Post by thenbe »

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

Re: I found an 8 years old bug in Xorg

#3

Post by kinow »

thenbe wrote: post #2

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.

Re: I found an 8 years old bug in Xorg

#4

Post by TillE »

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

Re: I found an 8 years old bug in Xorg

#5

Post by asveikau »

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

Re: I found an 8 years old bug in Xorg

#6

Post by celrod »

kinow wrote: post #3
thenbe wrote: post #2

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.

Re: I found an 8 years old bug in Xorg

#7

Post by marmight »

asveikau wrote: post #5

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

Re: I found an 8 years old bug in Xorg

#8

Post by aeadio »

celrod wrote: post #6
kinow wrote: post #3

Earlier quoted context omitted.

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 d…

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.

Post reply on HN