On Thursday 09 April 2009 03:12:19 am yakui_zhao wrote:
On Wed, 2009-04-08 at 18:17 +0800, Thomas Renninger wrote:
Hi,
We have these interfaces:
- vendor specific implementation
(mostly in drivers/platform/x86/vendor-laptop.c)
- ACPI generic backlight only
- Opregion (this
On Tue, 2009-04-07 at 16:48 +0800, Zhang, Rui wrote:
CC Thomas, Len and linux-acpi mail list.
On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
All subsystems can register a set of callbacks for backlight control in
On Tue, 2009-04-07 at 15:38 +0800, Matthew Garrett wrote:
On Tue, Apr 07, 2009 at 03:25:23PM +0800, yakui_zhao wrote:
On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote:
No, since in UMS mode the X server handles the backlight registers.
If so, there is no change about the backlight
On Tuesday 07 April 2009 10:48:22 Zhang Rui wrote:
CC Thomas, Len and linux-acpi mail list.
On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
All subsystems can register a set of callbacks for backlight control in
Hi,
We have these interfaces:
- vendor specific implementation
(mostly in drivers/platform/x86/vendor-laptop.c)
- ACPI generic backlight only
- Opregion (this is the KMS/i915 interface you are talking about
or is there another abstraction?)
- Possibly other graphics card specific
On Wed, 2009-04-08 at 12:17 +0200, Thomas Renninger wrote:
Matthew and Jesse are looking for following approach:
Let all drivers try to register for the generic backlight interface.
As we do not know which driver will get loaded first, you want to
detect whether another driver already
On Wed, 2009-04-08 at 18:17 +0800, Thomas Renninger wrote:
Hi,
We have these interfaces:
- vendor specific implementation
(mostly in drivers/platform/x86/vendor-laptop.c)
- ACPI generic backlight only
- Opregion (this is the KMS/i915 interface you are talking about
or is
On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote:
On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote:
I'd rather not have a native kernel backlight property (i.e. a property
on the LVDS output) exposed at all. I chatted with Matthew about this
a little, and I think the
On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote:
On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote:
Right. I'd imagine it as i915 loading and calling is_acpi_backlight().
If that returns false, it should register a backlight device and also a
notifier. If a
On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote:
On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote:
On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote:
Right. I'd imagine it as i915 loading and calling is_acpi_backlight().
If that returns false, it should register
On Tue, Apr 07, 2009 at 03:25:23PM +0800, yakui_zhao wrote:
On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote:
No, since in UMS mode the X server handles the backlight registers.
If so, there is no change about the backlight flowchart in UMS mode.
And only when the KMS mode is used,
On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
All subsystems can register a set of callbacks for backlight control in
its own way, e.g. ACPI, platform driver, i915.
And the backlight manager only exports one single I/F to users, like:
|
|brightness
On Tue, 2009-04-07 at 15:25 +0800, Zhao, Yakui wrote:
But if we do so, it seems that we have to solve the dependency issue
among acpi_video, i915 and platform driver.
For example: I915 driver is loaded firstly and the interface will be
registered. But after the acpi video
CC Thomas, Len and linux-acpi mail list.
On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
All subsystems can register a set of callbacks for backlight control in
its own way, e.g. ACPI, platform driver, i915.
And the
On Tue, 07 Apr 2009 16:48:22 +0800
Zhang Rui rui.zh...@intel.com wrote:
CC Thomas, Len and linux-acpi mail list.
On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
All subsystems can register a set of callbacks for
Hi, All
When the kernel is booted with KMS enabled, the backlight brightness
can't be changed by xrandr tool. This issue is caused by that the native
kernel backlight I/F is not exposed to userland. In such case there is
no backlight property in xrandr tool. Of course the brightness can't be
On Fri, 3 Apr 2009 17:29:06 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote:
I'd rather not have a native kernel backlight property (i.e. a
property on the LVDS output) exposed at all. I chatted with
Matthew about this a
On Fri, 03 Apr 2009 13:49:38 +0800
yakui_zhao yakui.z...@intel.com wrote:
How about following what we have done in UMS mode ?
a. When there exists the ACPI backlight I/F, the ACPI I/F will be
hook up in drmmode_display.c and exposed to xrandr tool. Then the
backlight can be changed by
On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote:
I'd rather not have a native kernel backlight property (i.e. a property
on the LVDS output) exposed at all. I chatted with Matthew about this
a little, and I think the best thing to do would be to have the i915
driver register a
19 matches
Mail list logo
