search

whatawurst / android_device_sony_yoshino-common

This is the Android device configuration for the yoshino platform
10 stars 48 forks source link

Minimum light setting limited by vendor blobs #64

Open Flamefire opened 2 years ago

Flamefire commented 2 years ago

I've seen lilac devices setting the minimum brightness to 34 not to 1 as it should.

Following that is quite hard, enabling some debug output I got this:

01-08 13:50:47.946  1440  1904 V LightsService: setLight #0: color=#ff030303: brightnessMode=0)
01-08 13:50:47.948   869   869 D illumination-service: 'backlight': Color ff030303, BrMode 0, OnMS 0, OffMS 0, Mode 0
01-08 13:50:47.948     0     0 D qpnp_wled_set_level: brightness=48 level=48
01-08 13:50:47.949     0     0 D level   : 48
01-08 13:50:48.328  1440  1904 V LightsService: setLight #0: color=#ff020202: brightnessMode=0)
01-08 13:50:48.330   869   869 D illumination-service: 'backlight': Color ff020202, BrMode 0, OnMS 0, OffMS 0, Mode 0
01-08 13:50:48.329     0     0 D qpnp_wled_set_level: brightness=34 level=34
01-08 13:50:48.331     0     0 D level   : 34
01-08 13:50:49.109  1440  1904 V LightsService: setLight #0: color=#ff010101: brightnessMode=0)
01-08 13:50:49.111   869   869 D illumination-service: 'backlight': Color ff010101, BrMode 0, OnMS 0, OffMS 0, Mode 0

I.e. a color of #ff020202 still works, but yields a brightness level of 34 while the lowest possible brightness color gets stuck in the illumination-service. That is extracted from stock at https://github.com/whatawurst/android_device_sony_lilac/blob/920e87e6d8a212246d22ec51c3cde15d984d9b6d/proprietary-files-vendor.txt#L828

Why do we copy that and lights.default.so from stock instead of using e.g. the module at https://github.com/whatawurst/android_device_sony_yoshino-common/blob/lineage-18.1/hardware/qcom-caf/display/liblight/lights.c or use a HIDL service implementation such as https://github.com/sonyxperiadev/device-sony-common/tree/fc6d709db9b4f44e8bfb410d8c7e7e67ca292a6a/hardware/liblights ?

Flamefire commented 2 years ago

Ok got some more info and possible solution: Removing the illumination service and the lights.default.so from the phone and adding lights.msm8998 to PRODUCT_PACKAGES works. However this severely limits the maximum brightness. Our kernels LED module has a max brightness of 4095: https://github.com/whatawurst/android_kernel_sony_msm8998/blob/lineage-18.1/drivers/leds/leds-qpnp-wled.c#L221 However the brightness conversion function only yields a value between 0-255 which means the brightness is limited to about 6% of the max brightness. In the old common-repo this was better: Brightness got scaled by the max brightness: https://github.com/whatawurst/android_device_sony_common-treble/blob/552bcb6e652f087d80b5bd9afffd2a09840b2788/hardware/lights/lights.c#L185

There is still a quirk though: As a brightness of "0" means "OFF", the lowest brightness before scaling is 1 which is scaled to 16 although the kernel driver and the LCD supports 1, so IMO we should support that. I.e. scaling should be something like real_brightness = (brightness == 255) ? max_brightness : (brightness - 1) * max_brightness / 255 + 1 This means we get the full range with a slightly larger step of brightness at the end which isn't a problem as brightness changes are perceived less the brighter the screen actually is.

@derfelot Are you interested in a PR for that?

Flamefire commented 2 years ago

FYI: I have a working implementation of this running for a month now without issues as far as I can tell and also removed the vendor blobs. Less binaries, less issues ;)

Most of the work is in https://github.com/Flamefire/android_device_sony_yoshino-common/pull/20, but needs https://github.com/Flamefire/android_device_sony_yoshino-common/commit/4cb34ee6a5ebcfbda573b4a0071d903c2b90715f & https://github.com/Flamefire/android_device_sony_yoshino-common/commit/9b6b3c09e74ddcbb8e09e87a67a3a1be4f6abd4b additionally as I noticed after more testing.

As mentioned: If you want this in this repo, I can create a PR for that. But as that requires some work with rebasing, etc. (my fork has a few custom changes) I won't do that unless you tell me you would use/merge that.

derfelot commented 2 years ago

sorry, I am a bit busy with the 19.0 bring-up right now. but i'll get back to you about all these things soon