[PATCH 1/5] Backlight: Add backlight type
[...] +What: /sys/class/backlight//type +Date: September 2010 +KernelVersion: 2.6.37 [...] 2.6.37? Will this go into 2.6.38? 2.6.39? Through which subsystem will these patches walk through? drm-2.6? platform-drivers-x86? Are you planning a GIT tree/branch for this patch-set? The patch-set from 14-Jan-2011 applies against linux-next (next-20110115). I will compile, test and report. - Sedat -
Re: [PATCH 1/5] Backlight: Add backlight type
[...] +What: /sys/class/backlight//type +Date: September 2010 +KernelVersion: 2.6.37 [...] 2.6.37? Will this go into 2.6.38? 2.6.39? Through which subsystem will these patches walk through? drm-2.6? platform-drivers-x86? Are you planning a GIT tree/branch for this patch-set? The patch-set from 14-Jan-2011 applies against linux-next (next-20110115). I will compile, test and report. - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] Backlight: Add backlight type
There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by: Matthew Garrett Cc: Richard Purdie Cc: intel-gfx at lists.freedesktop.org Cc: dri-devel at lists.freedesktop.org --- Documentation/ABI/stable/sysfs-class-backlight | 20 drivers/acpi/video.c |1 + drivers/gpu/drm/nouveau/nouveau_backlight.c|2 + drivers/hid/hid-picolcd.c |1 + drivers/macintosh/via-pmu-backlight.c |1 + drivers/platform/x86/acer-wmi.c|1 + drivers/platform/x86/asus-laptop.c |1 + drivers/platform/x86/asus_acpi.c |1 + drivers/platform/x86/classmate-laptop.c|1 + drivers/platform/x86/compal-laptop.c |1 + drivers/platform/x86/dell-laptop.c |1 + drivers/platform/x86/eeepc-laptop.c|1 + drivers/platform/x86/eeepc-wmi.c |1 + drivers/platform/x86/fujitsu-laptop.c |1 + drivers/platform/x86/msi-laptop.c |1 + drivers/platform/x86/msi-wmi.c |1 + drivers/platform/x86/panasonic-laptop.c|1 + drivers/platform/x86/sony-laptop.c |1 + drivers/platform/x86/thinkpad_acpi.c |1 + drivers/platform/x86/toshiba_acpi.c|1 + drivers/staging/olpc_dcon/olpc_dcon.c |1 + drivers/staging/samsung-laptop/samsung-laptop.c|1 + drivers/usb/misc/appledisplay.c|1 + drivers/video/atmel_lcdfb.c|1 + drivers/video/aty/aty128fb.c |1 + drivers/video/aty/atyfb_base.c |1 + drivers/video/aty/radeon_backlight.c |1 + drivers/video/backlight/88pm860x_bl.c |1 + drivers/video/backlight/adp5520_bl.c |1 + drivers/video/backlight/adp8860_bl.c |1 + drivers/video/backlight/adx_bl.c |1 + drivers/video/backlight/atmel-pwm-bl.c |1 + drivers/video/backlight/backlight.c| 24 +++- drivers/video/backlight/corgi_lcd.c|1 + drivers/video/backlight/cr_bllcd.c |1 + drivers/video/backlight/da903x_bl.c|1 + drivers/video/backlight/ep93xx_bl.c|1 + drivers/video/backlight/generic_bl.c |1 + drivers/video/backlight/hp680_bl.c |1 + drivers/video/backlight/jornada720_bl.c|1 + drivers/video/backlight/kb3886_bl.c|1 + drivers/video/backlight/locomolcd.c|1 + drivers/video/backlight/max8925_bl.c |1 + drivers/video/backlight/mbp_nvidia_bl.c|1 + drivers/video/backlight/omap1_bl.c |1 + drivers/video/backlight/pcf50633-backlight.c |1 + drivers/video/backlight/progear_bl.c |1 + drivers/video/backlight/pwm_bl.c |1 + drivers/video/backlight/s6e63m0.c |1 + drivers/video/backlight/tosa_bl.c |1 + drivers/video/backlight/wm831x_bl.c|1 + drivers/video/bf54x-lq043fb.c |1 + drivers/video/bfin-t350mcqb-fb.c |1 + drivers/video/imxfb.c |1 + drivers/video/nvidia/nv_backlight.c|1 + drivers/video/omap2/displays/panel-acx565akm.c |1 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |1 + drivers/video/omap2/displays/panel-taal.c |2 + drivers/video/riva/fbdev.c |1 + include/linux/backlight.h |9 +++ 60 files changed, 111 insertions(+), 1 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight index 4d637e1..70302f3 100644 --- a/Documentation/ABI/stable/sysfs-class-backlight +++ b/Documentation/ABI/stable/sysfs-class-backlight @@ -34,3 +34,23 @@ Contact: Richard Purdie Description: Maximum brightness for . Users: HAL + +What: /sys/class/backlight//type +Date: September 2010 +KernelVersion: 2.6.37 +Contact: Matthew Garrett +Description: + The type of interface controlled by . + "firmware": The driver uses a standard firmware interface + "platform": The driver uses a platform-specific interface + "raw": The driver controls hardware registers directly + + In the general case, when multiple backlight + interfaces are available for a
[PATCH 1/5] Backlight: Add backlight type
There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by: Matthew Garrett Cc: Richard Purdie Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org --- Documentation/ABI/stable/sysfs-class-backlight | 20 drivers/acpi/video.c |1 + drivers/gpu/drm/nouveau/nouveau_backlight.c|2 + drivers/hid/hid-picolcd.c |1 + drivers/macintosh/via-pmu-backlight.c |1 + drivers/platform/x86/acer-wmi.c|1 + drivers/platform/x86/asus-laptop.c |1 + drivers/platform/x86/asus_acpi.c |1 + drivers/platform/x86/classmate-laptop.c|1 + drivers/platform/x86/compal-laptop.c |1 + drivers/platform/x86/dell-laptop.c |1 + drivers/platform/x86/eeepc-laptop.c|1 + drivers/platform/x86/eeepc-wmi.c |1 + drivers/platform/x86/fujitsu-laptop.c |1 + drivers/platform/x86/msi-laptop.c |1 + drivers/platform/x86/msi-wmi.c |1 + drivers/platform/x86/panasonic-laptop.c|1 + drivers/platform/x86/sony-laptop.c |1 + drivers/platform/x86/thinkpad_acpi.c |1 + drivers/platform/x86/toshiba_acpi.c|1 + drivers/staging/olpc_dcon/olpc_dcon.c |1 + drivers/staging/samsung-laptop/samsung-laptop.c|1 + drivers/usb/misc/appledisplay.c|1 + drivers/video/atmel_lcdfb.c|1 + drivers/video/aty/aty128fb.c |1 + drivers/video/aty/atyfb_base.c |1 + drivers/video/aty/radeon_backlight.c |1 + drivers/video/backlight/88pm860x_bl.c |1 + drivers/video/backlight/adp5520_bl.c |1 + drivers/video/backlight/adp8860_bl.c |1 + drivers/video/backlight/adx_bl.c |1 + drivers/video/backlight/atmel-pwm-bl.c |1 + drivers/video/backlight/backlight.c| 24 +++- drivers/video/backlight/corgi_lcd.c|1 + drivers/video/backlight/cr_bllcd.c |1 + drivers/video/backlight/da903x_bl.c|1 + drivers/video/backlight/ep93xx_bl.c|1 + drivers/video/backlight/generic_bl.c |1 + drivers/video/backlight/hp680_bl.c |1 + drivers/video/backlight/jornada720_bl.c|1 + drivers/video/backlight/kb3886_bl.c|1 + drivers/video/backlight/locomolcd.c|1 + drivers/video/backlight/max8925_bl.c |1 + drivers/video/backlight/mbp_nvidia_bl.c|1 + drivers/video/backlight/omap1_bl.c |1 + drivers/video/backlight/pcf50633-backlight.c |1 + drivers/video/backlight/progear_bl.c |1 + drivers/video/backlight/pwm_bl.c |1 + drivers/video/backlight/s6e63m0.c |1 + drivers/video/backlight/tosa_bl.c |1 + drivers/video/backlight/wm831x_bl.c|1 + drivers/video/bf54x-lq043fb.c |1 + drivers/video/bfin-t350mcqb-fb.c |1 + drivers/video/imxfb.c |1 + drivers/video/nvidia/nv_backlight.c|1 + drivers/video/omap2/displays/panel-acx565akm.c |1 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |1 + drivers/video/omap2/displays/panel-taal.c |2 + drivers/video/riva/fbdev.c |1 + include/linux/backlight.h |9 +++ 60 files changed, 111 insertions(+), 1 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight index 4d637e1..70302f3 100644 --- a/Documentation/ABI/stable/sysfs-class-backlight +++ b/Documentation/ABI/stable/sysfs-class-backlight @@ -34,3 +34,23 @@ Contact: Richard Purdie Description: Maximum brightness for . Users: HAL + +What: /sys/class/backlight//type +Date: September 2010 +KernelVersion: 2.6.37 +Contact: Matthew Garrett +Description: + The type of interface controlled by . + "firmware": The driver uses a standard firmware interface + "platform": The driver uses a platform-specific interface + "raw": The driver controls hardware registers directly + + In the general case, when multiple backlight + interfaces are available for a singl
[PATCH 1/5] Backlight: Add backlight type
On Mon, Nov 22, 2010 at 01:35:48PM +, Richard Purdie wrote: > Its the reverse situation I worry about. Are there situations where > there are multiple connectors on the PCI device and the ACPI interface > just controls one of them but controls for the other connectors may > exist? Yes, that's certainly possible and it'd be desirable to fix this up, but the same problem also applies to platform interfaces and it's typically unfixable there. My userspace implementation looks at the connector type to determine the best approach - if it's not LVDS or eDP it ignores the firmware and platform interfaces, so you'll fall back to the raw interface if it can provide support for your connector (presumably via ddcci, although we don't have this implemented yet) -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 1/5] Backlight: Add backlight type
On Mon, 2010-11-22 at 12:30 +, Matthew Garrett wrote: > On Mon, Nov 22, 2010 at 10:17:00AM +, Richard Purdie wrote: > > > I also want to make sure you think this patch is going to scale with > > multiple GPU output machines? Thats the main reason I've held off any > > patch like this as it doesn't help solve that problem as far as I can > > tell. Yes, we have the device parent information and I see later in the > > patch series you ensure the backlight is registered against the > > connector which is good. If you have an ACPI "firmware" control that you > > say should always be preferred, how do we know which connector device > > that corresponds to in the multiple output case? From that point of view > > this model falls apart? > > The ACPI device will point at the correct PCI device. Associating it > with the appropriate connector is theoretically possible in the case of > open drivers, but I hadn't seen it as a high priority since (in > practice) there's no situations where an ACPI interface will be able to > control more than one backlight. Its the reverse situation I worry about. Are there situations where there are multiple connectors on the PCI device and the ACPI interface just controls one of them but controls for the other connectors may exist? I'm typing this with an external monitor plugged into my laptop with i915 graphics... Cheers, Richard
[PATCH 1/5] Backlight: Add backlight type
On Mon, Nov 22, 2010 at 10:17:00AM +, Richard Purdie wrote: > I also want to make sure you think this patch is going to scale with > multiple GPU output machines? Thats the main reason I've held off any > patch like this as it doesn't help solve that problem as far as I can > tell. Yes, we have the device parent information and I see later in the > patch series you ensure the backlight is registered against the > connector which is good. If you have an ACPI "firmware" control that you > say should always be preferred, how do we know which connector device > that corresponds to in the multiple output case? From that point of view > this model falls apart? The ACPI device will point at the correct PCI device. Associating it with the appropriate connector is theoretically possible in the case of open drivers, but I hadn't seen it as a high priority since (in practice) there's no situations where an ACPI interface will be able to control more than one backlight. -- Matthew Garrett | mjg59 at srcf.ucam.org
[PATCH 1/5] Backlight: Add backlight type
On Fri, 2010-11-19 at 20:25 +, Matthew Garrett wrote:
> On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> > On Fri, 19 Nov 2010 10:53:52 -0500
> > Matthew Garrett wrote:
> >
> > > There may be multiple ways of controlling the backlight on a given
> > > machine.
> > > Allow drivers to expose the type of interface they are providing, making
> > > it possible for userspace to make appropriate policy decisions.
> > >
> > > ...
> > >
> > > 60 files changed, 102 insertions(+), 0 deletions(-)
> >
> > This patch has a pretty short half-life.
>
> Well, ideally it would have landed in the backlight tree when I sent it
> months ago. Then we'd have the opportunity to ensure that everything was
> fixed up before it went in in the merge window.
>
> > > @@ -62,6 +68,8 @@ struct backlight_properties {
> > > /* FB Blanking active? (values as for power) */
> > > /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> > > int fb_blank;
> > > + /* Backlight type */
> > > + enum backlight_type type;
> > > /* Flags used to signal drivers of state changes */
> > > /* Upper 4 bits are reserved for driver internal use */
> > > unsigned int state;
> >
> > And if/when the half-life expires, we'll have drivers in-tree which
> > forget to set backlight_properties.type. I haven't checked, but if
> > we're lucky they will default to "0".
>
> Depends entirely on whether they kzalloc the structure or not before
> calling backlight_device_register().
>
> > What will be the runtime effects upon such unconverted drivers?
> > Ideally we'd like them to continue to work OK, and to emit a runtime
> > warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
> > driver can be detected, warned about and fixed up by the core code.
>
> The worst case I can think of is that we walk off the array - I guess
> there's an argument for sanity checking that in backlight_show_type().
I think adding a BACKLIGHT_TYPEUNKNOWN as the first item in the enum,
sanity checking the array bounds and printing a warning if type is not
one of the defined values would be good.
I also want to make sure you think this patch is going to scale with
multiple GPU output machines? Thats the main reason I've held off any
patch like this as it doesn't help solve that problem as far as I can
tell. Yes, we have the device parent information and I see later in the
patch series you ensure the backlight is registered against the
connector which is good. If you have an ACPI "firmware" control that you
say should always be preferred, how do we know which connector device
that corresponds to in the multiple output case? From that point of view
this model falls apart?
What I really want to avoid is a new interface which just papers over
cracks, only to have everything crumble anyway.
Cheers,
Richard
Re: [PATCH 1/5] Backlight: Add backlight type
On Mon, 2010-11-22 at 12:30 +, Matthew Garrett wrote: > On Mon, Nov 22, 2010 at 10:17:00AM +, Richard Purdie wrote: > > > I also want to make sure you think this patch is going to scale with > > multiple GPU output machines? Thats the main reason I've held off any > > patch like this as it doesn't help solve that problem as far as I can > > tell. Yes, we have the device parent information and I see later in the > > patch series you ensure the backlight is registered against the > > connector which is good. If you have an ACPI "firmware" control that you > > say should always be preferred, how do we know which connector device > > that corresponds to in the multiple output case? From that point of view > > this model falls apart? > > The ACPI device will point at the correct PCI device. Associating it > with the appropriate connector is theoretically possible in the case of > open drivers, but I hadn't seen it as a high priority since (in > practice) there's no situations where an ACPI interface will be able to > control more than one backlight. Its the reverse situation I worry about. Are there situations where there are multiple connectors on the PCI device and the ACPI interface just controls one of them but controls for the other connectors may exist? I'm typing this with an external monitor plugged into my laptop with i915 graphics... Cheers, Richard ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] Backlight: Add backlight type
On Fri, 2010-11-19 at 20:25 +, Matthew Garrett wrote:
> On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> > On Fri, 19 Nov 2010 10:53:52 -0500
> > Matthew Garrett wrote:
> >
> > > There may be multiple ways of controlling the backlight on a given
> > > machine.
> > > Allow drivers to expose the type of interface they are providing, making
> > > it possible for userspace to make appropriate policy decisions.
> > >
> > > ...
> > >
> > > 60 files changed, 102 insertions(+), 0 deletions(-)
> >
> > This patch has a pretty short half-life.
>
> Well, ideally it would have landed in the backlight tree when I sent it
> months ago. Then we'd have the opportunity to ensure that everything was
> fixed up before it went in in the merge window.
>
> > > @@ -62,6 +68,8 @@ struct backlight_properties {
> > > /* FB Blanking active? (values as for power) */
> > > /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> > > int fb_blank;
> > > + /* Backlight type */
> > > + enum backlight_type type;
> > > /* Flags used to signal drivers of state changes */
> > > /* Upper 4 bits are reserved for driver internal use */
> > > unsigned int state;
> >
> > And if/when the half-life expires, we'll have drivers in-tree which
> > forget to set backlight_properties.type. I haven't checked, but if
> > we're lucky they will default to "0".
>
> Depends entirely on whether they kzalloc the structure or not before
> calling backlight_device_register().
>
> > What will be the runtime effects upon such unconverted drivers?
> > Ideally we'd like them to continue to work OK, and to emit a runtime
> > warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
> > driver can be detected, warned about and fixed up by the core code.
>
> The worst case I can think of is that we walk off the array - I guess
> there's an argument for sanity checking that in backlight_show_type().
I think adding a BACKLIGHT_TYPEUNKNOWN as the first item in the enum,
sanity checking the array bounds and printing a warning if type is not
one of the defined values would be good.
I also want to make sure you think this patch is going to scale with
multiple GPU output machines? Thats the main reason I've held off any
patch like this as it doesn't help solve that problem as far as I can
tell. Yes, we have the device parent information and I see later in the
patch series you ensure the backlight is registered against the
connector which is good. If you have an ACPI "firmware" control that you
say should always be preferred, how do we know which connector device
that corresponds to in the multiple output case? From that point of view
this model falls apart?
What I really want to avoid is a new interface which just papers over
cracks, only to have everything crumble anyway.
Cheers,
Richard
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] Backlight: Add backlight type
On Mon, Nov 22, 2010 at 01:35:48PM +, Richard Purdie wrote: > Its the reverse situation I worry about. Are there situations where > there are multiple connectors on the PCI device and the ACPI interface > just controls one of them but controls for the other connectors may > exist? Yes, that's certainly possible and it'd be desirable to fix this up, but the same problem also applies to platform interfaces and it's typically unfixable there. My userspace implementation looks at the connector type to determine the best approach - if it's not LVDS or eDP it ignores the firmware and platform interfaces, so you'll fall back to the raw interface if it can provide support for your connector (presumably via ddcci, although we don't have this implemented yet) -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] Backlight: Add backlight type
On Mon, Nov 22, 2010 at 10:17:00AM +, Richard Purdie wrote: > I also want to make sure you think this patch is going to scale with > multiple GPU output machines? Thats the main reason I've held off any > patch like this as it doesn't help solve that problem as far as I can > tell. Yes, we have the device parent information and I see later in the > patch series you ensure the backlight is registered against the > connector which is good. If you have an ACPI "firmware" control that you > say should always be preferred, how do we know which connector device > that corresponds to in the multiple output case? From that point of view > this model falls apart? The ACPI device will point at the correct PCI device. Associating it with the appropriate connector is theoretically possible in the case of open drivers, but I hadn't seen it as a high priority since (in practice) there's no situations where an ACPI interface will be able to control more than one backlight. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] Backlight: Add backlight type
On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> On Fri, 19 Nov 2010 10:53:52 -0500
> Matthew Garrett wrote:
>
> > There may be multiple ways of controlling the backlight on a given machine.
> > Allow drivers to expose the type of interface they are providing, making
> > it possible for userspace to make appropriate policy decisions.
> >
> > ...
> >
> > 60 files changed, 102 insertions(+), 0 deletions(-)
>
> This patch has a pretty short half-life.
Well, ideally it would have landed in the backlight tree when I sent it
months ago. Then we'd have the opportunity to ensure that everything was
fixed up before it went in in the merge window.
> > @@ -62,6 +68,8 @@ struct backlight_properties {
> > /* FB Blanking active? (values as for power) */
> > /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> > int fb_blank;
> > + /* Backlight type */
> > + enum backlight_type type;
> > /* Flags used to signal drivers of state changes */
> > /* Upper 4 bits are reserved for driver internal use */
> > unsigned int state;
>
> And if/when the half-life expires, we'll have drivers in-tree which
> forget to set backlight_properties.type. I haven't checked, but if
> we're lucky they will default to "0".
Depends entirely on whether they kzalloc the structure or not before
calling backlight_device_register().
> What will be the runtime effects upon such unconverted drivers?
> Ideally we'd like them to continue to work OK, and to emit a runtime
> warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
> driver can be detected, warned about and fixed up by the core code.
The worst case I can think of is that we walk off the array - I guess
there's an argument for sanity checking that in backlight_show_type().
--
Matthew Garrett | mjg59 at srcf.ucam.org
Re: [PATCH 1/5] Backlight: Add backlight type
On Fri, 19 Nov 2010 20:25:59 +
Matthew Garrett wrote:
> On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> > On Fri, 19 Nov 2010 10:53:52 -0500
> > Matthew Garrett wrote:
> >
> > > There may be multiple ways of controlling the backlight on a given
> > > machine.
> > > Allow drivers to expose the type of interface they are providing, making
> > > it possible for userspace to make appropriate policy decisions.
> > >
> > > ...
> > >
> > > 60 files changed, 102 insertions(+), 0 deletions(-)
> >
> > This patch has a pretty short half-life.
>
> Well, ideally it would have landed in the backlight tree when I sent it
> months ago. Then we'd have the opportunity to ensure that everything was
> fixed up before it went in in the merge window.
Richard got distracted. At present I'm grabbing the leds and backlight
patches and Richard is reviewing them as they fly past.
I don't see there's much point in me merging this patch series so if it
survives review, I'd suggest that you put it into an mjg tree and
thence into linux-next and mainline?
> > > @@ -62,6 +68,8 @@ struct backlight_properties {
> > > /* FB Blanking active? (values as for power) */
> > > /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> > > int fb_blank;
> > > + /* Backlight type */
> > > + enum backlight_type type;
> > > /* Flags used to signal drivers of state changes */
> > > /* Upper 4 bits are reserved for driver internal use */
> > > unsigned int state;
> >
> > And if/when the half-life expires, we'll have drivers in-tree which
> > forget to set backlight_properties.type. I haven't checked, but if
> > we're lucky they will default to "0".
>
> Depends entirely on whether they kzalloc the structure or not before
> calling backlight_device_register().
Well. Even if it's uninitialised, the chances of the value being 1, 2
or 3 for all users are pretty small, so we'll still get to hear about
it if the runtime check is appropriately implemented.
> > What will be the runtime effects upon such unconverted drivers?
> > Ideally we'd like them to continue to work OK, and to emit a runtime
> > warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
> > driver can be detected, warned about and fixed up by the core code.
>
> The worst case I can think of is that we walk off the array - I guess
> there's an argument for sanity checking that in backlight_show_type().
OK, well please have a think about it, see what you can do to handle
unconverted (and possibly out-of-tree) drivers in a friendly fashion.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] Backlight: Add backlight type
On Fri, 19 Nov 2010 20:25:59 +
Matthew Garrett wrote:
> On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> > On Fri, 19 Nov 2010 10:53:52 -0500
> > Matthew Garrett wrote:
> >
> > > There may be multiple ways of controlling the backlight on a given
> > > machine.
> > > Allow drivers to expose the type of interface they are providing, making
> > > it possible for userspace to make appropriate policy decisions.
> > >
> > > ...
> > >
> > > 60 files changed, 102 insertions(+), 0 deletions(-)
> >
> > This patch has a pretty short half-life.
>
> Well, ideally it would have landed in the backlight tree when I sent it
> months ago. Then we'd have the opportunity to ensure that everything was
> fixed up before it went in in the merge window.
Richard got distracted. At present I'm grabbing the leds and backlight
patches and Richard is reviewing them as they fly past.
I don't see there's much point in me merging this patch series so if it
survives review, I'd suggest that you put it into an mjg tree and
thence into linux-next and mainline?
> > > @@ -62,6 +68,8 @@ struct backlight_properties {
> > > /* FB Blanking active? (values as for power) */
> > > /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> > > int fb_blank;
> > > + /* Backlight type */
> > > + enum backlight_type type;
> > > /* Flags used to signal drivers of state changes */
> > > /* Upper 4 bits are reserved for driver internal use */
> > > unsigned int state;
> >
> > And if/when the half-life expires, we'll have drivers in-tree which
> > forget to set backlight_properties.type. I haven't checked, but if
> > we're lucky they will default to "0".
>
> Depends entirely on whether they kzalloc the structure or not before
> calling backlight_device_register().
Well. Even if it's uninitialised, the chances of the value being 1, 2
or 3 for all users are pretty small, so we'll still get to hear about
it if the runtime check is appropriately implemented.
> > What will be the runtime effects upon such unconverted drivers?
> > Ideally we'd like them to continue to work OK, and to emit a runtime
> > warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
> > driver can be detected, warned about and fixed up by the core code.
>
> The worst case I can think of is that we walk off the array - I guess
> there's an argument for sanity checking that in backlight_show_type().
OK, well please have a think about it, see what you can do to handle
unconverted (and possibly out-of-tree) drivers in a friendly fashion.
Re: [PATCH 1/5] Backlight: Add backlight type
On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> On Fri, 19 Nov 2010 10:53:52 -0500
> Matthew Garrett wrote:
>
> > There may be multiple ways of controlling the backlight on a given machine.
> > Allow drivers to expose the type of interface they are providing, making
> > it possible for userspace to make appropriate policy decisions.
> >
> > ...
> >
> > 60 files changed, 102 insertions(+), 0 deletions(-)
>
> This patch has a pretty short half-life.
Well, ideally it would have landed in the backlight tree when I sent it
months ago. Then we'd have the opportunity to ensure that everything was
fixed up before it went in in the merge window.
> > @@ -62,6 +68,8 @@ struct backlight_properties {
> > /* FB Blanking active? (values as for power) */
> > /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> > int fb_blank;
> > + /* Backlight type */
> > + enum backlight_type type;
> > /* Flags used to signal drivers of state changes */
> > /* Upper 4 bits are reserved for driver internal use */
> > unsigned int state;
>
> And if/when the half-life expires, we'll have drivers in-tree which
> forget to set backlight_properties.type. I haven't checked, but if
> we're lucky they will default to "0".
Depends entirely on whether they kzalloc the structure or not before
calling backlight_device_register().
> What will be the runtime effects upon such unconverted drivers?
> Ideally we'd like them to continue to work OK, and to emit a runtime
> warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
> driver can be detected, warned about and fixed up by the core code.
The worst case I can think of is that we walk off the array - I guess
there's an argument for sanity checking that in backlight_show_type().
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] Backlight: Add backlight type
On Fri, 19 Nov 2010 10:53:52 -0500
Matthew Garrett wrote:
> There may be multiple ways of controlling the backlight on a given machine.
> Allow drivers to expose the type of interface they are providing, making
> it possible for userspace to make appropriate policy decisions.
>
> ...
>
> 60 files changed, 102 insertions(+), 0 deletions(-)
This patch has a pretty short half-life.
>
> ...
>
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -32,6 +32,12 @@ enum backlight_update_reason {
> BACKLIGHT_UPDATE_SYSFS,
> };
>
> +enum backlight_type {
> + BACKLIGHT_RAW,
> + BACKLIGHT_PLATFORM,
> + BACKLIGHT_FIRMWARE,
> +};
> +
> struct backlight_device;
> struct fb_info;
>
> @@ -62,6 +68,8 @@ struct backlight_properties {
> /* FB Blanking active? (values as for power) */
> /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> int fb_blank;
> + /* Backlight type */
> + enum backlight_type type;
> /* Flags used to signal drivers of state changes */
> /* Upper 4 bits are reserved for driver internal use */
> unsigned int state;
And if/when the half-life expires, we'll have drivers in-tree which
forget to set backlight_properties.type. I haven't checked, but if
we're lucky they will default to "0".
What will be the runtime effects upon such unconverted drivers?
Ideally we'd like them to continue to work OK, and to emit a runtime
warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
driver can be detected, warned about and fixed up by the core code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] Backlight: Add backlight type
On Fri, 19 Nov 2010 10:53:52 -0500
Matthew Garrett wrote:
> There may be multiple ways of controlling the backlight on a given machine.
> Allow drivers to expose the type of interface they are providing, making
> it possible for userspace to make appropriate policy decisions.
>
> ...
>
> 60 files changed, 102 insertions(+), 0 deletions(-)
This patch has a pretty short half-life.
>
> ...
>
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -32,6 +32,12 @@ enum backlight_update_reason {
> BACKLIGHT_UPDATE_SYSFS,
> };
>
> +enum backlight_type {
> + BACKLIGHT_RAW,
> + BACKLIGHT_PLATFORM,
> + BACKLIGHT_FIRMWARE,
> +};
> +
> struct backlight_device;
> struct fb_info;
>
> @@ -62,6 +68,8 @@ struct backlight_properties {
> /* FB Blanking active? (values as for power) */
> /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> int fb_blank;
> + /* Backlight type */
> + enum backlight_type type;
> /* Flags used to signal drivers of state changes */
> /* Upper 4 bits are reserved for driver internal use */
> unsigned int state;
And if/when the half-life expires, we'll have drivers in-tree which
forget to set backlight_properties.type. I haven't checked, but if
we're lucky they will default to "0".
What will be the runtime effects upon such unconverted drivers?
Ideally we'd like them to continue to work OK, and to emit a runtime
warning. In which case you'll need BACKLIGHT_RAW=1 so the unconverted
driver can be detected, warned about and fixed up by the core code.
[PATCH 1/5] Backlight: Add backlight type
There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by: Matthew Garrett Cc: Richard Purdie Cc: intel-gfx at lists.freedesktop.org Cc: dri-devel at lists.freedesktop.org --- Documentation/ABI/stable/sysfs-class-backlight | 20 drivers/acpi/video.c |1 + drivers/gpu/drm/nouveau/nouveau_backlight.c|2 ++ drivers/hid/hid-picolcd.c |1 + drivers/macintosh/via-pmu-backlight.c |1 + drivers/platform/x86/acer-wmi.c|1 + drivers/platform/x86/asus-laptop.c |1 + drivers/platform/x86/asus_acpi.c |1 + drivers/platform/x86/classmate-laptop.c|1 + drivers/platform/x86/compal-laptop.c |1 + drivers/platform/x86/dell-laptop.c |1 + drivers/platform/x86/eeepc-laptop.c|1 + drivers/platform/x86/eeepc-wmi.c |1 + drivers/platform/x86/fujitsu-laptop.c |1 + drivers/platform/x86/msi-laptop.c |1 + drivers/platform/x86/msi-wmi.c |1 + drivers/platform/x86/panasonic-laptop.c|1 + drivers/platform/x86/sony-laptop.c |1 + drivers/platform/x86/thinkpad_acpi.c |1 + drivers/platform/x86/toshiba_acpi.c|1 + drivers/staging/olpc_dcon/olpc_dcon.c |1 + drivers/staging/samsung-laptop/samsung-laptop.c|1 + drivers/usb/misc/appledisplay.c|1 + drivers/video/atmel_lcdfb.c|1 + drivers/video/aty/aty128fb.c |1 + drivers/video/aty/atyfb_base.c |1 + drivers/video/aty/radeon_backlight.c |1 + drivers/video/backlight/88pm860x_bl.c |1 + drivers/video/backlight/adp5520_bl.c |1 + drivers/video/backlight/adp8860_bl.c |1 + drivers/video/backlight/adx_bl.c |1 + drivers/video/backlight/atmel-pwm-bl.c |1 + drivers/video/backlight/backlight.c| 15 +++ drivers/video/backlight/corgi_lcd.c|1 + drivers/video/backlight/cr_bllcd.c |1 + drivers/video/backlight/da903x_bl.c|1 + drivers/video/backlight/ep93xx_bl.c|1 + drivers/video/backlight/generic_bl.c |1 + drivers/video/backlight/hp680_bl.c |1 + drivers/video/backlight/jornada720_bl.c|1 + drivers/video/backlight/kb3886_bl.c|1 + drivers/video/backlight/locomolcd.c|1 + drivers/video/backlight/max8925_bl.c |1 + drivers/video/backlight/mbp_nvidia_bl.c|1 + drivers/video/backlight/omap1_bl.c |1 + drivers/video/backlight/pcf50633-backlight.c |1 + drivers/video/backlight/progear_bl.c |1 + drivers/video/backlight/pwm_bl.c |1 + drivers/video/backlight/s6e63m0.c |1 + drivers/video/backlight/tosa_bl.c |1 + drivers/video/backlight/wm831x_bl.c|1 + drivers/video/bf54x-lq043fb.c |1 + drivers/video/bfin-t350mcqb-fb.c |1 + drivers/video/imxfb.c |1 + drivers/video/nvidia/nv_backlight.c|1 + drivers/video/omap2/displays/panel-acx565akm.c |1 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |1 + drivers/video/omap2/displays/panel-taal.c |2 ++ drivers/video/riva/fbdev.c |1 + include/linux/backlight.h |8 60 files changed, 102 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight index 4d637e1..70302f3 100644 --- a/Documentation/ABI/stable/sysfs-class-backlight +++ b/Documentation/ABI/stable/sysfs-class-backlight @@ -34,3 +34,23 @@ Contact: Richard Purdie Description: Maximum brightness for . Users: HAL + +What: /sys/class/backlight//type +Date: September 2010 +KernelVersion: 2.6.37 +Contact: Matthew Garrett +Description: + The type of interface controlled by . + "firmware": The driver uses a standard firmware interface + "platform": The driver uses a platform-specific interface + "raw": The driver controls hardware registers directly + + In the general case, when multiple backlight + interfaces are available for
[PATCH 1/5] Backlight: Add backlight type
There may be multiple ways of controlling the backlight on a given machine. Allow drivers to expose the type of interface they are providing, making it possible for userspace to make appropriate policy decisions. Signed-off-by: Matthew Garrett Cc: Richard Purdie Cc: intel-...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org --- Documentation/ABI/stable/sysfs-class-backlight | 20 drivers/acpi/video.c |1 + drivers/gpu/drm/nouveau/nouveau_backlight.c|2 ++ drivers/hid/hid-picolcd.c |1 + drivers/macintosh/via-pmu-backlight.c |1 + drivers/platform/x86/acer-wmi.c|1 + drivers/platform/x86/asus-laptop.c |1 + drivers/platform/x86/asus_acpi.c |1 + drivers/platform/x86/classmate-laptop.c|1 + drivers/platform/x86/compal-laptop.c |1 + drivers/platform/x86/dell-laptop.c |1 + drivers/platform/x86/eeepc-laptop.c|1 + drivers/platform/x86/eeepc-wmi.c |1 + drivers/platform/x86/fujitsu-laptop.c |1 + drivers/platform/x86/msi-laptop.c |1 + drivers/platform/x86/msi-wmi.c |1 + drivers/platform/x86/panasonic-laptop.c|1 + drivers/platform/x86/sony-laptop.c |1 + drivers/platform/x86/thinkpad_acpi.c |1 + drivers/platform/x86/toshiba_acpi.c|1 + drivers/staging/olpc_dcon/olpc_dcon.c |1 + drivers/staging/samsung-laptop/samsung-laptop.c|1 + drivers/usb/misc/appledisplay.c|1 + drivers/video/atmel_lcdfb.c|1 + drivers/video/aty/aty128fb.c |1 + drivers/video/aty/atyfb_base.c |1 + drivers/video/aty/radeon_backlight.c |1 + drivers/video/backlight/88pm860x_bl.c |1 + drivers/video/backlight/adp5520_bl.c |1 + drivers/video/backlight/adp8860_bl.c |1 + drivers/video/backlight/adx_bl.c |1 + drivers/video/backlight/atmel-pwm-bl.c |1 + drivers/video/backlight/backlight.c| 15 +++ drivers/video/backlight/corgi_lcd.c|1 + drivers/video/backlight/cr_bllcd.c |1 + drivers/video/backlight/da903x_bl.c|1 + drivers/video/backlight/ep93xx_bl.c|1 + drivers/video/backlight/generic_bl.c |1 + drivers/video/backlight/hp680_bl.c |1 + drivers/video/backlight/jornada720_bl.c|1 + drivers/video/backlight/kb3886_bl.c|1 + drivers/video/backlight/locomolcd.c|1 + drivers/video/backlight/max8925_bl.c |1 + drivers/video/backlight/mbp_nvidia_bl.c|1 + drivers/video/backlight/omap1_bl.c |1 + drivers/video/backlight/pcf50633-backlight.c |1 + drivers/video/backlight/progear_bl.c |1 + drivers/video/backlight/pwm_bl.c |1 + drivers/video/backlight/s6e63m0.c |1 + drivers/video/backlight/tosa_bl.c |1 + drivers/video/backlight/wm831x_bl.c|1 + drivers/video/bf54x-lq043fb.c |1 + drivers/video/bfin-t350mcqb-fb.c |1 + drivers/video/imxfb.c |1 + drivers/video/nvidia/nv_backlight.c|1 + drivers/video/omap2/displays/panel-acx565akm.c |1 + .../video/omap2/displays/panel-sharp-ls037v7dw01.c |1 + drivers/video/omap2/displays/panel-taal.c |2 ++ drivers/video/riva/fbdev.c |1 + include/linux/backlight.h |8 60 files changed, 102 insertions(+), 0 deletions(-) diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight index 4d637e1..70302f3 100644 --- a/Documentation/ABI/stable/sysfs-class-backlight +++ b/Documentation/ABI/stable/sysfs-class-backlight @@ -34,3 +34,23 @@ Contact: Richard Purdie Description: Maximum brightness for . Users: HAL + +What: /sys/class/backlight//type +Date: September 2010 +KernelVersion: 2.6.37 +Contact: Matthew Garrett +Description: + The type of interface controlled by . + "firmware": The driver uses a standard firmware interface + "platform": The driver uses a platform-specific interface + "raw": The driver controls hardware registers directly + + In the general case, when multiple backlight + interfaces are available for a sin
