On Tue, Jul 23, 2019 at 06:46:55PM +0800, Kai-Heng Feng wrote: > Hi, > > Currently, OLED panel brightness [1] is not supported. > We have a similar Dell system that also affect by lack of OLED brightness > support. > > I’ve investigated both kernel and user space but I haven’t found a good > general solution yet. > Dell systems use EDID descriptor 4 as Dell specific descriptor, which > reports its panel type and we can know it’s an OLED panel or not. > > My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to > let userspace like clutter [3] to control the brightness. > However other DEs may need to implement their own OLED brightness support > which isn’t ideal. > > So I’d like to know if there’s any good way to support OLED brightness in > good old backlight sysfs, to let userspace keep to the current interface. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=97883 > [2] https://pastebin.ubuntu.com/p/QYrRBppVT9/ > [3] https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter-brightness-contrast-effect.c#L559 I think the Most Proper Solution would be to integrate the backlight support into drm, by adding the backlight knobs as kms properties to the correct connector. This would fix a whole bag of issue: - no more ill-defined magic for userspace to find the right backlight - we could have well-defined semantics what happens with the backlight across a kms modeset - issues like this could be solved with a small helper and a bit of code in the kernel (there's also other DDC knobs to control backlight, which we also don't really expose in a consistent way). Downside is how to roll this out in a backward compatible way, without breaking the world: - fbcon/fbdev needs to be taught to not do it's own backlight wrangling for kms drivers which handle backlight natively - we might need an opt-in magic for this, if it turns out that the kms driver handling the backlight breaks stuff - userspace ofc needs to fall back to its current pile of hacks if the backlight stuff isn't supported natively. Adding more ill-defined sysfs files, or more magice ordering rules, or anything else like that doesn't sound too appealing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
