https://bugzilla.kernel.org/show_bug.cgi?id=47841


Aaron Lu <aaron...@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aaron...@intel.com
         AssignedTo|acpi_acpica-core@kernel-bug |aaron...@intel.com
                   |s.osdl.org                  |




--- Comment #25 from Aaron Lu <aaron...@intel.com>  2013-04-10 01:57:46 ---
(In reply to comment #24)
> ~~~~~~~~~~~
> Conclusions
> ~~~~~~~~~~~
> On this machine I think one should go with acpi_backlight=vendor and wait for 
> a
> correct backlight uevent support by desktop environments.

Right.

> 
> Still it is unclear to me which is the interaction path between desktop power
> management and the files under /sys/class/backlight (i.e. see points A5 and
> B5). I would be glad if anyone can explain that.

Documentation/ABI/stable/sysfs-class-backlight has some info on these files.

Usually, when hotkey is pressed to adjust backlight, there are three cases:
1 A keycode is generate to user space. In this case, we need to remap the
keycode to standard backlight brightness up/down code, so that user space can
react accordingly(the remap can either be done by driver or by udev);
2 Firmware sends driver a notification, and driver will send a key event(e.g.
standard brightness up/down key code) corresponding to this notification to
user space, so user space can again react accordingly;
3 Firmware directly manipulates the backlight and then sends driver a
notification and driver will send user space an uevent to let them know
something has already happened.

For the first 2 cases, user space will adjust the backlight level through one
of the available backlight interfaces in /sys/class/backlight.

And after any of the operations of the above 3 cases, the file's content may
have changed.

> 
> And still I could not understand why the generic ACPI drivers are preferred by
> default over the specific ones, which are supposed to better handle the
> devices. Could anyone explain that too?

GNOME did this, I don't know why.
The gnome-settings-daemon code showed that, g-s-d will prefer backlight
interface of the following order: firmware(acpi_video) >
platform(asus/acer/etc._wmi) > raw (intel/radeon/etc._backlight)

> 
> Sorry for the lenghty post, but I tried to be exhaustive. Thanks!

It's very clear, thanks.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to