Allow webcam sleep duration to be set in config

[pyt0xic]

My laptop has a webcam activity LED and I got annoyed with it flashing every 2 seconds.

This allows setting the delay between steps instead of using the WAITING_SLEEP_MS constant. If it is not set or a value < MIN_WAITING_SLEEP_MS is passed, WAITING_SLEEP_MS is used as a default.

I used 1000ms for MIN_WAITING_SLEEP_MS, not sure if its even needed but I assume no one wants to use less than that...

An example:

[als.webcam]
video = 0
sleep_ms = 5000
thresholds = { 0 = "night", 15 = "dark", 30 = "dim", 45 = "normal", 60 = "bright", 75 = "outdoors" }

I added tests for no custom value, an invalid custom value and a valid custom value in which I am passing 0 as the video parameter in the Webcam constructor, let me know if this needs to change.

This is my first time working with Rust, so any feedback/improvements would be appreciated 😄

[maximbaz]

Thanks for the PR! You are totally right that the blinking LED is a concern (and was since the beginning...). There probably is a battery life aspect to it too, in addition to the LED annoyance (because als.webcam is a lot more computationally heavy than just reading a sensor value - when it exists).

If you don't mind, I'd like to ask you a few questions, simply because I don't know many users of als.webcam and I would like to consider if there is a "better default" to be made.

• What value for sleep_ms have you ended up using yourself?
• How long have you tried to use the app with this setting?
• Is it working well? Are there cases when it's annoying? For example, it takes super long to notice a change in ambient light, thus resulting in you having to manually adjust screen brightness anyway?
• Have you tried to use the app with als.none? Do you see additional value in als.webcam, that is worth paying the price of LED annoyance and battery life for?

Many thanks in advance 🙂

[pyt0xic]

If you don't mind, I'd like to ask you a few questions, simply because I don't know many users of als.webcam and I would like to consider if there is a "better default" to be made.

Sure!

* What value for `sleep_ms` have you ended up using yourself?

I started with 10000ms but I found the delay to be a bit annoying so I switched to 5000ms. I also tried 3000ms which performed pretty much the same as 2000ms

* How long have you tried to use the app with this setting?

Since I opened this PR. 😃 I only started using the app full time after I got the changes working.

* Is it working well? Are there cases when it's annoying? For example, it takes super long to notice a change in ambient light, thus resulting in you having to manually adjust screen brightness anyway?

Sometimes it can be a bit finicky (eg. If I move and the camera points directly at a white wall, it will move from dim to normal) but it seems to be happening less and less so I suspect that more training might help?
I've noticed that there is usually a 4-5s second delay between a threshold being crossed and the brightness changing and I think it was the same with all the sleep_ms values I tried.

* Have you tried to use the app with `als.none`? Do you see additional value in `als.webcam`, that is worth paying the price of LED annoyance and battery life for?

I tried als.time initially but I kinda committed to using als.webcam after deciding to make this change 😆
I haven't noticed any difference in battery life, but I am using swayidle to stop the service before locking/sleeping and start it back up again when system resumes, so it's not running when I am not working.

I'm kinda getting used to the LED now, so I am going to keep using als.webcam for a few more days and maybe try out als.none as well.

Regards,
Nic

[maximbaz]

Thanks for the answers! Please share an update as you keep using als.webcam for a few days, I'm curious to hear if you will trend towards reducing the sleep duration or not (as you will get used more and more to the LED).

The current value of 2s is not any special value produced by some golden rule, it was basically @cyrinux trying out different values and using the app for days and weeks, to see what feels best, in terms of LED annoyance vs reaction on environment change. There's no correct answer, but I'm very curious to collect feedbacks from actual users of als.webcam, since I'm currently not one of them 🙂

[name-snrl]

Wow, great job! This PR will give me the opportunity to completely ditch the bulky clight, and switch to wluma + wl-gammarelay-rs.

@maximbaz you asked for feedback, for the last 2 month I have been using clight with this timeouts (sec):

• ac_timeouts = [ 300 900 180 ];
• batt_timeouts = [ 300 900 180 ];

