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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b170af450911280230g4a2f7f8ao64b46ce7e88ec929@mail.gmail.com>
Date:	Sat, 28 Nov 2009 11:30:51 +0100
From:	Rafał Miłecki <zajec5@...il.com>
To:	Linux ACPI <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Backlight device class redesign

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

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.

Any comments? Should I work on something like specified above?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