linux-kernel - Re: Backlight device class redesign

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091128122229.GB17894@khazad-dum.debian.net>
Date:	Sat, 28 Nov 2009 10:22:29 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Rafa?? Mi??ecki <zajec5@...il.com>
Cc:	Linux ACPI <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Richard Purdie <rpurdie@...ys.net>
Subject: Re: Backlight device class redesign

Backlight maintainer added to CC.

On Sat, 28 Nov 2009, Rafa?? Mi??ecki wrote:
> W dniu 28 listopada 2009 01:30 u??ytkownik Rafa?? Mi??ecki
> <zajec5@...il.com> napisa??:
> > 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.
> 
> Just in case I was not clear enough. We should make ACPI, platform and
> GPU drivers register same panel backlight control under same name like
> "panel-0". Backlight class device would create
> /sys/class/backlight/panel-0 only. When touching files in this
> backlight/panel-0/, blacklight class would call functions from the
> most proper (ACPI > platform > GPU) driver.
> 

I once suggested some sort of multiplexer backlight device that would do
exactly that.  Various drivers (platform, ACPI, display) would register
backends and specify some sort of dynamic preference so that the kernel
would have a good bet on the default one, and userspace could switch the
active backend later if it wanted.

In this case, we'd have to specify properties or some other way to group the
backends properly and to easily let userspace find the backlight device it
needs to drive a specific device.

> I thought if we could use card number for anything. I recalled that
> notebooks with hybrid gpu, where system should switch between weaker
> and more powerful GPU watching load. In case of that notebooks PANEL
> can be controlled by both: card0 and card1.

That would require backends to be able to runtime register and unregister
themselves with the main backlight device, and that they hook somehow on the
hotplug stuff, to know when to bind/unbind along with the GPU.

> So finally I think we should just register panel0 by default
> everywhere. And in future we could add some quirks in drivers (ACPI,
> platform, GPU) that would register panel1, panel2... for such devices.

If you're going to design something, do it properly from day one.  Address
all the main issues: multiple backends for each device, auto-selection of
the default backend based on data reported by the backend drivers (e.g. a
platform driver usually knows very well if it should be preferred over ACPI
and GPU or not...), *and* multiple devices with hotplug.

These are not, after all, overengineering for the future.  It is a problem
we have _now_ with real world devices that are shipping.

There are other ways to solve this issue, of course, and they're easier:
publish MORE information on sysfs to properly bind backlight devices to the
real device they control, as well as more data to help userspace decide
which one it should use.   It is a cop-out, as we are only solving half the
problem space in-kernel.  But it works, and it is not a hack, so it is also
a viable solution.

I prefer the full kernel solution where we export just one backlight
interface, but when I propesed it, the others made it clear they'd prefer
the less complex "userspace chooses which backlight backend to drive"
currently employed.

Meanwhile, I'd like a LOT to know how I could parent the backlight device I
export in a platform driver to the correct PCI or ACPI device for the main
GPU...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/