Re: KMS backlight ABI proposition

[Jani Nikula <jani.nikula@linux.intel.com>]

On Fri, 24 Feb 2017, Hans de Goede <hdegoede@redhat.com> wrote:
> On 24-02-17 09:43, Jani Nikula wrote:
>> I don't think we have any good ideas how to solve the property max
>> changing on the fly. But based on the discussion so far, it's starting
>> to look like we'll need to study that more thoroughly.
>
> As I mentioned in another part of the thread, I think we can just return
> -EBUSY if udev tries to change the binding when a drm-node is open
> *and* the backlight/brightness property has been accessed (even if
> read only) through that drm-node. We can reset the busy flag when
> the (last open) drm-node gets closed.

That's certainly easier than coming up with ways to notify the userspace
about property range changes. The obvious downside is that you have to
kill X to do the re-association. That's fine for when everything just
works (i.e. everything happens before the drm node is opened), but for
debugging it's a bit painful. Can we live with that?

> I'm adding the *and* the backlight/brightness property has been accessed
> condition so that udev can still do its thing while a boot splash
> screen is active. This assumes that boot splash screens do not
> touch the brightness.

I presume udev will have to do its job before the drm node is opened, I
think relying on the userspace not touching the brightness property is
going to be racy/flaky.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel