Webcam is used for measureing ambient light in favor of iio sensor

[mindrunner]

Webcam is used for measureing ambient light in favor of iio sensor

[beret]

I'll try to test this weekend and let you all know my findings. Thanks! <3

…

On Jan 3, 2020, at 4:51 PM, Federico ***@***.***> wrote: Wow! acpi-als had 4096 steps instead. Hopefully i will have to only support iio/als! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[FedeDP]

Wow! acpi-als had 4096 steps instead.
Hopefully i will have to only support iio/als!

[mindrunner]

Yeah sounds reasonable. I'd say, lets give it a go and I will test around with it. :)

[FedeDP]

If @beret does not mind, i will ask him to test it too as soon as i push! This way we can ensure proper retrocompatibility :)

Moreover, merging in #31 that will possibly be fixed by this implementation.
@lukas1760 Do you mind testing this one too when it's committed?

[FedeDP]

Commit 77368ac tries to fix ALS support! Awaiting your tests, thanks!

[beret]

Seems to work fine for me over here. First read was in a dim room, and the second was with a flashlight sitting on the webcam/ALS sensor area.

$ clight
Config file /home/beret/.config/clight.conf not found.
GAMMA forcefully disabled as Clightd was built without gamma support.
SCREEN forcefully disabled as Clightd was built without screen support.
Clightd found, version: 4.1.
Initial AC state: connected.
Failed to create org.freedesktop.ScreenSaver dbus interface: Unknown error -1
Fallback at monitoring requests to org.freedesktop.ScreenSaver name owner.
Ambient brightness: 0.044 -> Backlight pct: 0.058.
Ambient brightness: 1.000 -> Backlight pct: 0.999.

[lukas1760]

hi! I have a lot of work now, but sure I will test it!

[lukas1760]

under led lamp.

KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{proximity_scale_available}=="1 2 4 8"
    ATTR{in_proximity_raw}=="188"
    ATTR{in_intensity_green_raw}=="1850"
    ATTR{in_intensity_clear_raw}=="4407"
    ATTR{in_intensity_blue_raw}=="1842"
    ATTR{in_intensity_scale}=="1"
    ATTR{name}=="apds9960"
    ATTR{intensity_scale_available}=="1 4 16 64"
    ATTR{in_intensity_integration_time}=="0.028000"
    ATTR{in_intensity_red_raw}=="1065"
    ATTR{in_proximity_scale}=="1"
    ATTR{integration_time_available}=="0.028 0.1 0.2 0.7"

[mindrunner]

You can always tweak clight backlight curve for that :)

Yeah, sure. Will create my new curve :)

Yes, when no sensor_devname is provided in clight config, clightd will use first matching device it finds, and ALS devices have higher priority.

Sweet, problem solved!!

No need to bump, you just need to rebuild clightd-git package!

Yeah, I assumed that as well, however clightd-git is using my webcam and not ALS :(
Works perfectly fine

[FedeDP]

After latest commit, everyone should have working ALS support.
Let me know, thank you very much!

[lukas1760]

after last commit
sb "/dev/iio:device0" true

it looks like it's working correctly, brightness is increasing/decreasing but only for a while.
here is a clight log file.
clight.log
any ideas? :(

[FedeDP]

Dimmed as in "idle since X seconds and no org.freedesktop.ScreenSaver lock present".
Ie: when Clight detects you're away from keyboard and reduces screen backlight.

[FedeDP]

The settings option for ALS are now documented: https://github.com/FedeDP/Clightd/wiki/Api#als-settings.

[FedeDP]

Expanded Clightd sensors once more; i just pushed a commit that adds a "Custom" sensor to clightd that will just takes its input from a text file.
This means that you are now able to provide any text file as fake sensor; eg: you may have a script to read your Android ALS and refresh a file that is then read by clightd; or, even better, you can probably mount your smartphone with eg: mtpfs, and directly let Clightd read its als values (i guess; not tested :) ).

I'd consider this closed if you all are so kind to try a new test with your ALS device to exlude any regression (i always fear to break it, as i cannot test it; still waiting for my ALS device to arrive!).
Thank you very much!

[mindrunner]

Still working for me. Did not test the new custom feature though

[FedeDP]

Hi! Does it work when forcing Als device?

[mindrunner]

Can you please be clear about how to do that?

[FedeDP]

busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor Capture "sis" "" 5 ""

[mindrunner]

[le@w530]: ~>$ busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor Capture "sis" "" 5 ""
Call failed: No such device

[FedeDP]

Great! There is a bug somewhere :) I'll take a look at it. I will surely need you help testing though as my laptop does not have Als :)

