On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
On Fri, 19 Nov 2010 10:53:52 -0500 Matthew Garrett mjg@redhat.com 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().