On 01/29/2013 01:30 PM, Thierry Reding wrote: >> Right. Now I know the background. >> However I do not agree with the conclusion. Probably it is fine in some cases >> to limit the number of configurable duty cycles to have only distinct steps. >> To not go too far, on my laptop I have: >> # cat /sys/class/backlight/acpi_video0/max_brightness >> 15 >> # cat /sys/class/backlight/intel_backlight/max_brightness >> 93 > > FWIW, I have hardware with an Intel chipset that has max_brightness > 13666. That doesn't mean all of these are necessarily valid or useful. For sure this range is overkill, but if you reduce it to let's say 15 would it be better? I don't think. It is up to the userspace to decide how to use it. User should have full control over the HW in hand. In this particular case I would expect userspace to give you around 20 steps to change brightness and when you change it would step between those so you will have nice, smooth changes and not big jumps. > That's not true. The duty-cycle merely defines a percentage of how long > the PWM signal will be high. You can choose an arbitrary number of > subdivisions. Sure all HW has limitation. The HW I have either have 127 or 255 time slots. Probably the best thing way to deal with the backlight is to have a range of 0 - 100% Nothing else. We should have an API to PWMs so user drivers could get the duty cycle from the HW drivers. In this way backlight would only expose percentage and the backlight driver would get the number of time slots from the PWM core to calculate the actual value for the selected percentage. > Since the brightness of a display isn't linearly proportional to the > duty cycle of the PWM driving it, representing that brightness by a > linear range is misleading. Furthermore some panels have regions where > the backlight isn't lit at all or where changes in the PWM duty-cycle > don't make any difference. and all of this also depend on the surrounding light conditions as well. If the same device is used in low light condition you care about the lower light ranges more compared to when the same device is used in bright environment. In these case the user space has to be adopted to the conditions and one should not need to recompile the kernel/dtb just because the device is used in different environment. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html