[mindrunner]

Sure, no worries. I will be there. Happy to see this working! :)

May I ask what device you are using? I assumed, all modern laptops should have sucha a sensor....

[FedeDP]

My laptop is an Acer Swift 3 and unfortunately it comes with no als!

[mindrunner]

Alright, seems like my expectations to industry are too high again.... :)

Let me know where I can assist in fixing this! :)

[FedeDP]

I had a look at autolight source code and it uses the same interface as clightd.
But Clightd uses udev to reach that, while autolight just opens and reads the appropriate files.

Can you share both
ls /sys/bus/acpi/drivers/acpi_als/
and
ls /sys/class/als
output?
Clightd uses acpi_als driver to retrieve and use als devices. Can you check that it is loaded?

[mindrunner]

[le@w530]: ~>$ ls /sys/bus/acpi/drivers/acpi_als/
ls: cannot access '/sys/bus/acpi/drivers/acpi_als/': No such file or directory
[le@w530]: ~>$ ls /sys/class/als/
ls: cannot access '/sys/class/als/': No such file or directory

Also, there is neither a acpi-als module loaded, nor can I find a package with that name. I feel a bit stuck. Shouldn't this be either straight-forward or somewhere documented?

[FedeDP]

The kernel driver is called acpi_als, isn't it there for you?

Yes it should be straightforward or documented, but not having myself an Als does not help me develop for it.
When first Als tester said it was working I thought it was for everyone without extra steps.

I think that you only need to load that kernel module at boot time and clightd should work.
It that's the case, I will fix this in doc and next clightd version will automatically load the module for you.
Can you try to modprobe acpi_als? Thanks and merry Xmas!

[mindrunner]

Module is not autoloaded, which usually means that there is no supported hardware by it.

Many of the sensors in modern Laptops use iio-sensor-proxy.

Manually loading the module does not change the situation for me.

[mindrunner]

Any chance, we can implement the iio device interface, like autolight does?

[FedeDP]

Happy new year!
Can you share output of:
udevadm info /sys/bus/iio/devices/iio:device1 ?

[mindrunner]

Happy new year!! :)

I have two iio devices (acceleration and als). The have changed their order recently. Not sure why. So als is now device0:

[le@y730]: ~>$ udevadm info /sys/bus/iio/devices/iio:device0
P: /devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-0416C300:00/0018:6243:0001.0003/HID-SENSOR-200041.2.auto/iio:device0
N: iio:device0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-0416C300:00/0018:6243:0001.0003/HID-SENSOR-200041.2.auto/iio:device0
E: DEVNAME=/dev/iio:device0
E: DEVTYPE=iio_device
E: MAJOR=239
E: MINOR=0
E: SUBSYSTEM=iio
E: USEC_INITIALIZED=19844900
E: IIO_SENSOR_PROXY_TYPE=iio-buffer-als
E: SYSTEMD_WANTS=iio-sensor-proxy.service
E: TAGS=:systemd:

[FedeDP]

Great, thanks!
And what about udevadm info -a /sys/bus/iio/devices/iio:device0?

[mindrunner]

