Bug in hs.brightness.set()

[latenitefilms]

On macOS 10.14.6 I'm seeing:

> hs.brightness.set(80)
true

> hs.brightness.get()
79

> hs.brightness.set(81)
true

> hs.brightness.get()
80

Can you reproduce @cmsj or @asmagill ?

[latenitefilms]

Also, hs.brightness.ambient() isn't working on my MacBook Pro (15-inch, 2017). I'm just getting -1.

[dasmurphy]

@latenitefilms I can reproduce it on my 10.14.6 too. Same values here.

It is a MacBook Pro 15 also a 2017 model.

[pedrorrivero]

Same thing going on here, any news? Also, I noticed that the brightness scrollbar does not get updated when a new brightness is set trough the API.

[latenitefilms]

Thoughts on this @asmagill or @cmsj ?

[asmagill]

The brightness value used by both the IOKit approach and the newer DisplayServices approach used for M1 is actually a double type. The brightness module internally converts this to/from an integer between 1 and 100. I suspect that rounding and machine approximations are causing this.

hs.screen:get/setBrightness keeps everything a double, so it will probably be more consistent.

[cmsj]

yeah I'm pretty sure @asmagill is right here. The question is, should we deprecate hs.brightness:get() and :set()?

[asmagill]

That would leave only hs.brightness.ambient in the brightness module. It isn't monitor specific, so it shouldn't be moved into hs.screen as a method, but with proper documentation, it might not be a horrible fit as a function.

Or we could just make it something like hs.ambient and put it in at the "top level".