Open nitrotol opened 1 day ago
Wow, I've never heard anything like that 😧
Do you have two screens? Does it reproduce if you only leave one of them in the config?
Yeah, I have dual screen laptop
RUST_LOG=debug wluma
[2024-10-22T18:06:33Z DEBUG wluma] Using Config {
als: Iio {
path: "/sys/bus/iio/devices",
thresholds: {
20: "dark",
0: "night",
500: "bright",
80: "dim",
800: "outdoors",
250: "normal",
},
},
output: [
Backlight(
BacklightOutput {
name: "eDP-1",
path: "/sys/class/backlight/intel_backlight",
capturer: Wlroots,
min_brightness: 1,
},
),
],
}
[2024-10-22T18:06:33Z INFO wluma] Continue adjusting brightness and wluma will learn your preference over time.
[2024-10-22T18:06:33Z DEBUG wluma::frame::capturer::wlroots] Using output 'Samsung Display Corp. 0x419D (eDP-1)' for config 'eDP-1'
Flickering still persist
I cannot possibly imagine how we can be affecting screen contents if all we do is receive a frame and copy it into a new image for further professing ☹️
What if you replace this entire part with let result = 0;
, does flickering go away? This maps the frame but doesn't copy it.
Or what if you comment out this part, does the flickering go away? This is basically receiving frames and not doing anything with them at all.
Changes in vulkan.rs
- flickering still persist
Changes in wlroots.rs
- no changes, flickering still there
Maybe this is not about image as is, maybe it related to change backlight so fast? But if it is, why I have black rectaggles here and there sometimes?
I did not expect that flickering would persist with changes to vulkan.rs
!
Let's comment one more line and see if it changes anything, replace all of this please with let result = 0;
, does it make a difference?
Similarly to test your idea that it is backlight change that could be the culprit, you could maybe try to replace this part with state.controller.as_mut().unwrap().adjust(0)
:
By the way, I just pushed some major update to main
branch, it should not have any difference whatsoever, but just so you know why references above have changed.
First case - error[E0425]: cannot find value
frame_imagein this scope
If keep line 201 - no changes, it still flicker
Please note that all previous tests I'm doing on tag 4.4.1
Now I checkout fresh main
(just because tag 4.4.1 dont have wluma/src/frame/capturer/wlr_export_dmabuf_unstable_v1.rs
Fresh unchanged main
- flickering
with changes in wlr_export_dmabuf_unstable_v1.rs
- absolutely the same shit(
First case - error[E0425]: cannot find value frame_image in this scope If keep line 201 - no changes, it still flicker
Right, sorry, comment out line 201 and all of the unsafe block in the end too, lines 229-234.
It's f**king magic
Somehow it stops flickering! On all versions (including installed 4.4.1). I don't understand how.
Maybe it depends on some gamma settings? I also have gammastep
running...
Give me please some time to make more tests in different circumstances. I'll keep you posted
A new wlr-screencopy-unstable-v1
protocol has landed in wluma's main branch, the way I understand how it is different is that we don't access the compositor's frame directly, but instead we create our own image and ask compositor to fill it in. So I'm guessing/hoping that this would have even less chance for wluma to cause any kind of image artifacts, if it always works on its own copy of the image.
Would you like to try it out? Just pull the latest main
, keep capturer=wlroots
, and if both protocols are supported, wluma will automatically pick the wlr-screencopy-unstable-v1
one (you will see in RUST_LOG=trace
what it picks).
If you do get to try it, please report any issues you face with it, because I want to make this protocol a new default.
And also, on my own hardware I observed that with the new protocol I am getting occasional luma: 0
, but I don't know if it's something that I do incorrectly in the code, or it's a bug in my driver.
$ RUST_LOG=trace cargo run
...
[2024-10-23T21:48:43Z TRACE wluma::predictor::controller] Prediction: 180 (lux: none, luma: 17)
[2024-10-23T21:48:43Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:43Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:43Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 174 (lux: none, luma: 0) <-------------
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 180 (lux: none, luma: 17)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 174 (lux: none, luma: 0) <-------------
[2024-10-23T21:48:44Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:45Z TRACE wluma::predictor::controller] Prediction: 174 (lux: none, luma: 0) <-------------
[2024-10-23T21:48:45Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
[2024-10-23T21:48:45Z TRACE wluma::predictor::controller] Prediction: 181 (lux: none, luma: 16)
Could you tell me if you see them? (they pop up relatively frequently).
If you don't see them, could you comment this line and try again?
I see them without sleep
and don't see them anymore with sleep
.
changes in src/frame/capturer/wlr_export_dmabuf_unstable_v1.rs
don't helps at all, it still flickering
also with
comment out line 201 and all of the unsafe block in the end too, lines 229-234.
I tried fresh master with wlr-screencopy-unstable-v1
and I don't see luma: 0
. Screen keeps flickering, and I see that each particular flick happend in the same time with each trace message appear. Same with commented 432 line in src/frame/capturer/wayland.rs
Steps for reproducing the issue
wluma
What is the buggy behavior?
Right after start app screen starts flickering (with frequency near 5 Hz) and sometimes appear dark rectangles on light parts of screen image which persist on the same place after change image (scroll out or change browser tab). I saw this only in Chrome but I can't be sure that it don't appear in other apps
What is the expected behavior?
Clear screen image without flickering
Logs
Version
4.4.1
Environment