Re: [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices

[David Herrmann]

Hi

On Wed, Sep 10, 2014 at 10:40 PM, Matthew Garrett
<matthew.garrett@xxxxxxxxxx> wrote:
> On Wed, 2014-09-10 at 17:54 +0200, David Herrmann wrote:
>
>>  * User-space currently has a hard-time figuring out which backlight device to
>>    use, and which backlight device belongs to which display. So far, most
>>    systems only provide backlight-devices for internal displays, so figuring out
>>    the connection is easy, but that might change with more capable external
>>    connectors.
>
> The parent device of the backlight will be the correct display, if the
> kernel has a meaningful way to determine that. We could do a better job
> in the ACPI code than we currently do, but (unfortunately) that requires
> us to know the ACPI IDs that each GPU vendor uses.

We also probe ACPI devices independently of PCI devices (or other
buses). So the actual DRM device might be created much later than the
backlight, thus it cannot be a parent of the backlight. We can try to
find a common ancestor, though.

>> This series tries to solve this problem with a much simpler approach:
>> Instead of moving backlights into DRM, we simply link DRM properties to a
>> backlight device. That is, the kernel manages a link between a connector and a
>> backlight device (or n backlight devices) which can be modified by udev in case
>> the kernel got it wrong (we don't want huge board-fixup-tables in the kernel).
>> User-space can now use the simpl DRM API to manage backlights, and the kernel
>> does not need any special driver code to make it work.
>
> This doesn't really simplify userspace significantly - something's still
> going to have to make the same policy decision as we do right now, and
> the kernel isn't really the right place to do that.

This patch allows to add really simple udev rules that implement any
policy we want. This way, we can keep the policy in user-space, but at
the same time it's no longer part of the compositors. Instead, we have
an independent place (udev rules) where to write that policy and tell
the kernel. I think this is an improvement. But of course, the
unprivileged access is the much more compelling argument.

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/