Questions on adding backlight support for the i915 driver

[Adrian Chadd]

On 30 January 2015 at 17:01, Elizabeth Myers <elizabeth at interlinked.me> wrote:
> On 01/30/15 17:45, John Baldwin wrote:
>> On Friday, January 30, 2015 04:45:45 PM Elizabeth Myers wrote:
>>> On 01/30/15 09:17, John Baldwin wrote:
>>>> Humm.  If the code is going to live in the drm driver, then I would
>>>> start with hanging a sysctl off of the drm device itself.  (Each new-bus
>>>> device_t has a sysctl ctx you can get to hang new nodes off of the
>>>> device's node.)
>>> I'm wondering if that's the correct place for it to live. So far it's
>>> the only real place it *can* live that makes logical sense imho, unless
>>> anyone has better ideas.
>>>
>>> This is awesome. As for upower, it should probably be patched to know
>>> about other types of brightness sysctls if/when this is implemented.
>> For now I think hanging it off of the device_t is fine.  It can be moved
>> later if there is an urgent need.  However, I suspect that tools like upower
>> will need updating regardless of where it ends up living.
>>
>
> Now a more interesting question... the raw PCM backlight value used by
> the hardware means that one can set the backlight to anything between 0
> and a specific number. On my system, it's 4882, and yes, there is a
> subtle difference between the values. Is it best to expose this as a
> percentage, or just have a read-only sysctl for max values?

So, this is one of the discussions that popped up in the linux side of
things, that we will end up eventually pulling into freebsd when the
i915 code is updated.

The raw value is (a) different per setup, and (b) may be inverted to
work correctly.

I also don't know if linear values along that spectrum map to linear
brightness levels.

So yeah, my suggestion we expose an ACPI/acpi_video like list of valid
percentages, and let the user set them from 0-100%. That way the
details of how the actual backlight values get derived are hidden from
userland.



-adrian