[le@y730]: ~>$ udevadm info -a /sys/bus/iio/devices/iio:device0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-0416C300:00/0018:6243:0001.0003/HID-SENSOR-200041.2.auto/iio:device0':
    KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{in_illuminance_raw}=="209"
    ATTR{in_illuminance_offset}=="0"
    ATTR{in_intensity_scale}=="1.000000000"
    ATTR{name}=="als"
    ATTR{in_illuminance_scale}=="1.000000000"
    ATTR{in_intensity_offset}=="0"
    ATTR{in_intensity_sampling_frequency}=="10.000000"
    ATTR{in_intensity_both_raw}=="209"
    ATTR{in_illuminance_sampling_frequency}=="10.000000"

  looking at parent device '/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-0416C300:00/0018:6243:0001.0003/HID-SENSOR-200041.2.auto':
    KERNELS=="HID-SENSOR-200041.2.auto"
    SUBSYSTEMS=="platform"
    DRIVERS=="hid_sensor_als"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-0416C300:00/0018:6243:0001.0003':
    KERNELS=="0018:6243:0001.0003"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-sensor-hub"

  looking at parent device '/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8/i2c-0416C300:00':
    KERNELS=="i2c-0416C300:00"
    SUBSYSTEMS=="i2c"
    DRIVERS=="i2c_hid"
    ATTRS{name}=="0416C300:00"

  looking at parent device '/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-8':
    KERNELS=="i2c-8"
    SUBSYSTEMS=="i2c"
    DRIVERS==""
    ATTRS{name}=="Synopsys DesignWare I2C adapter"

  looking at parent device '/devices/pci0000:00/0000:00:15.2/i2c_designware.2':
    KERNELS=="i2c_designware.2"
    SUBSYSTEMS=="platform"
    DRIVERS=="i2c_designware"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/pci0000:00/0000:00:15.2':
    KERNELS=="0000:00:15.2"
    SUBSYSTEMS=="pci"
    DRIVERS=="intel-lpss"
    ATTRS{driver_override}=="(null)"
    ATTRS{devspec}==""
    ATTRS{local_cpus}=="ff"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{d3cold_allowed}=="1"
    ATTRS{class}=="0x118000"
    ATTRS{irq}=="18"
    ATTRS{numa_node}=="-1"
    ATTRS{subsystem_vendor}=="0x17aa"
    ATTRS{subsystem_device}=="0x3818"
    ATTRS{vendor}=="0x8086"
    ATTRS{consistent_dma_mask_bits}=="64"
    ATTRS{ari_enabled}=="0"
    ATTRS{enable}=="1"
    ATTRS{local_cpulist}=="0-7"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}=="1"
    ATTRS{device}=="0x9d62"
    ATTRS{revision}=="0x21"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

[FedeDP]

Thanks, this is much helpful! Hopefully I'll soon come back with a working git master version to let you test :)

[mindrunner]

Sweet, sounds awesome! Thanks :)

[FedeDP]

Can you try to change https://github.com/FedeDP/Clightd/blob/master/src/modules/sensors/als.c#L6 with just "als" instead of "acpi-als" and then recompile clightd, kill current clight and clightd and try running clightd again?

Then, finally, you can try to issue a
busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor IsAvailable "s" ""
once more :)

[FedeDP]

I expect it to say that it now finds correct als device.
I'll explain why: "acpi_als" driver uses "acpi-als" udev ATTRS{name}, while normal iio drivers use just "als".
Probably the first tester of the feature had an acpi als device and thus i developed als support against it.

Note that acpi-als has also a different API: Clightd is currently using "ATTRS{in_illuminance_input}" that is not availabe in your driver.
We should probably use ATTRS{in_illuminance_raw}.

Thus, even if IsAvailable method works (it should!), we still need to port Capture method to use in_illuminance_raw.
Can you test under various brightness conditions maximum and minimum level reported by your als sensor, testing with udevadm info -a /sys/bus/iio/devices/iio:device0 | grep in_illuminance_raw ?

Then i only need to find out whether acpi_als should be supported too (or if it is just a special case for iio als but is already supported by it) and if maximum and minimum reported values are universally fixed.

[mindrunner]

Alright, looks like we are on the right track:

compiled clightd with the change you mentioned, starting and firing

[le@y730]: ~>$ busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor IsAvailable "s" ""
sb "/dev/iio:device0" true

Looking good so far. However starting clight seems to fail now (not sure if this is supposed to be):

[le@y730]: ~>$ clight 
Disabling DIMMER as BACKLIGHT is disabled.
Disabling SCREEN as BACKLIGHT is disabled.
GAMMA forcefully disabled as Clightd was built without gamma support.
DPMS forcefully disabled as Clightd was built without dpms support.
Clightd found, version: 4.0.
'/home/le/.local/share/clight/modules.d/backlight' loaded.
'/home/le/.local/share/clight/modules.d/gamma' loaded.
'/home/le/.local/share/clight/modules.d/autolight' loaded.
No functional module running. Leaving...

[FedeDP]

You probably did not build backlight/gamma/dpms support while manually building Clightd :)
No problem!

Alright, looks like we are on the right track:

That is really great!
Moreover, i found out that ATTRS{in_illuminance_raw} is standard even for acpi-als, thus it should work great!
I'd like to hear back from @beret that was our fortunate acpi-als user if he can check if he has a normal iio syspath too, eg udevadm info -a /sys/bus/iio/devices/iio:device0.

Otherwise i will fallback at supporting both als drivers (ie: standard iio/als and acpi_als).

[mindrunner]

Playing around with my head-torch and

 watch -n0.2 cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw

Found the ALS which is about 10cm left of the webcam. Lowest value is 0, highest is hard to tell. I got it up to something around 55000. My assumption is that is will max out at 65535, but the highest numbers might also have a special meaning since we definitely reach 0 in somewhat dark conditions.

I can run further tests under normal daylight conditions tomorrow to see what the average values are. I suppose it will never reach that far up. My torch is quite bright...

[beret]

Tested watch -n0.2 cat /sys/bus/iio/devices/iio\:device0/in_illuminance_raw
On my laptop I still get a range from 0-4095 (dark to bright saturation) just like on #6.
in_illuminance_input has the same 0-4095 range on my hardware, and there appear to be no other in_illumininance_**** files in this folder on my hardware.

Maybe @mindrunner has a higher precision sensor on their laptop?
I'm not sure what the best normalized data source is though. I think ACPI-ALS is supposed to provide absolute values in Lux, (see #6) but the kernel documentation does not seem very detailed. Some related code and discussions: https://code.woboq.org/linux/linux/drivers/iio/light/hid-sensor-als.c.html http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04192.html

$ udevadm info -a /sys/bus/iio/devices/iio:device0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0c/ACPI0008:00/iio:device0':
    KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{in_illuminance_raw}=="0"
    ATTR{name}=="acpi-als"
    ATTR{in_illuminance_input}=="0"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0c/ACPI0008:00':
    KERNELS=="ACPI0008:00"
    SUBSYSTEMS=="acpi"
    DRIVERS=="acpi_als"
    ATTRS{path}=="\_SB_.PCI0.LPCB.ALS0"
    ATTRS{status}=="15"
    ATTRS{hid}=="ACPI0008"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0c':
    KERNELS=="device:0c"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{path}=="\_SB_.PCI0.LPCB"
    ATTRS{adr}=="0x001f0000"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00':
    KERNELS=="PNP0A08:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{uid}=="0"
    ATTRS{path}=="\_SB_.PCI0"
    ATTRS{hid}=="PNP0A08"
    ATTRS{adr}=="0x00000000"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00':
    KERNELS=="LNXSYBUS:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{path}=="\_SB_"
    ATTRS{hid}=="LNXSYBUS"

  looking at parent device '/devices/LNXSYSTM:00':
    KERNELS=="LNXSYSTM:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{path}=="\"
    ATTRS{hid}=="LNXSYSTM"

$ uname -a
Linux macbookair-2014-13 5.4.6-arch3-1 #1 SMP PREEMPT x86_64 GNU/Linux

[FedeDP]

I found out that most als will return lux unit values; at least that is what iio-sensor-proxy is inferring and i think we can trust it.

The issue with lux values is that they are quite hard to normalize between 0 and 1, see wikipedia.
Right now, this is last problem before commit; we could theoretically just cut values above eg: 4096, but we still need to figure out a proper curve to normalize those values.

[FedeDP]

The issue with lux values is that they are quite hard to normalize between 0 and 1, see wikipedia.

Following wikipedia's provided table, we can just crop values between 0 and 500 that should be highest value for normal human usage (higher values will be cropped to 500 and thus to 1.0); below 500 values seems somewhat reasonably proportional.

For reference, this is exactly what autolight does: https://gitlab.com/craftyguy/autolight/blob/master/autolight#L45.

