From: "Rafał Miłecki" <zajec5@gmail.com>
To: Linux ACPI <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Backlight device class redesign
Date: Sat, 28 Nov 2009 01:30:08 +0100 [thread overview]
Message-ID: <b170af450911271630k63fb857auf8314cecd6219eba@mail.gmail.com> (raw)
As discussed in http://marc.info/?t=124947671300008&r=1&w=2 we need to
redesign our backlight device class. If you wish you can read whole
thread and even http://bugs.freedesktop.org/show_bug.cgi?id=20963 but
I'll try to summarize everything anyway.
1) One display can be controlled (I mean backlight) in more than one
way. For example: ACPI, something platform-specific and GPU encoder.
2) Exporting many ways of controlling one display at the same time
drives us to inconsistencies.
3) We have to decide some priority like: ACPI > platform > GPU
4) We have to keep list of all registered controllers for one display.
We can not just unregister lower prioritised as we will hit problem
after (for example) unloading acpi module.
5) We should not export more than one way and let userspace decide.
Currently we keep all registered controllers in /sys/class/backlgiht/
without any grouping per display or per anything. We can not use
grouping per GPU (as somewhere proposed) because one GPU can control
(for example) two PANELS and TV - 3 displays needing backlight
management. The most obvious and stable solution seems to be grouping
per display.
So staying with idea of grouping per display I tried to imagine the
most crazy notebook with external displays configuration we should
handle. Let's consider following displays in notebook (yes, two
panel-notebook!):
1) PANEL#A controlled by ACPI + platform-specific + GPU
2) PANEL#B controlled by ACPI + platform-specific
3) TV connected by S-VIDEO controlled by GPU
4) LCD#A connected by USB controlled by LCD-specific driver
5) LCD#B connected by USB controlled by LCD-specific driver (same
model as LCD#A, driven by the same driver)
Let's do reverse order:
a) For two USB-LCDs driver should generate two other names. Depends on
properties received from LCD that could be serial number or usb port
number. So we would get /sys/class/lcd-vendor-0000:00:1d.2 and
/sys/class/lcd-vendor-0000:00:a3.5
b) For TV gpu kernel module would use name with GPU card number and
output name. Let's say /sys/class/card0-svideo
c) The most complicated case is for PANELs. We have to pick up same
names in: ACPI, platform-specific and GPU driver. For most cases,
which means notebooks with one panel, we could just use "panel".
However I do not want to redesign this after year when we get more
notebooks with two PANELs. So do you have any idea about this? How we
could generate correct names in 3 almost unrelated modules (ACPI,
platform, GPU driver)? We should end with something like
/sys/class/internal-panel-1 and /sys/class/internal-panel-2 but that
won't be so easy. Any ideas?
Please use "Reply to all", as I do cross-ML-post and I am not
subscribed to LKML.
--
Rafał
next reply other threads:[~2009-11-28 0:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-28 0:30 Rafał Miłecki [this message]
2009-11-28 10:30 ` Rafał Miłecki
2009-11-28 12:22 ` Henrique de Moraes Holschuh
2009-11-28 12:58 ` Rafał Miłecki
2009-11-28 17:21 ` Henrique de Moraes Holschuh
2009-11-29 20:09 ` Rafał Miłecki
2009-11-29 21:51 ` Rafał Miłecki
2009-11-29 21:51 ` Rafał Miłecki
2009-11-30 0:04 ` Henrique de Moraes Holschuh
2009-12-03 8:01 ` Zhang Rui
2009-12-03 10:52 ` Henrique de Moraes Holschuh
2009-12-04 1:50 ` Zhang Rui
2009-12-03 14:55 ` Matthew Garrett
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=b170af450911271630k63fb857auf8314cecd6219eba@mail.gmail.com \
--to=zajec5@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®