Clightd
Clightd copied to clipboard
FedeDP
ALS not working
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 https://github.com/FedeDP/Clight/issues/111#issuecomment-573604758 fix results in AE_NOT_FOUND
I'm starting to run out of options and don't know where to look anymore.
Hi! Thanks for opening this issue! What does clightd Capture method say (instead of the IsAvailable one)?
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
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!)
Sure thing, thanks a lot. Here is my clight.conf in case it helps. Have a great rest of your vacation.
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
busctlcapture command - checkout clightd terminal output
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
i have added the patch. ATM i have the sensor at 49%. will report in a day or two...
after a day or two . i have to report it still sty at 0% . and does not change ...
Can you share clightd output with the patch?
are you talking about the output when starting clight?
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:
i did : hedmo@my300 ~ $ sudo udevadm info --all /dev/iio:device0 info: unrecognized option '--all'
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"
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 ;)
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!
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 :/
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 ..
Ehy everyone, in https://github.com/FedeDP/Clightd/pull/102 i implemented support for iio buffer ALS sensor read. Can you test it? I unfortunately haven't got any ALS device :/
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.
Hi! Thank you very much for testing! Yes, can you share clightd log and output of Sensor.Capture dbus method call?
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"
What about:
busctl call org.clightd.clightd /org/clightd/clightd/Sensor/Als org.clightd.clightd.Sensor Capture "sis" "" 5 ""
?
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
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!