Closed vega-d closed 1 year ago
It's probably caused by this, but you are right we can try to be better at explaining what needs to be done...
And I've realized that we don't have udev rules documented anywhere! This is actually how it's solved in Arch package, by installing this file in the proper location, so that adding yourself to video
group actually works!
https://github.com/maximbaz/wluma/blob/3901acc75a25f9db8aae41512ca26a74fec2b5b2/Makefile#L42
$(LIB_DIR)
I don't seem to have these variables defined on my system? I figured LIB_DIR is supposed to point to /etc or something, so I did
sudo install -Dm644 -t /etc/udev/rules.d/ 90-wluma-backlight.rules
and then did the usual dance around config files to add myself to video
group (silverblue has it a bit broken)
cat /usr/lib/group | grep video
echo video:x:39:$USER | sudo tee -a /etc/group
sudo usermod -a -G video $USER
and I can confirm I am in video
group:
vega@dart ~/s/wluma> groups
vega wheel kvm video qemu libvirt
BUT, it still doesn't appear to have permissions to control the screen:
vega@dart ~/s/wluma> ./target/release/wluma
[2022-01-29T14:16:02Z WARN wluma] Skipping 'eDP-1' as it might be disconnected: Permission denied (os error 13)
[2022-01-29T14:16:02Z INFO wluma] Continue adjusting brightness and wluma will learn your preference over time.
^Cā
I don't seem to have these variables defined on my system?
https://github.com/maximbaz/wluma/blob/3901acc75a25f9db8aae41512ca26a74fec2b5b2/Makefile#L4-L5
It's part of make
ecosystem, DESTDIR
is empty for you, so LIB_DIR
becomes /usr/lib
and I can confirm I am in video group:
Great, final thing is to confirm that udev rule was applied successfully (you can look inside what it does, it just changes group owner of a file), it should look like this (if not, reboot, or maybe you installed udev rule in a wrong location, or maybe just do it by hand)
$ ls -al /sys/class/backlight/intel_backlight/brightness
.rw-rw-r-- 4.1k root video 27 Jan 11:42 /sys/class/backlight/intel_backlight/brightness
^
Great, final thing is to confirm that udev rule was applied successfully
It was!
vega@dart ~> ls -al /sys/class/backlight/intel_backlight/brightness
-rw-rw-r--. 1 root video 4096 Jan 29 16:04 /sys/class/backlight/intel_backlight/brightness
However after a quick reboot I am now facing another crash XD
vega@dart ~/s/wluma> ./target/release/wluma
[2022-01-30T13:30:02Z INFO wluma] Continue adjusting brightness and wluma will learn your preference over time.
thread 'predictor-eDP-1' panicked at 'Unable to init export_dmabuf_manager: Missing', src/frame/capturer/wlroots.rs:80:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
the backtrace can be found here: https://paste.centos.org/view/fbfd811d
Great!
This is because you are using Gnome, you must change capturer
to none
in the config; screen contents capturing is currently only implemented for wlroots-based compositors, #5 is tracking support for more.
And please dont close the issue yet after you get it to work, there is clearly several things that must be documented better, I will use this as a reference to improve it š
you must change
capturer
tonone
in the config;
looks like it did the trick. Can it still adjust my brightness based on time of day? I only really need it to get a bit dimmer during the day and a bit brighter during the night.
actually no scratch that, I tested how annoying webcam simulation is, and it doesn't seem to affect anything aside from my webcam light blinking :D It doesn't appear to change my brightness though, is there a way to make it output logs, something along the lines of "hmm, looks like light amount is X now so I will change brightness to Y"?
Can it still adjust my brightness based on time of day?
Yes, that will still work š
Make sure to use als.time
:
https://github.com/maximbaz/wluma/blob/3901acc75a25f9db8aae41512ca26a74fec2b5b2/config.toml#L9-L10
The keys are hours, values are arbitrary, so you can do like:
thresholds = { 0 = "night", 7 = "day", 20 = "night" }
And this would give you two states, night during 20:00-07:00
and day during 07:00-20:00
It doesn't appear to change my brightness though
You need to train it after setting the config :) So suppose you use time based config above, during the day set brightness to 90% and then at night set it to 30%, and then wluma will keep setting it for you to 90% and 30% as the hour changes
is there a way to make it output logs, something along the lines of "hmm, looks like light amount is X now so I will change brightness to Y"?
$ RUST_LOG=trace wluma
will make it print a bit more...
hmm yes, it appears to work now. I'm going to add it as a user systemd service and let it run for a couple of days, will check in back later to report how well it turned out
wluma has done something weird to my webcam. Now if I run wluma webcam light comes on and stays on, instead of blinking like it did yesterday. RUST_LOG=trace says wluma thinks it's always bright af, even if I cover the camera with my finger. All other apps just receive a black screen from it.
Could you please create a separate ticket for this? Let's see what we can improve with regards to webcam...
Also please include whether you can consistently reproduce (and if yes, some repro steps would be welcome), whether stopping wluma turns off the webcam light or it keeps shining even after exiting the app, whether running wluma without als.webcam
turns the light off, whether you have some other apps running that might be using webcam.
If it worked but then stopped, I imagine it's some sort of conflict with another app, webcam is a single shared resource that can only be used by one app, so if you e.g. have a video call, wluma will not be able to use webcam.
Could you please create a separate ticket for this?
created #41
Documented the need for installing udev rule when using video
group, otherwise this particular topic looks solved - thanks again, closing.
Steps for reproducing the issue
~/.config/wluma/config.toml
What is the buggy behavior?
behavior when ran without sudo:
behavior when ran with sudo:
here's a link to a file with
RUST_BACKTRACE=full
when running with sudo: https://paste.centos.org/view/33b45dcfWhat is the expected behavior?
I think the issue there is that when it's ran with sudo it thinks the user is root and looks for config file in
/root/.config/wluma/config.toml
Logs
Version
version 4.1.0, from the built artifact in releases folder
Environment