On Fri, 24 Feb 2017, Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
