From: David Herrmann <dh.herrmann@gmail.com> To: Matthew Garrett <matthew.garrett@nebula.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>, "jg1.han@samsung.com" <jg1.han@samsung.com>, "lee.jones@linaro.org" <lee.jones@linaro.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "cooloney@gmail.com" <cooloney@gmail.com>, "airlied@gmail.com" <airlied@gmail.com>, "ajax@redhat.com" <ajax@redhat.com> Subject: Re: [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices Date: Thu, 11 Sep 2014 14:48:59 +0200 [thread overview] Message-ID: <CANq1E4S6rzDSXXTQws1nPiAXkRgLMbADJJTCoLjONLFiR6wP4g@mail.gmail.com> (raw) In-Reply-To: <1410381657.4117.3.camel@nebula.com> Hi On Wed, Sep 10, 2014 at 10:40 PM, Matthew Garrett <matthew.garrett@nebula.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: David Herrmann <dh.herrmann@gmail.com> To: Matthew Garrett <matthew.garrett@nebula.com> Cc: "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>, "cooloney@gmail.com" <cooloney@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "lee.jones@linaro.org" <lee.jones@linaro.org> Subject: Re: [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices Date: Thu, 11 Sep 2014 14:48:59 +0200 [thread overview] Message-ID: <CANq1E4S6rzDSXXTQws1nPiAXkRgLMbADJJTCoLjONLFiR6wP4g@mail.gmail.com> (raw) In-Reply-To: <1410381657.4117.3.camel@nebula.com> Hi On Wed, Sep 10, 2014 at 10:40 PM, Matthew Garrett <matthew.garrett@nebula.com> 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
next prev parent reply other threads:[~2014-09-11 12:49 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-10 15:54 [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices David Herrmann 2014-09-10 15:54 ` David Herrmann 2014-09-10 15:54 ` [PATCH RFC 1/4] backlight: use static initializers David Herrmann 2014-09-10 15:54 ` David Herrmann 2014-09-11 8:59 ` Jani Nikula 2014-09-11 8:59 ` Jani Nikula 2014-09-10 15:54 ` [PATCH RFC 2/4] backlight: use spin-lock to protect device list David Herrmann 2014-09-10 15:54 ` David Herrmann 2014-09-11 9:00 ` Jani Nikula 2014-09-11 9:00 ` Jani Nikula 2014-09-10 15:54 ` [PATCH RFC 3/4] backlight: add kernel-internal backlight API David Herrmann 2014-09-11 11:10 ` Thierry Reding 2014-09-11 11:10 ` Thierry Reding 2014-09-11 11:14 ` David Herrmann 2014-09-11 11:14 ` David Herrmann 2014-09-11 11:21 ` Thierry Reding 2014-09-11 11:21 ` Thierry Reding 2014-09-10 15:54 ` [PATCH RFC 4/4] drm: link connectors to backlight devices David Herrmann 2014-09-10 15:54 ` David Herrmann 2014-09-11 6:48 ` Daniel Vetter 2014-09-11 6:48 ` Daniel Vetter 2014-09-11 12:22 ` David Herrmann 2014-09-11 13:06 ` Daniel Vetter 2014-09-11 13:06 ` Daniel Vetter 2014-09-11 16:07 ` David Herrmann 2014-09-11 12:46 ` Jani Nikula 2014-09-10 20:40 ` [PATCH RFC 0/4] Linking DRM Connectors to Backlight Devices Matthew Garrett 2014-09-10 20:40 ` Matthew Garrett 2014-09-11 12:48 ` David Herrmann [this message] 2014-09-11 12:48 ` David Herrmann 2016-10-24 13:08 ` [PATCH 0/6] Rebase of David Herrmann drm connector link to backlight device Marta Lofstedt 2016-10-24 13:08 ` [PATCH 1/6] backlight: use static initializers Marta Lofstedt 2016-10-24 13:08 ` [PATCH 2/6] backlight: use spin-lock to protect device list Marta Lofstedt 2016-10-24 13:08 ` [PATCH 3/6] backlight: add kernel-internal backlight API Marta Lofstedt 2016-10-24 13:08 ` [PATCH 4/6] drm: link connectors to backlight devices Marta Lofstedt 2016-10-24 13:08 ` [PATCH 5/6] i915: Use drm backlight Marta Lofstedt 2016-10-24 13:08 ` [PATCH 6/6] drm: drm_backlight use the connect value to set brightness property Marta Lofstedt 2016-10-24 14:33 ` [PATCH 0/6] Rebase of David Herrmann drm connector link to backlight device Daniel Vetter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CANq1E4S6rzDSXXTQws1nPiAXkRgLMbADJJTCoLjONLFiR6wP4g@mail.gmail.com \ --to=dh.herrmann@gmail.com \ --cc=airlied@gmail.com \ --cc=ajax@redhat.com \ --cc=cooloney@gmail.com \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=jg1.han@samsung.com \ --cc=lee.jones@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=matthew.garrett@nebula.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.