ALS not working #88

guillaumeboehm · 2022-08-14T09:30:21Z

I'm using a Delta 15 A5EFK laptop under Arch-5.19.1-zen1-1-zen with clight 4.8-fc3df9c and clightd 5.6-77b1953.

Here is my clight.log
busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor IsAvailable "s" "" returns sb "/dev/iio:device0" true
The FedeDP/Clight#111 (comment) fix results in AE_NOT_FOUND

I'm starting to run out of options and don't know where to look anymore.

The text was updated successfully, but these errors were encountered:

FedeDP · 2022-08-14T18:08:05Z

Hi! Thanks for opening this issue!
What does clightd Capture method say (instead of the IsAvailable one)?

guillaumeboehm · 2022-08-15T15:53:02Z

Hi, not exactly sure what you want me to test but running something like busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor Capture "sis" "" 5 "" returns sad "/dev/iio:device0" 5 0 0 0 0 0

FedeDP · 2022-08-15T17:16:14Z

Hi! Exactly that, thank you!
That's really weird (of course it is!); I will give it a proper look once I am back home with a proper laptop :) (on vacation rn!)

guillaumeboehm · 2022-08-15T20:40:26Z

Sure thing, thanks a lot. Here is my clight.conf in case it helps. Have a great rest of your vacation.

FedeDP · 2022-08-15T20:57:52Z

Thank you! :)

FedeDP · 2022-08-20T22:19:46Z

The clight conf is fine indeed!
It seems like the issue is that the Clightd ALS module is not able to capture through the als device, even if it finds it.
As you can see, the ALS capture method is pretty simple: https://github.com/FedeDP/Clightd/blob/master/src/modules/sensors/als.c#L60.

To debug your issue, you can try this (very simple) patch:

diff --git a/src/modules/sensors/als.c b/src/modules/sensors/als.c
index 016ad1c..f94f3ba 100644
--- a/src/modules/sensors/als.c
+++ b/src/modules/sensors/als.c
@@ -72,6 +72,8 @@ static int capture(void *dev, double *pct, const int num_captures, char *setting
             scale = atof(val);
         }
     }
