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

[David Herrmann]

Hi

This series introduces a link between DRM connectors and backlight-class
devices. It tries to solve some long standing issues:

 * 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.
   If multiple backlights are available, the easiest solution is to simply write
   to all of them and hope at least one of them works. This obviously fails if
   the devices interact badly, so it's not really a solution.

 * User-space needs root privileges to write to sysfs. There are no char-devs
   that can be used to control access-management to the backlight API, so /sys
   is the only interface available. So far, udev policy has been "/sys is
   read-only for non-root" and it's not going to change. char-devs are *THE*
   standard way to provide non-root user-space APIs, so use them!

Several solutions have been discussed so far, but we never agreed on one. I'm
aware of at least the following solutions:

 * Provide char-devs for backlight devices and a sysfs link from connectors to
   backlight devices. This way, user-space can managed access to char-devs *and*
   get proper topology information.
   However, this might be an n:m relationship (n:1 for displays exposed as
   multiple connectors, 1:m for boards with multiple backlights? whatever..) and
   it sounds like a waste of resources to add char-devs just to write brightness
   values.

 * Do everything in privileged user-space. One daemon that provides an
   unprivileged-API and forwards writes to /sys. It reads topology information
   from udev hwdb.
   This circumvents the ugly sysfs API and not really solves the problem. It
   should work, though ugly.

 * Add a DRM connector property that takes brightness values.
   This is the nicest solution for user-space, but introduces a whole lot of
   issues on the kernel side. There already is a backlight-class and we had a
   hard-time trying to move it into DRM drivers, so no-one ever did the work.

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.

Patch #1 and #2 are cleanups and can be applied right away. #3 adds in-kernel
backlight APIs and #4 implements the connector-backlight link.

Comments welcome!
David

David Herrmann (4):
  backlight: use static initializers
  backlight: use spin-lock to protect device list
  backlight: add kernel-internal backlight API
  drm: link connectors to backlight devices

 drivers/gpu/drm/Kconfig             |   1 +
 drivers/gpu/drm/Makefile            |   2 +-
 drivers/gpu/drm/drm_backlight.c     | 387 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_crtc.c          |  45 +++--
 drivers/gpu/drm/drm_drv.c           |  11 +
 drivers/gpu/drm/drm_sysfs.c         |  53 +++++
 drivers/video/backlight/backlight.c |  91 +++++++--
 include/drm/drm_backlight.h         |  44 ++++
 include/drm/drm_crtc.h              |   3 +
 include/linux/backlight.h           |  17 ++
 10 files changed, 622 insertions(+), 32 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_backlight.c
 create mode 100644 include/drm/drm_backlight.h

-- 
2.1.0

--
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/