[FedeDP]

hi! I have a lot of work now, but sure I will test it!

Thank you very much!!

[lukas1760]

ok so...
my kernel after executing rpi-update command is: Linux raspberrypi 4.19.93-v7+ #1286 SMP Mon Jan 6 13:18:44 GMT 2020 armv7l GNU/Linux
This kernel have native support for AVAGO APDS9960 digital proximity, ambient light, RGB and gesture sensor so I bought one for testing. :)
Here is description:

Name: apds9960
Info: Configures the AVAGO APDS9960 digital proximity, ambient light, RGB and
gesture sensor
Load: dtoverlay=apds9960,=
Params: gpiopin GPIO used for INT (default 4)
noints Disable the interrupt GPIO line.

I added line dtoverlay=apds9960,gpiopin=4 into /boot/config file
and now is loaded after startup. Sensor is connected to rpi using 5 wires (VIN,GND,SCL,SDA,INT)

ls /sys/bus/iio/devices
iio:device0

lsmod
apds9960               20480  0
kfifo_buf              16384  1 apds9960
industrialio           73728  2 apds9960,kfifo_buf

but...

busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor IsAvailable "s" ""
sb "" false

[FedeDP]

Hi, thanks for testing!
What about:
udevadm info -a /sys/bus/iio/devices/iio:device0?

[lukas1760]

  looking at device '/devices/platform/soc/3f804000.i2c/i2c-1/1-0039/iio:device0':
    KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{intensity_scale_available}=="1 4 16 64"
    ATTR{in_intensity_integration_time}=="0.028000"
    ATTR{proximity_scale_available}=="1 2 4 8"
    ATTR{in_intensity_clear_raw}=="12"
    ATTR{in_intensity_green_raw}=="5"
    ATTR{integration_time_available}=="0.028 0.1 0.2 0.7"
    ATTR{name}=="apds9960"
    ATTR{in_intensity_blue_raw}=="3"
    ATTR{in_proximity_raw}=="1"
    ATTR{in_intensity_scale}=="1"
    ATTR{in_proximity_scale}=="1"
    ATTR{in_intensity_red_raw}=="4"

  looking at parent device '/devices/platform/soc/3f804000.i2c/i2c-1/1-0039':
    KERNELS=="1-0039"
    SUBSYSTEMS=="i2c"
    DRIVERS=="apds9960"
    ATTRS{name}=="apds9960"

  looking at parent device '/devices/platform/soc/3f804000.i2c/i2c-1':
    KERNELS=="i2c-1"
    SUBSYSTEMS=="i2c"
    DRIVERS==""
    ATTRS{name}=="bcm2835 I2C adapter"

  looking at parent device '/devices/platform/soc/3f804000.i2c':
    KERNELS=="3f804000.i2c"
    SUBSYSTEMS=="platform"
    DRIVERS=="i2c-bcm2835"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform/soc':
    KERNELS=="soc"
    SUBSYSTEMS=="platform"
    DRIVERS==""
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

[lukas1760]

and when is sensor covered (no light)

    KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{in_intensity_integration_time}=="0.028000"
    ATTR{integration_time_available}=="0.028 0.1 0.2 0.7"
    ATTR{name}=="apds9960"
    ATTR{in_intensity_red_raw}=="0"
    ATTR{intensity_scale_available}=="1 4 16 64"
    ATTR{in_intensity_blue_raw}=="0"
    ATTR{in_proximity_raw}=="219"
    ATTR{in_intensity_green_raw}=="0"
    ATTR{in_intensity_scale}=="1"
    ATTR{in_intensity_clear_raw}=="0"
    ATTR{proximity_scale_available}=="1 2 4 8"
    ATTR{in_proximity_scale}=="1"

  looking at parent device '/devices/platform/soc/3f804000.i2c/i2c-1/1-0039':
    KERNELS=="1-0039"
    SUBSYSTEMS=="i2c"
    DRIVERS=="apds9960"
    ATTRS{name}=="apds9960"

  looking at parent device '/devices/platform/soc/3f804000.i2c/i2c-1':
    KERNELS=="i2c-1"
    SUBSYSTEMS=="i2c"
    DRIVERS==""
    ATTRS{name}=="bcm2835 I2C adapter"

  looking at parent device '/devices/platform/soc/3f804000.i2c':
    KERNELS=="3f804000.i2c"
    SUBSYSTEMS=="platform"
    DRIVERS=="i2c-bcm2835"
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform/soc':
    KERNELS=="soc"
    SUBSYSTEMS=="platform"
    DRIVERS==""
    ATTRS{driver_override}=="(null)"

  looking at parent device '/devices/platform':
    KERNELS=="platform"
    SUBSYSTEMS==""
    DRIVERS==""

[FedeDP]

Ok i see. Your driver is behaving differently once more :(

Right now Clightd looks for ATTRS{name} = "*als*", ie: it must contains "als", while your is "apds9960".
Secondly, Clightd looks for "in_illuminance_input" or "in_illuminance_raw" properties, while your driver exposes "in_intensity_clear_raw".
Moreover, i see that in your first udev output:
ATTR{in_intensity_clear_raw}=="12"

Is this on a very low ambient light? Can you check its maximum level with a torch?

[FedeDP]

Thanks! Will work on this asap :)

[lukas1760]

Thanks! Will work on this asap :)

great! :)

[mindrunner]

Ok i see. Your driver is behaving differently once more :(

make all those different names, thresholds and whatever available to the config file. Then it is not up to you to support everything, but to the user to configure clight accordingly. Doesn't that make more sense?

[FedeDP]

@mindrunner I can workaround these issues with no problems; i just need testers :)
We should be quite done though; I am happy about this; moreover i ordered an USB als device to hopefully help me overcome possible future issues.

@lukas1760 btw what about calling:
busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor IsAvailable "s" "iio:device0"
?

[mindrunner]

Commit 77368ac tries to fix ALS support! Awaiting your tests, thanks!

Works on my device out of the box now. (Technically)

However, i feel like the screen is a bit too dark.
Daytime
Bad lightning conditions

[le@y730]: ~>$ cat /sys/bus/iio/devices/iio:device1/in_illuminance_raw
55

Also need to say, that I have a glaring screen which makes me seeing myself if brightness is too low.

Also, another question
Does clight find the sensor by itself? I did not need to configure any sensors in my config file. But I figured out that sometimes it is iio:sensor1 and sometimes it is iio:sensor0. Seems to be randomly assigned. Is that an issue?

[mindrunner]

Can you bump aur/clightd-git to build the latest commit? :)

[FedeDP]

However, i feel like the screen is a bit too dark.

You can always tweak clight backlight curve for that :)

Does clight find the sensor by itself?

Yes, when no sensor_devname is provided in clight config, clightd will use first matching device it finds, and ALS devices have higher priority.

Can you bump aur/clightd-git to build the latest commit? :)

No need to bump, you just need to rebuild clightd-git package!

Btw i will soon push another commit that changes some more things to allow Clightd to support @lukas1760 sensor too (together with much easier support for any other sensor).
I'd like if you all can test it once more! Thanks for your time!

[mindrunner]

f96c077 works for me!!

[FedeDP]

(D)[21:33:24]{display.c:35} Entering dimmed state...

It seems like your screen was dimmed; when screen is dimmed, backlight module is paused as it is useless.

[mindrunner]

What does dimmed exactly mean here? Do you mean manually dimmed?

[FedeDP]

Since latest commit, you are now able to pass 3 options to ALS capture, through last "Capture" method parameter: "i=X", "m=X", "M=X";
these let you customize:

• "i" -> interval, ie: how many milliseconds between each requested sensor polling; by default Clightd uses 20ms.
• "m" -> minimum value, ie: if ALS read is below this value, it will be set to this value.
• "M" -> maximum value, ie: if ALS read is above this value, it will be set to this value.

Note that settings string must be comma separated, eg:
i=10,M=400

I still need to document this on wiki page!

[FedeDP]

Custom sensors documentation has been added: https://github.com/FedeDP/Clightd/wiki/Sensors.

[FedeDP]

I think we can close this :)
Please feel free to reopen if something breaks!

[mindrunner]

Works perfectly fine here!

[lukas1760]

Great job!