+    
+    printf("Scale: %lf\n", scale);
 
     for (int i = 0; i < num_captures; i++) {
         struct udev_device *non_cached_dev = udev_device_new_from_syspath(udev, udev_device_get_syspath(dev));
@@ -79,6 +81,7 @@ static int capture(void *dev, double *pct, const int num_captures, char *setting
         for (int j = 0; j < SIZE(ill_names) && illuminance == -1; j++) {
             val = udev_device_get_sysattr_value(non_cached_dev, ill_names[j]);
             if (val) {
+                printf("Val: %s\n", val);
                 illuminance = atof(val) * scale;
                 ctr++;
                 pct[i] = compute_value(illuminance);

and then, manually run Clightd; the quicker way is:

stop clight
systemctl stop clightd
apply the patch
build clightd
run clightd
call again the busctl capture command
checkout clightd terminal output

hedmo · 2023-01-05T10:02:10Z

hi .
i jump in this issue as well because of the the title. i have many systems and all have the same problems. the ALS is always reports 0%. when i check on sensor-monitor (iio-sensor-proxy) i can see changes when i use a lamp to the sensor but not in clight . camera (video0) works. i will add the patch to my ebuild and report back.

FedeDP · 2023-03-04T18:34:34Z

Hi @hedmo ! Any news on this?
Thanks for reporting btw!

hedmo · 2023-03-04T20:39:34Z

@FedeDP

i have added the patch. ATM i have the sensor at 49%. will report in a day or two...

FedeDP · 2023-03-04T20:49:30Z

Thank you very much!

hedmo · 2023-03-07T16:49:11Z

after a day or two . i have to report it still sty at 0% . and does not change ...

FedeDP · 2023-03-07T17:25:34Z

Can you share clightd output with the patch?

FedeDP · 2023-03-07T17:39:46Z

Moreover, can you share output of

udevadm info --all /dev/iio:device0

?

hedmo · 2023-03-08T18:52:52Z

Can you share clightd output with the patch?

are you talking about the output when starting clight?

hedmo · 2023-03-08T18:53:24Z

Moreover, can you share output of
udevadm info --all /dev/iio:device0
?

hedmo@my300 ~ $ sudo udevadm info /dev/iio:device0
P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0008:00/iio:device0
M: iio:device0
R: 0
U: iio
T: iio_device
D: c 238:0
N: iio:device0
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0008:00/iio:device0
E: DEVNAME=/dev/iio:device0
E: DEVTYPE=iio_device
E: MAJOR=238
E: MINOR=0
E: SUBSYSTEM=iio
E: USEC_INITIALIZED=6196915
E: IIO_SENSOR_PROXY_TYPE=iio-poll-als iio-poll-als
E: SYSTEMD_WANTS=iio-sensor-proxy.service
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

FedeDP · 2023-03-08T18:54:22Z

Can you add the "--all" flag to the udevadm command?
Thanks!

hedmo · 2023-03-08T18:57:41Z

i did : hedmo@my300 ~ $ sudo udevadm info --all /dev/iio:device0
info: unrecognized option '--all'

hedmo · 2023-03-08T19:00:01Z

can this be the on you want ?

hedmo@my300 ~ $ sudo udevadm info -a /dev/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/ACPI0008:00/iio:device0':
    KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{buffer/data_available}=="0"
    ATTR{buffer/direction}=="in"
    ATTR{buffer/enable}=="0"
    ATTR{buffer/length}=="2"
    ATTR{buffer/watermark}=="1"
    ATTR{buffer0/data_available}=="0"
    ATTR{buffer0/direction}=="in"
    ATTR{buffer0/enable}=="0"
    ATTR{buffer0/in_illuminance_en}=="0"
    ATTR{buffer0/in_illuminance_index}=="0"
    ATTR{buffer0/in_illuminance_type}=="le:s32/32>>0"
    ATTR{buffer0/in_timestamp_en}=="0"
    ATTR{buffer0/in_timestamp_index}=="1"
    ATTR{buffer0/in_timestamp_type}=="le:s64/64>>0"
    ATTR{buffer0/length}=="2"
    ATTR{buffer0/watermark}=="1"
    ATTR{current_timestamp_clock}=="realtime"
    ATTR{in_illuminance_input}=="0"
    ATTR{in_illuminance_raw}=="0"
    ATTR{name}=="acpi-als"

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/ACPI0008:00/iio:device0':
    KERNEL=="iio:device0"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{buffer/data_available}=="0"
    ATTR{buffer/direction}=="in"
    ATTR{buffer/enable}=="0"
    ATTR{buffer/length}=="2"
    ATTR{buffer/watermark}=="1"
    ATTR{buffer0/data_available}=="0"
    ATTR{buffer0/direction}=="in"
    ATTR{buffer0/enable}=="0"
    ATTR{buffer0/in_illuminance_en}=="0"
    ATTR{buffer0/in_illuminance_index}=="0"
    ATTR{buffer0/in_illuminance_type}=="le:s32/32>>0"
    ATTR{buffer0/in_timestamp_en}=="0"
    ATTR{buffer0/in_timestamp_index}=="1"
    ATTR{buffer0/in_timestamp_type}=="le:s64/64>>0"
    ATTR{buffer0/length}=="2"
    ATTR{buffer0/watermark}=="1"
    ATTR{current_timestamp_clock}=="realtime"
    ATTR{in_illuminance_input}=="0"
    ATTR{in_illuminance_raw}=="0"
    ATTR{name}=="acpi-als"
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"
    ATTR{scan_elements/in_illuminance_en}=="0"
    ATTR{scan_elements/in_illuminance_index}=="0"
    ATTR{scan_elements/in_illuminance_type}=="le:s32/32>>0"
    ATTR{scan_elements/in_timestamp_en}=="0"
    ATTR{scan_elements/in_timestamp_index}=="1"
    ATTR{scan_elements/in_timestamp_type}=="le:s64/64>>0"
    ATTR{trigger/current_trigger}=="acpi-als-dev0"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0008:00':
    KERNELS=="ACPI0008:00"
    SUBSYSTEMS=="acpi"
    DRIVERS=="acpi_als"
    ATTRS{hid}=="ACPI0008"
    ATTRS{path}=="\_SB_.ALS_"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{status}=="11"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00':
    KERNELS=="LNXSYBUS:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{hid}=="LNXSYBUS"
    ATTRS{path}=="\_SB_"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/LNXSYSTM:00':
    KERNELS=="LNXSYSTM:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{hid}=="LNXSYSTM"
    ATTRS{path}=="\"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"

FedeDP · 2023-03-08T20:07:52Z

can this be the on you want ?

Exactly, thanks!

ATTR{in_illuminance_input}=="0"
ATTR{in_illuminance_raw}=="0"

These ones are the 2 udev ATTRibutes that Clightd uses; they are both 0 :/ That's why it reads 0.

Fact is, i don't see any attribute with a possible value. I will check out iio-sensor-proxy source code to understand what they use ;)

FedeDP · 2023-03-08T21:08:20Z

Well, it seems like iio-sensor-proxy actually uses similar logic as Clightd:

Checks "in_illuminance_{input,raw}": https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/blob/master/src/drv-iio-poll-light.c#L68
Matching sensor type is iio-poll-als (that is the one you are using, given your udev output above): https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/blob/master/src/drv-iio-poll-light.c#L31
To read data, it just reads file from sysfs: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/blob/master/src/drv-iio-poll-light.c#L52 (i use udev instead: https://github.com/FedeDP/Clightd/blob/master/src/modules/sensors/als.c#L80)

I don't get how it is working while Clightd is not. Perhaps updates are not exposed through udev?
I will further investigate!

FedeDP · 2023-03-08T21:33:48Z

Oh it seems like iio-sensor-proxy gives higher priority to iio-buffer-als devices than iio-poll-devices.
Given that your als device exposes both, it surely uses iio-buffer-als and that is not supported by Clightd!
I will work on it asap :) but i will surely need your feedback on the PR! Will ping you once I've got something that should work! Thank you!

EDIT: nope I am wrong your als devices only supports iio-poll-als :/

hedmo · 2023-03-09T12:38:17Z

more info .now when it is day here i do have a working clight with als. i will continue to check on it under the day and reboot some times to confirm it does work ..

FedeDP · 2023-06-15T19:33:57Z

Ehy everyone, in #102 i implemented support for iio buffer ALS sensor read.
Can you test it? I unfortunately haven't got any ALS device :/

guillaumeboehm · 2023-06-18T11:24:56Z

Hey, I'm testing the build from #102 and it doesn't seem to fix it... I'm not exactly sure what's the best way to test it, but rn I'm simply trying to block the sensor physically and see if with the ambiant gamma activated it changes something but it doesn't seem so. I can produce some dumps if you point me the direction.

FedeDP · 2023-06-18T14:19:16Z

Hi! Thank you very much for testing! Yes, can you share clightd log and output of Sensor.Capture dbus method call?

guillaumeboehm · 2023-06-18T15:53:53Z

Okay so busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor IsAvailable "s" "" returned sb "/dev/iio:device2" true.

Here is what clightd logs after starting

Registered 'Sysfs' bl plugin.
Registered 'Als' sensor plugin.
Registered 'Camera' sensor plugin.
Registered 'Custom' sensor plugin.
Registered 'Drm' gamma plugin.
Registered 'Wl' gamma plugin.
Registered 'Xorg' gamma plugin.
Registered 'Drm' dpms plugin.
Registered 'KWin_wl' dpms plugin.
Registered 'Wl' dpms plugin.
Registered 'Xorg' dpms plugin.
Registered 'Fb' screen plugin.
Registered 'Wl' screen plugin.
Registered 'Xorg' screen plugin.
[default]|GAMMA|: Current gamma value: 3728.
[default]|IDLE|: Creating client 0
[default]|IDLE|: Creating client 1
[default]|IDLE|: Adding inotify watch as first client was started.
[default]|IDLE|: Starting Client 1
[default]|GAMMA|: Current gamma value: 3728.
[default]|IDLE|: Creating client 2
[default]|IDLE|: Creating client 3
[default]|IDLE|: Starting Client 3
[default]|BACKLIGHT2|: Target pct: 0.15
[default]|GAMMA|: Temperature target value set: 3954.
[default]|GAMMA|: Reached target temp: 3954.
[default]|BACKLIGHT2|: amdgpu_bl1 reached target backlight: 0.15.
[default]|BACKLIGHT2|: Target pct: 0.16
[default]|BACKLIGHT2|: amdgpu_bl1 reached target backlight: 0.16.
[default]|GAMMA|: Temperature target value set: 3982.
[default]|GAMMA|: Reached target temp: 3982.

And how can I get the output of the sensor ?

I also saw you used the output of udevadm so here it is:

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/0020:1022:0001.000E/HID-SENSOR-200041.5.auto/iio:device2':
    KERNEL=="iio:device2"
    SUBSYSTEM=="iio"
    DRIVER==""
    ATTR{buffer/data_available}=="0"
    ATTR{buffer/direction}=="in"
    ATTR{buffer/enable}=="0"
    ATTR{buffer/length}=="4"
    ATTR{buffer/watermark}=="1"
    ATTR{buffer0/data_available}=="0"
    ATTR{buffer0/direction}=="in"
    ATTR{buffer0/enable}=="0"
    ATTR{buffer0/in_illuminance_en}=="0"
    ATTR{buffer0/in_illuminance_index}=="1"
    ATTR{buffer0/in_illuminance_type}=="le:s32/32>>0"
    ATTR{buffer0/in_intensity_both_en}=="0"
    ATTR{buffer0/in_intensity_both_index}=="0"
    ATTR{buffer0/in_intensity_both_type}=="le:s32/32>>0"
    ATTR{buffer0/in_timestamp_en}=="0"
    ATTR{buffer0/in_timestamp_index}=="2"
    ATTR{buffer0/in_timestamp_type}=="le:s64/64>>0"
    ATTR{buffer0/length}=="4"
    ATTR{buffer0/watermark}=="1"
    ATTR{current_timestamp_clock}=="realtime"
    ATTR{in_illuminance_hysteresis_relative}=="0.000000"
    ATTR{in_illuminance_offset}=="0"
    ATTR{in_illuminance_raw}=="5244241"
    ATTR{in_illuminance_sampling_frequency}=="0.000000"
    ATTR{in_illuminance_scale}=="0.100000000"
    ATTR{in_intensity_both_raw}=="5244241"
    ATTR{in_intensity_hysteresis_relative}=="0.000000"
    ATTR{in_intensity_offset}=="0"
    ATTR{in_intensity_sampling_frequency}=="0.000000"
    ATTR{in_intensity_scale}=="0.100000000"
    ATTR{name}=="als"
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"
    ATTR{scan_elements/in_illuminance_en}=="0"
    ATTR{scan_elements/in_illuminance_index}=="1"
    ATTR{scan_elements/in_illuminance_type}=="le:s32/32>>0"
    ATTR{scan_elements/in_intensity_both_en}=="0"
    ATTR{scan_elements/in_intensity_both_index}=="0"
    ATTR{scan_elements/in_intensity_both_type}=="le:s32/32>>0"
    ATTR{scan_elements/in_timestamp_en}=="0"
    ATTR{scan_elements/in_timestamp_index}=="2"
    ATTR{scan_elements/in_timestamp_type}=="le:s64/64>>0"
    ATTR{trigger/current_trigger}=="als-dev2"

  looking at parent device '/devices/0020:1022:0001.000E/HID-SENSOR-200041.5.auto':
    KERNELS=="HID-SENSOR-200041.5.auto"
    SUBSYSTEMS=="platform"
    DRIVERS=="hid_sensor_als"
    ATTRS{driver_override}=="(null)"
    ATTRS{power/autosuspend_delay_ms}=="3000"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="3161354"
    ATTRS{power/runtime_status}=="active"
    ATTRS{power/runtime_suspended_time}=="168086918"

  looking at parent device '/devices/0020:1022:0001.000E':
    KERNELS=="0020:1022:0001.000E"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-sensor-hub"
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"

FedeDP · 2023-06-18T16:51:51Z

What about:

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

?

guillaumeboehm · 2023-06-18T16:54:51Z

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

it returns this sad "/dev/iio:device2" 5 0 0 0 0 0

FedeDP · 2023-06-18T16:57:00Z

Ok! I will add some debug prints to the PR so that we can better understand what's going on :)
I will ping you back once I pushed the changes!
Thank you very much btw, we will fix this, i promise you!

guillaumeboehm · 2023-06-18T16:59:30Z

I should thank you for being so proactive about it !

FedeDP · 2023-06-18T19:04:51Z

Hey i just pushed a commit whichadds debug prints! eae2ad9

guillaumeboehm · 2023-06-18T20:59:17Z

Here you go, I rebooted so the device name changed

Registered 'Sysfs' bl plugin.
Registered 'Als' sensor plugin.
Registered 'Camera' sensor plugin.
Registered 'Custom' sensor plugin.
Registered 'Drm' gamma plugin.
Registered 'Wl' gamma plugin.
Registered 'Xorg' gamma plugin.
Registered 'Drm' dpms plugin.
Registered 'KWin_wl' dpms plugin.
Registered 'Wl' dpms plugin.
Registered 'Xorg' dpms plugin.
Registered 'Fb' screen plugin.
Registered 'Wl' screen plugin.
Registered 'Xorg' screen plugin.
[default]|GAMMA|: Current gamma value: 3942.
[default]|IDLE|: Creating client 0
[default]|IDLE|: Creating client 1
[default]|IDLE|: Adding inotify watch as first client was started.
[default]|IDLE|: Starting Client 1
Buffer available, using 'scan_elements/in_illuminance_en' sysattr
Poll available, using 'in_illuminance_raw' sysattr
Buffer available, using 'scan_elements/in_illuminance_en' sysattr
Poll available, using 'in_illuminance_raw' sysattr
[IIO-BUF] Start capture: 'iio:device4' sysname.
[IIO-BUF] Found device.
[IIO-BUF] Channel name: 'illuminance'.
[IIO-BUF] Creating buffer.
WARNING: High-speed mode not enabled
[IIO-BUF] Data fmt: bits: 32 | signed: 1 | len: 32 | rep: 1 | scale: 0.100000 | has_scale: 1 | shift: 0.
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[0] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[1] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[2] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[3] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[4] = 0.000000
[default]|BACKLIGHT2|: Target pct: 0.15
[default]|BACKLIGHT2|: amdgpu_bl1 reached target backlight: 0.15.
[default]|GAMMA|: Temperature target value set: 3935.
[default]|GAMMA|: Reached target temp: 3935.
[default]|GAMMA|: Current gamma value: 3942.
[default]|IDLE|: Creating client 2
[default]|IDLE|: Creating client 3
[default]|IDLE|: Starting Client 3
Buffer available, using 'scan_elements/in_illuminance_en' sysattr
Poll available, using 'in_illuminance_raw' sysattr
Buffer available, using 'scan_elements/in_illuminance_en' sysattr
Poll available, using 'in_illuminance_raw' sysattr
[IIO-BUF] Start capture: 'iio:device4' sysname.
[IIO-BUF] Found device.
[IIO-BUF] Channel name: 'illuminance'.
[IIO-BUF] Creating buffer.
WARNING: High-speed mode not enabled
[IIO-BUF] Data fmt: bits: 32 | signed: 1 | len: 32 | rep: 1 | scale: 0.100000 | has_scale: 1 | shift: 0.
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[0] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[1] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[2] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[3] = 0.000000
[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[4] = 0.000000
[default]|BACKLIGHT2|: Target pct: 0.15
[default]|GAMMA|: Temperature target value set: 3935.
[default]|GAMMA|: Reached target temp: 3935.
[default]|BACKLIGHT2|: amdgpu_bl1 reached target backlight: 0.15.

Hopefully my sensor is actually working correctly, I'll look for a way to confirm that it's working correctly.

FedeDP · 2023-06-18T21:53:18Z

[IIO-BUF] Refill ret: 4/4
[IIO-BUF] Read 0
[IIO-BUF] Pct[0] = 0.000000

It seems like we are correctly reading data, but data is always 0 :/
Can you share ls /sys/bus/iio/devices/*/ output?
It seems like your kernel is generating multiple iio:device nodes, and i'd like to know if you really got multiple iio sensors :)

Thank you!

I'll look for a way to confirm that it's working correctly.

Best way IMHO is to use https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/ that is Gnome/freedesktop implementation of a dbus API around iio devices. It should be already packaged in your distro repos (at least it is, on arch!).
Note however that Clightd with the patch should exactly match its behavior!

guillaumeboehm · 2023-06-19T16:55:42Z

Here's my devices

/sys/bus/iio/devices/iio:device0/:
 buffer    dev                  in_magn_offset               in_magn_scale   in_magn_y_raw   name    scan_elements   trigger
 buffer0   in_magn_hysteresis   in_magn_sampling_frequency   in_magn_x_raw   in_magn_z_raw   power   subsystem       uevent

/sys/bus/iio/devices/iio:device1/:
 buffer    current_timestamp_clock   in_accel_hysteresis   in_accel_sampling_frequency   in_accel_x_raw   in_accel_z_raw   power           subsystem   uevent
 buffer0   dev                       in_accel_offset       in_accel_scale                in_accel_y_raw   name             scan_elements   trigger    

/sys/bus/iio/devices/iio:device2/:
 buffer    current_timestamp_clock   in_anglvel_hysteresis   in_anglvel_sampling_frequency   in_anglvel_x_raw   in_anglvel_z_raw   power           subsystem   uevent
 buffer0   dev                       in_anglvel_offset       in_anglvel_scale                in_anglvel_y_raw   name               scan_elements   trigger    

/sys/bus/iio/devices/iio:device3/:
 buffer    dev                       in_proximity_offset   in_proximity_sampling_frequency   name    scan_elements   trigger
 buffer0   in_proximity_hysteresis   in_proximity_raw      in_proximity_scale                power   subsystem       uevent

/sys/bus/iio/devices/iio:device4/:
 buffer                    in_illuminance_hysteresis            in_illuminance_sampling_frequency   in_intensity_hysteresis_relative   name            trigger
 buffer0                   in_illuminance_hysteresis_relative   in_illuminance_scale                in_intensity_offset                power           uevent
 current_timestamp_clock   in_illuminance_offset                in_intensity_both_raw               in_intensity_sampling_frequency    scan_elements  
 dev                       in_illuminance_raw                   in_intensity_hysteresis             in_intensity_scale                 subsystem      

/sys/bus/iio/devices/trigger0/:
 name   power   subsystem   uevent

/sys/bus/iio/devices/trigger1/:
 name   power   subsystem   uevent

/sys/bus/iio/devices/trigger2/:
 name   power   subsystem   uevent

/sys/bus/iio/devices/trigger3/:
 name   power   subsystem   uevent

/sys/bus/iio/devices/trigger4/:
 name   power   subsystem   uevent

I tested stuff a bit with udevadm, and it's weird my illuminance, if I'm looking in the right place, seems to never change... ATTR{in_illuminance_raw}=="5244241" sometimes it's 0 and jumps back to that value. Maybe I actually have a problem with my sensor ?

FedeDP · 2023-06-21T21:03:57Z

Thanks for the output! So you got multiple sensors, nice!
Well, if your sensor only sees 0 or a weird value, perhaps it has some issues? I am not sure though...again, if iio-sensor-proxy does output the same as clightd, then chances are that the sensor is broken/its support is broken...https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/

guillaumeboehm mentioned this issue Aug 27, 2022

The gui is all grayed at startup nullobsi/clight-gui#27

Open

FedeDP mentioned this issue Apr 16, 2023

[BUG] ALS detected but doesn't really work FedeDP/Clight#277

Closed

FedeDP mentioned this issue Jun 15, 2023

new(sensors): implemented iio buffer support for als sensor. #102

Merged

FedeDP closed this as completed in #102 Nov 4, 2023

ALS not working #88

ALS not working #88

Comments

guillaumeboehm commented Aug 14, 2022

FedeDP commented Aug 14, 2022 • edited Loading

guillaumeboehm commented Aug 15, 2022

FedeDP commented Aug 15, 2022

guillaumeboehm commented Aug 15, 2022

FedeDP commented Aug 15, 2022

FedeDP commented Aug 20, 2022 • edited Loading

hedmo commented Jan 5, 2023

FedeDP commented Mar 4, 2023

hedmo commented Mar 4, 2023

FedeDP commented Mar 4, 2023

hedmo commented Mar 7, 2023

FedeDP commented Mar 7, 2023

FedeDP commented Mar 7, 2023 • edited Loading

hedmo commented Mar 8, 2023

hedmo commented Mar 8, 2023

FedeDP commented Mar 8, 2023

hedmo commented Mar 8, 2023

hedmo commented Mar 8, 2023 • edited by FedeDP Loading

FedeDP commented Mar 8, 2023

FedeDP commented Mar 8, 2023

FedeDP commented Mar 8, 2023 • edited Loading

hedmo commented Mar 9, 2023

FedeDP commented Jun 15, 2023

guillaumeboehm commented Jun 18, 2023

FedeDP commented Jun 18, 2023

guillaumeboehm commented Jun 18, 2023

FedeDP commented Jun 18, 2023 • edited Loading

guillaumeboehm commented Jun 18, 2023

FedeDP commented Jun 18, 2023

guillaumeboehm commented Jun 18, 2023

FedeDP commented Jun 18, 2023

guillaumeboehm commented Jun 18, 2023

FedeDP commented Jun 18, 2023

guillaumeboehm commented Jun 19, 2023

FedeDP commented Jun 21, 2023

FedeDP commented Aug 14, 2022 •

edited

Loading

FedeDP commented Aug 20, 2022 •

edited

Loading

FedeDP commented Mar 7, 2023 •

edited

Loading

hedmo commented Mar 8, 2023 •

edited by FedeDP

Loading

FedeDP commented Mar 8, 2023 •

edited

Loading

FedeDP commented Jun 18, 2023 •

edited

Loading