The first two values are day/night, what the last one is not so important. I think in the case of wluma I would set a timeout of 2-5 minutes. I don't see the point in calibrating too often

[maximbaz]

That is a great feedback, many thanks for sharing! Could you elaborate on what makes it useful to have 300 during the day and 900 during the night, as opposed to having only one timeout? Is it saving you significant amount of battery, or is the camera blinking still annoying even at 300 during the day? The fact that clight went to also offer different timeouts for AC and battery is also curious, though I can see you don't make use of that distinction.

I think in the case of wluma I would set a timeout of 2-5 minutes. I don't see the point in calibrating too often

The one reason why calibrating often could be important: because it can mess up the training data. Here's one example to illustrate:

Imagine it is night time, you are sitting in a well-illuminated room, wluma keeps your screen bright, exactly as you like it. It's time to turn off the lights, you are suddenly sitting with your laptop in the darkness.

wluma is already trained well, it knows you want a lower brightness, but it will only react once the new "ALS" value shows up.

If your timeout is set for a few seconds, it is okay to wait those few seconds for wluma to finally react, you eyes have probably not adapted to darkness yet anyway.

Now, if there is 5 minutes to wait, you might desperately want to reduce the brightness by hand. If you just do it (as opposed to e.g. restarting wluma), you will register a new training datapoint: "I want low brightness value during bright surroundings" (because wluma still thinks it's bright around!). From now on, when you are in bright conditions, wluma will incorrectly be dimming your screen.

[pyt0xic]

Some feedback:

I have been using wluma with als.webcam and a 5000ms sleep duration for the past week and, it just works.

I basically never change the brightness manually any more and I'm kind of used to the flashing LED now.

I'm going to try the als.time and als.none for a comparison but id be happy continuing to use it as is.

Regarding the ability to set different sleep durations for AC and battery, Im going to try find a way to measure the power impact of different sleep durations and if I find any difference I would like to try add this. I do love to optimise 😂

@maximbaz do you think there would be any benefit in combining als.time and als.webcam with a longer sleep duration as a way to "fine tune" and be a bit more adaptive than just als.time? The only potential benefit of doing this in my mind is having the ability to set a longer sleep duration and maybe to save battery...

I use gammastep alongside wluma which uses your location to determine the time of sunset and sunrise, this doesn't give the same level of control as how als.time is implemented but perhaps something like this could be used to determine the user's night/day times automatically and then fine tune the thresholds based on that..

I might be misunderstanding how als.time works so I'll do some experimenting and let you know what I find. It's been fun working with rust 😂

I am also curious about whether implementing gamma control is an option, it would be nice to just use wluma without something like gammastep.

I really really like this app, I've been looking for something like it for a long time so thank you so much for all your hard work!

[pyt0xic]

Wow, great job! This PR will give me the opportunity to completely ditch the bulky clight, and switch to wluma + wl-gammarelay-rs.

@maximbaz you asked for feedback, for the last 2 month I have been using clight with this timeouts (sec):

• ac_timeouts = [ 300 900 180 ];
• batt_timeouts = [ 300 900 180 ];

The first two values are day/night, what the last one is not so important. I think in the case of wluma I would set a timeout of 2-5 minutes. I don't see the point in calibrating too often

Just out of curiosity, how do you plan on using wluma and wl-gammarelay-rs together?

[maximbaz]

do you think there would be any benefit in combining als.time and als.webcam with a longer sleep duration as a way to "fine tune" and be a bit more adaptive than just als.time?

I can't envision fully yet what you have in mind, or we might be understanding als.time a bit differently 🙃

To give you an intuition behind als.time, it is meant as a stub for ALS, it simulates a sensor that always returns the same constant reading at a given hour of the day.

It's basically to say "at 12:00 it's usually bright around me, at 17:00 it begins to be dim, and at 21:00 I turn off the lights, and I want wluma to react accordingly", so you configure those thresholds to let wluma think that it's bright between 12-17, dim between 17-21 and dark in the rest of the day.

gammastep is smarter, as in you don't have to hardcode sunrise and sunset time, but on the other hand als.time allows you to have 24 steps with totally custom values.

I have been using wluma with als.webcam and a 5000ms sleep duration for the past week and, it just works.

I always want for people to have a great experience out of the box, so in this particular case, I'm still not 100% decided because:

1. I wary of allowing to configure long values without understanding the consequences it has on the training process (because it can really mess up your training, and in my experience it is really hard to recover sometimes from bad datapoints... I had to remove all data and start entirely from scratch a couple times when it went totally bad),
2. If small incremental change really feels better and is less annoying (e.g. 5s instead of 2s), I'd rather just have 5s as the new value and improve lives of everyone.
3. Blinking LED is understandably annoying, you don't experience that from any other app, but if after a few days of usage you get used to it, I'm questioning if the blinking interval (e.g. 2 vs 5s) is really something you mind will pay attention too.
4. Battery life might be an important factor to consider
5. Making LED constantly on, as opposed to blinking, is also perhaps something to consider (there are downsides - webcam is an exclusive resource, you can't start a video call if wluma uses camera - and wluma can't use camera while you are in a call).

I am also curious about whether implementing gamma control is an option, it would be nice to just use wluma without something like gammastep.

I've been thinking about it so many times 😅 But every time I abandon the idea, as it's not as intuitive for me yet how that could work, color temperature probably shouldn't change with screen contents, some people like you and me accept a smooth curve based on sunrise/sunset time, @name-snrl probably uses wl-gammarelay-rs to adjust it manually with more intelligent rules. Maybe ALS, but then if it's a rainy day like today, the ALS value is significantly lower than on a sunny day, and I probably don't want to have a warm color during the day... In any case, it's an interesting topic to consider, if you want to chat more about this, I propose to move to a dedicated issue, so that others will find it easier to find the discussion and participate in it 🙂

[name-snrl]

what makes it useful to have 300 during the day and 900 during the night

I've a smaller timeout during the daytime because light levels change more frequently during the day than at night.

example to illustrate:

Hm... Yeah, that reasonable. But, I think we could solve this by forcing a light level check immediately after manually changing the brightness, but before wluma reads its learning entries.

[maximbaz]

Hm... Yeah, that reasonable. But, I think we could solve this by forcing a light level check immediately after manually changing the brightness, but before wluma reads its learning entries.

It's definitely better but not ideal, the training likely should not have been needed in that case (if only wluma knew the real ALS values, it would have predicted the best values anyway), and there is a downside to overfitting the model with a lot of training points around similar values (it becomes very "jumpy" when it has too much data around "similar" environments).

The LED is a privacy indicator, and with als.webcam or clight you are almost giving up on that protection (you never know if it's wluma taking ALS value, or some rogue script taking a pic of you), so I'm half-jokingly thinking if a piece of black tape is a requirement to use als.webcam to cover that annoying LED 😅 Or making it constantly light, instead of blinking!

[name-snrl]

Just out of curiosity, how do you plan on using wluma and wl-gammarelay-rs together?

Here are the features I need:

1. manually change screen brightness
2. changing the brightness depending on the screen content
3. changing screen temperature by clock
4. periodically checking the light level and changing the screen brightness

I used to use only clight, but changing the brightness for p.2 is quite slow as it checks the screen content every second (not sure if you can set a fractional number there, the default is 3 seconds), also there is a problem in the implementation FedeDP/Clightd#110. Now I have replaced that part of clight with wluma. After merging this PR, I plan to also start using wluma for p.4 and replace clight with wl-gammarelay-rs for p.1 and p.3.

[name-snrl]

should not have been needed in that case

Yeah, I'm trying to turn wluma into clight. Maybe I should just stay with the combination of wluma + clight. I like how clight changes the screen brightness every 5 minutes, and also has a set of commands in its .desktop file. This allows me to never have to change the brightness by hand, I always just call fuzzel, find clight there and it changes the brightness based on the ALS data

[maximbaz]

It's not that I'm against this idea in any way, I'm trying to better understand the pains and motivations behind how people use this. For example, is LED a real deal breaker, or rather an annoyance that you get used to in a weeks time? Is LED perhaps irrelevant at all, but instead it is undesirable that screen brightness changes too frequently, as opposed to only every 5 minutes? Is it that it's just very hard to capture your internal algorithm of how to pick an ideal brightness level, for whatever reasons, and that's why you would rather have "obvious automated corrections" and a control to fine-tune things whenever you like? 🙂

[name-snrl]

annoyance that you get used to in a weeks time?

we'll find out in a week :D

Is LED perhaps irrelevant at all, but instead it is undesirable that screen brightness changes too frequently, as opposed to only every 5 minutes?

no, it's not a problem

[pyt0xic]

do you think there would be any benefit in combining als.time and als.webcam with a longer sleep duration as a way to "fine tune" and be a bit more adaptive than just als.time?

I can't envision fully yet what you have in mind, or we might be understanding als.time a bit differently 🙃

To give you an intuition behind als.time, it is meant as a stub for ALS, it simulates a sensor that always returns the same constant reading at a given hour of the day.

It's basically to say "at 12:00 it's usually bright around me, at 17:00 it begins to be dim, and at 21:00 I turn off the lights, and I want wluma to react accordingly", so you configure those thresholds to let wluma think that it's bright between 12-17, dim between 17-21 and dark in the rest of the day.

gammastep is smarter, as in you don't have to hardcode sunrise and sunset time, but on the other hand als.time allows you to have 24 steps with totally custom values.

I have been using wluma with als.webcam and a 5000ms sleep duration for the past week and, it just works.

I always want for people to have a great experience out of the box, so in this particular case, I'm still not 100% decided because:

1. I wary of allowing to configure long values without understanding the consequences it has on the training process (because it can _really_ mess up your training, and in my experience it is really hard to recover sometimes from bad datapoints... I had to remove all data and start entirely from scratch a couple times when it went totally bad),

2. If small incremental change really feels better and is less annoying (e.g. 5s instead of 2s), I'd rather just have 5s as the new value and improve lives of everyone.

3. Blinking LED is understandably annoying, you don't experience that from any other app, but if after a few days of usage you get used to it, I'm questioning if the blinking interval (e.g. 2 vs 5s) is really something you mind will pay attention too.

4. Battery life might be an important factor to consider

5. Making LED constantly on, as opposed to blinking, is also perhaps something to consider (there are downsides - webcam is an exclusive resource, you can't start a video call if wluma uses camera - and wluma can't use camera while you are in a call).

I am also curious about whether implementing gamma control is an option, it would be nice to just use wluma without something like gammastep.

I've been thinking about it so many times 😅 But every time I abandon the idea, as it's not as intuitive for me yet how that could work, color temperature probably shouldn't change with screen contents, some people like you and me accept a smooth curve based on sunrise/sunset time, @name-snrl probably uses wl-gammarelay-rs to adjust it manually with more intelligent rules. Maybe ALS, but then if it's a rainy day like today, the ALS value is significantly lower than on a sunny day, and I probably don't want to have a warm color during the day... In any case, it's an interesting topic to consider, if you want to chat more about this, I propose to move to a dedicated issue, so that others will find it easier to find the discussion and participate in it 🙂

---

Okay I read the code and I realized it does not work how I thought it did 😆

Honestly I agree about this PR being kinda pointless, I think upping the sleep duration to 3-4 seconds might be a good idea, but honestly, there isn't much difference.
It is mildly less annoying but I could get used to 2s.

I found out it is possible to disable the LED on some webcams. I can't remember where I read about it but I used the following to list my webcams controls:

v4l2-ctl -d /dev/video0 --all

I think it needs to have the led_mode control.

I have been trying out wl_gamma_control but I have yet to get it working. 🤣
I've only ever worked with Wayland with C#, Rust is quite different...

[pyt0xic]

Just out of curiosity, how do you plan on using wluma and wl-gammarelay-rs together?

Here are the features I need:

1. manually change screen brightness

2. changing the brightness depending on the screen content

3. changing screen temperature by clock

4. periodically checking the light level and changing the screen brightness

I used to use only clight, but changing the brightness for p.2 is quite slow as it checks the screen content every second (not sure if you can set a fractional number there, the default is 3 seconds), also there is a problem in the implementation FedeDP/Clightd#110. Now I have replaced that part of clight with wluma. After merging this PR, I plan to also start using wluma for p.4 and replace clight with wl-gammarelay-rs for p.1 and p.3.

Ahh I see.

Regarding number 3, I am attempting to add this in.
I would like add the ability to determine sunset/sundown times like gammastep as well.

@maximbaz I'll open a new issue for this 👍
I might need some help with wl_gamma_control, I mostly understand what you are doing in wlroots.rs but Rust is so different to what I am used to...

[salman-farooq-sh]

@pyt0xic Did you notice any impact on battery endurance with [als.webcam]? And on what sleep interval?

Edit: Personally I don't mind the blinking webcam led. I will be okay with lowering the sleep interval to even a very low value such as 100ms if it doesn't affect battery life. I just want the best experience i.e. whatever makes wluma smarter in choosing the brightness value but I also want to preserve battery life. These 2 things is what I desire.

Overall, I vote for this to be configurable i.e. the PR should be merged imo. Because everyone is going to have different preferences regarding led-blinking anyways even if it is the case that battery isn't hit hard even with like 100ms sleep interval. Some people might get used to even really frequent blinks right away (like me) or they might want to trade everything just because they are unable to get used to it even after weeks. Some people might have machines where the led is objectively more annoying e.g. by being very bright or sharp compared to some other machines where the led is almost calming in a way (like mine).

The effects of increasing and decreasing this interval, on the battery at least, will need to be investigated and presented in the documentation maybe under a section called "Advanced Config" if it is felt to be too complex so that people don't tamper with it by mistake.

I will try to report back on this.

tl;dr: Merge the PR and document the effects of changing the interval.

Update: Battery seemed to take a hit, not sure though. I was running the main branch with its default 2000ms interval.

[maximbaz]

The biggest argument against this was in fact not the battery life, but that by using a too-large value you will (a) make wluma not reactive and (b) inadvertently and very quickly mess up training data, where a new data point was meant for a new ambient light value, whereas wluma still has the old value that it will associate with your training data.

Example: you are in a dark room, someone turns on the lights, wluma doesn't react. (a) chances are you will not wait more than a few seconds, before being annoyed and manually increasing the brightness; (b) you increase the brightness but since wluma doesn't know it's bright, it will remember that you want this high brightness in such a dark room (as it remembers it), thus totally invalidating your training data.

I think I'll be okay to merge it if we can find a solution to prevent incorrect training points - one way could be that we always read webcam right before saving the new training point, and thereby ensuring that the new training item is being saved with the latest ALS value.

All the other things (battery impact vs wluma being not reactive) I'm okay to just document and let people configure, it's just impossible to document how to not mess up the training data.

[salman-farooq-sh]

A simple note saying that high values will mess up training data and here is how you can reset training data in case you mess it up won't be enough?

I am still interested in knowing how much battery life is affected by [als.webcam] in relation to different sleep intervals.

[maximbaz]

No, in my eyes that's like shipping a feature called "foot-shooter" with a note "shooting yourself in the foot can mess up your foot, anyways here's how to do it" 😅

The whole premise is that wluma gets better with time, you tend to value well-trained dataset (on my laptop I haven't touched brightness buttons for months!), I really don't like opening a way for throwing all that away at unpredictable times.

[salman-farooq-sh]

What if we write a big DANGER! in bright red color wherever this thing is mentioned? I mean all the power to the user, that is what linux is, and who a large user-base of wluma probably is? We are also telling the user here is how you can get a new foot 😆, or the old one by telling them here is how you can backup your learning data before playing with this setting.

Maybe have a hard-coded upper-bound for this as going too high seems to be the only problem? 🙂

[maximbaz]

I think if we have the opportunity to do the right thing (in this case protect people from losing training data at unpredictable times by e.g. taking an extra webcam shot when new training data is being introduced), we should do the right thing.

You are probably also the only person who wants to increase the frequency, everyone else seems to want to reduce it, so if we ship this, we have to make it useful for the majority 🙂

Also all users are luckily have the power to do whatever they want thanks to this tool being open-source with a very permissive license, it's just one cargo build away :)

[salman-farooq-sh]

Touché.