search

digitaltrails / ddcutil-service

A Dbus ddcutil server for control of DDC Monitors/VDUs
GNU General Public License v2.0
11 stars 1 forks source link

Support laptop displays - add virtual DDCA implementations to the service. #16

Open digitaltrails opened 6 months ago

digitaltrails commented 6 months ago

Support non-DDC laptop displays by allowing for a virtual implementations of DDC.

Virtual implementations would fake up DDC data for the non DDC device by consulting and altering files under /sys/class or doing whatever is necessary to perform the requested operation.

$ ls /sys/class/backlight/acpi_video0/
actual_brightness  brightness         max_brightness     subsystem/    uevent             
bl_power           device/            power/             type

The actual files and location vary depending on the laptop manufacturer.

For example a call to detect might call the actual detect in libddcutil and then merge that with the results from a virtual implementations inspection of /sys/class/backlight. A call the setvcp on a virtual implementation might translate the set to write to /sys/class/backlight/acpi_video0/brightness

Capabilities enquiries on virtual implementations would just fake up DDC features for what's possible (brightness and maybe contrast).

This could also be done at a higher level in an application, see: vdu_controls/issues/44. Or at a lower level in ddcutil/libddcutil.

digitaltrails commented 6 months ago

One issue is potential variability and reliability of different hardware and driver combos. It would be disappointing if most laptops didn't bend to this approach, or if the quality of drivers ment the result was a bit of a lottery.

jpetso commented 6 months ago

KDE's implementation of this can be found in powerdevil for Plasma 6.0. Getting this right is tricky though and at the time of writing, it's still not quite correct.

Furthermore, as the recent Season of KDE project proposal notes, not all displays actually have a backlight. And displays in HDR mode generally also don't allow brightness manipulation that way. Hence the goal to bring it into the compositor, which can distinguish between different display capabilities and employ software dimming (or other effects) if hardware methods aren't supported.

So, it's not just drivers. Even if you do this right, be mindful that your support will still be incomplete.

digitaltrails commented 6 months ago

Thanks, I had intended to have a look at what powerdevil was doing. I just watched the video Kernel Recipes 2022 - New userspace api for display panel brightness-control (mentioned in a discussion at https://invent.kde.org/). As I haven't purchased a laptop in the last two decades, it was very enlightening, and very discouraging.

As I don't own any laptop hardware (except one 20 year old XP machine), and it looks like I would need to purchase many, I'm probably going to put this on the back burner.

digitaltrails commented 6 months ago

Maybe a termcap or config.d approach would work ok. Presumably a manufacturer, model and serial can be extracted from the EDID, then a termcap or config.d could identify which files to consult to get/set brightness and max-brightness, plus define any special handling. I guess there might be some need to define what udev rules need to be in place to obtain the necessary permissions.

If a general enough approach can be defined, it would up to others to figure out and contribute definitions for manufacturers and/or models. Users with special cases could add definitions down to the serial-number level. Over time, a termcap or config.d could fill out, plus code and config-syntax to handle weird cases could be added.

Given the current state of play, it's possible a config lookup may also have to involve GPU and GPU-driver.