-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtual ambiance light indicator device #6
Comments
I don't understand your request...clightd already has a dbus API to set monitor backlight.
|
Closing as reporter did not answer back. Feel free to reopen the issue. |
Sorry for slow reply, i just was in trouble with finding answer. Though writing dedicated guis for clight is possible (and even wanted by those, who know clight), meanwhile brightness controll and virtual light sensor could be separate as well. For now DE's own brightness control has to be disabled in order to let clight brightness module run (it is probably not good idea to let different powermanagers interfere). At the same time lightsensor module may send lightness values as input for virtual device module... i'm only unsure, is there some dummy/testing driver for that (i only know, there are testing drivers for various device types). |
I'm not sure i understood it :) I'll try to answer!
Separate daemons are needed as:
My long-term idea/hope is to convert these DEs features to directly use clightd. I know it seems impossible right now though.
Hopefully, as soon as i find time, a dbus API to query clight status and enable/disable modules is in clight todo. This way, creating a GUI should be quite simple. |
Ah, now i understood goals.
Then it would need support for all kinds of hardware sensors.
I did not mean separation between root/user parts. I meaned rather further separation of brightness module, moving camera2lightness calc module to separate module... |
Ok i now understand.
Yes, this may be correct (and a nice extension of clight features): clight will then have a "webcam driver" and may be any other "X source driver", where "X source" can be any other hardware, like an ambient sensor. I see a couple of issues, though:
It would be great though, but it is probably a huge amount of work that i'm not willing to do right now. |
Today i discovered about ColorHug ALS, which is usb dongle light sensor. |
Very cool thanks for the info! |
@nick87720z By the way, as it seems you are really interested in clight/clightd (at least i hope!); are you by chance a developer? |
It is rather hobby now. I don't feel self very performant for now :) Btw, for example about root part: I looked to xfce4-power-manager files layout, there are only two helpers |
It would be great if you feel :) |
Edit: If I should just split this into a different issue just let me know! I'm really interested in generic light sensing sources for Clight/Clightd, since my device has a simple accessible ambient light sensor, and a pain of a camera. None of this answers the question about external ambient light sensors, but there is a unified api for ACPI ones at least, and I would love to be able to use that with Clight. It appears there is a standard kernel sysfs ACPI 0008 device for getting ambient illuminance: https://cateee.net/lkddb/web-lkddb/ACPI_ALS.html It shows up on my MacBookAir 6,2 as
Both return the same values for me, but input can be subject to some correction and normalization supposedly? (See below IIO docs.) _raw is supposedly raw, but still converted into Lux/SI. This may just be duplicate data because the original patch appears to have been converted to the IIO ABI later on. I get a range from There are also vendor specific paths which return the sensor data as reported, one on my device is: These docs are general about the iio (Industrial I/O) ABI, rather than the specific ACPI device output. They do includes some of the in_illumninance_[raw,input] paths, so mildly helpful about interactions? |
I think the proper way to achieve this is to add a new "capture_light" method to clightd API, and then let clight use proper method (capture_frames or capture_light) based upon device specified in its config file. I'll obviously need your help though as i cannot test anything :) Can you share me your: |
i had to change the path since /sys/class/als doesn't exist any more. It looks like it's just an ACPI part. For the uvevadm output I went another layer deeper to the iio device0 folder that has the sensor files (in_illuminance_input, etc) Paths:
For reference: |
Very nice, thanks!
Very unfortunate :( Most important things i note in your output:
Is this ok? I mean they are both 0... |
No worries, that's correct and reflects the reading of my sensor. I was in a dark room and I have a sticker that covers the camera/ALS. It is responsive when I add light. It also looks like the ACPI readings are not a direct conversion of the applesmc.768 readings. Readings appear to be accurate enough (compared with Wikipedia Lux chart)
|
That's great! Shouldn't max value be 255 though? |
The vendor specific applesmc.768 only returns 256 discrete values covering the sensor range. (0-255.) I was only using that for validation though. The ACPI interface returns Lux (estimated) and I was able to get it to go up to 4095. So I think it covers 4096 values (12bit precision) at least on my hardware. For screens today, at 4095 lux the user probably would have their screen at full brightness. At full saturation (flashlight on top of ALS/camera):
Lux is absolute, so 0 should always be 0 across sensors, and 4096 Lux is already quite bright, so we could use that as the max brightness threshold for Clight's use. But the lux variable should probably be handled as a 32bit signed int, since that's how the driver uses it. Also, I get this info from So it looks like the driver uses it as a 32bit signed number, in LE with 0 right shifts. Per the data here: https://github.com/01org/iio_testing_framework/blob/master/iio_sample_format.c#L45 |
Thank you very much, your info were really helpful!
will it be the same for every als device? (i guess yes, it will). |
@beret Can you test once more with this code: and paste here the output? |
Referring to this, DEVTYPE should be "iio_device", that obviously does not give us any information whether this device is an ALS device. We should alawys check for |
With the new test code, in a dark room:
I haven't tested on other devices, but it makes sense that all sensors using the kernel ACPI-ALS driver would report that type. If you need to, the udev parent's Sorry I wasn't able to test sooner! |
Great! I think ATTRS{name}=="ACPI-ALS" is already a good way to filter als devices. Then I need to port Clight to new Clightd interface :)
No problem at all! Thank you! |
@beret For me als support in Clightd is completed; I still need to add support for new interface in clight. The work will stay in als branch until clight catch up with new clightd interface (in a devel branch). It would be great if you can test clightd new interface cloning the repository and building from ALS branch. They should both return current luminance as a double. Note that "Sensor" is just a high level interface that will use ALS or WEBCAM depending on which one is available. It checks ALS first as obviously it is the best and most accurate option. |
I'll test this tonight and report back! |
It builds fine, and strace shows it is reading the right file and getting the right values: However, dbus does not output the right values, and always prints zero. In a dark room:
In a dim room:
With a flashlight pointing at the sensor:
For comparison, udev_als.c reads the values correctly.
|
Thanks! It works then. The issue is that, quite obviously, i forgot to cast "illuminance" to double before division, here: https://github.com/FedeDP/Clightd/blob/als_support/src/sensors/als.c#L12. |
The above issue is now fixed, so i expect the code to work. It is ready to be merged to master. Clight is slowly catching up, unfortunately it is not yet ready. |
Yup, that was it! It now goes from 0 to full (4095.)
|
Fixed in f948833. Note also that travis build is not broken; the script i use to build has some weird issues. |
Obviously, let me know if everything works as expected :) |
While there are already existing tools to control backlight (usually in DE settings), color temperature (redshift, f.lux), dpms and dimming (also both DE settings, more likely in power-man part), and even some integration with ambiant light sensors (i found mention, that gnome automatically uses it to adjust brightness, if such sensor found), there are only lack of something to use webcam as light sensor.
Having some virtual device, which actually gets brightness from software, instead of hardware, would allow to things to work in more standard way. Virtual device may have input, either for video buffer (so, module itself does all calculation for final brightness value) or light level itself (i.e., userspace daemon calculates value by own, and uses virtual device only to submit results).
Probably, second variant looks more desirable, as daemon would be needed anyway, to do input.
The text was updated successfully, but these errors were encountered: