by Anton Vorontsov

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

On Mon, Nov 19, 2012 at 11:29:05AM +0900, Alex Courbot wrote:
> On Saturday 17 November 2012 19:38:50 Anton Vorontsov wrote:
> > > +++ b/drivers/power/power_seq/Kconfig
> > > @@ -0,0 +1,2 @@
> > > +config POWER_SEQ
> > > + tristate
> >
> > This really needs a proper Kconfig description and a help text, shortly
> > describing the purpose of the subsystem.
>
> Does it? The current state makes power seqs automatically selected by drivers
> that need it, and they do not appear in the configuration menu. If we add a
> description they will then become a visible item, so the logic would be to
> make it user-selectable.

Ah. OK, then yes, there is no need for the short description, but the help
text would a good idea anyway.

Thanks,
Anton.

2012-11-20 14:48:46

On Tue, Nov 20, 2012 at 09:54:29PM +0000, Grant Likely wrote:
> On Sat, 17 Nov 2012 19:55:45 +0900, Alexandre Courbot <[email protected]> wrote:

> > With the advent of the device tree and of ARM kernels that are not
> > board-tied, we cannot rely on these board-specific hooks anymore but

> This isn't strictly true. It is still perfectly fine to have board
> specific code when necessary. However, there is strong encouragement to
> enable that code in device drivers as much as possible and new board
> files need to have very strong justification.

This isn't the message that's gone over, and even for device drivers
everyone seems to be taking the whole device tree thing as a move to
pull all data out of the kernel. In some cases there are some real
practical advantages to doing this but a lot of the people making these
changes seem to view having things in DT as a goal in itself.

> I'm thinking about the scripts as trivial-to-parse ascii strings that
> have a very simple set of commands. The commands use resources already
> defined in the node. ie. 'g0' refers to the first entry in the gpios
> property. 'r0' for the regulator, 'p0' for the pwms, 'd' means delay. By
> no means take this as the format to use, it is just an example off the
> top of my head, but it is already way easier to work with than putting
> each command into a node.

It does appear to have some legibility challenges, especially with using
the indexes into the arrays of resources. On the other hand the arrays
should be fairly small.

> > +Platform Data Format
> > +--------------------
> > +All relevant data structures for declaring power sequences are located in
> > +include/linux/power_seq.h.

> Hmm... If sequences are switched to a string instead, then platform_data
> should also use it. The power sequence data structures can be created at
> runtime by parsing the string.

Seems like a step backwards to me - why not let people store the more
parsed version of the data? It's going to be less convenient for users
on non-DT systems.

As I said in my earlier reviews I think this is a useful thing to have
as a utility library for drivers independantly of the DT bindings, it
would allow drivers to become more data driven. Perhaps we can rework
the series so that the DT bindings are added as a final patch? All the
rest of the code seems OK.

Attachments:

(No filename) (2.30 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2012-11-21 01:56:46

by Alexandre Courbot

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

Hi Tomi,

On Tuesday 20 November 2012 22:48:18 Tomi Valkeinen wrote:
> I guess there's a reason, but the above looks a bit inconsistent. For
> gpio you define the gpio resource inside the step. For power and pwm the
> resource is defined before the steps. Why wouldn't "pwm = <&pwm 2
> 5000000>;" work in step2?

That's mostly a framework issue. Most frameworks do not export a function that
allow to dereference a phandle - they expect resources to be declared right
under the device node and accessed by name through foo_get(device, name). So
using phandles in power sequences would require to export these additional
functions and also opens the door to some inconsistencies - for instance, your
PWM phandle could be referenced a second time in the sequence with a different
period - how do you know that these are actually referring the same PWM
device?

> > +When a power sequence is run, its steps is executed one after the other
> > until +one step fails or the end of the sequence is reached.
>
> The document doesn't give any hint of what the driver should do if
> running the power sequence fails. Run the "opposite" power sequence?
> Will that work for all resources? I'm mainly thinking of a case where
> each enable of the resource should be matched by a disable, i.e. you
> can't call disable if no enable was called.

We discussed that issue already (around v5 I think) and the conclusion was
that it should be up to the driver. When we simply enable/disable resources it
is easy to revert, but in the future non-boolean properties will likely be
introduced, and these cannot easily be reverted. Moreover some drivers might
have more complex recovery needs. This deserves more discussion I think, as
I'd like to have some "generic" recovery mechanism that covers most of the
cases.

Alex.

2012-11-21 04:23:20

by Alexandre Courbot

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

Hi Grant,

On Wednesday 21 November 2012 05:54:29 Grant Likely wrote:
> > With the advent of the device tree and of ARM kernels that are not
> > board-tied, we cannot rely on these board-specific hooks anymore but
>
> This isn't strictly true. It is still perfectly fine to have board
> specific code when necessary. However, there is strong encouragement to
> enable that code in device drivers as much as possible and new board
> files need to have very strong justification.

But doesn't introducing board-specific code into the kernel just defeats the
purpose of the DT? If we extend this logic, we are heading straight back to
board-definition files. To a lesser extent than before I agree, but the problem
is fundamentally the same.

> > need a way to implement these sequences in a portable manner. This patch
> > introduces a simple interpreter that can execute such power sequences
> > encoded either as platform data or within the device tree. It also
> > introduces first support for regulator, GPIO and PWM resources.
>
> This is where I start getting nervous. Up to now I've strongly resisted
> adding any kind of interpreted code to the device tree. The model is to
> identify hardware, but require the driver to know how to control it. (as
> compared to ACPI which is entirely designed around executable
> bytecode).
>
> While the power sequences described here certainly cannot be confused
> with a Turing complete bytecode, it is a step in that direction.

Technically speaking power sequences are a step towards an interpreter, but it
is a very small one and it should not go much further than the current state.
I understand the concern of having "code" into the DT but I really think it
should be viewed from a different angle.

Powering sequences are special in that they can be affected by the board design
or the devices variations. For instance hundreds of different panels with
backlights are currently compatible with the pwm-backlight driver. The only
thing that differenciates them is how the backlight is powered on and off. If
you are to build a kernel that is supposed to support all these panels, you
would need to embed all the powering sequences in the kernel even though only
one of them will be used by one specific board. Power sequences in the DT help
preventing that.

With that stated, it is clear that we should not need to define more than the
short, simple sequences of actions that cannot be elegantly handled by the
driver. Anything beyond that should be handled by the driver itself. In
particular, here are a few things I do *not* want to see included in power
seqs:

- conditionals/jumps (or it's not a sequence anymore).
- direct access to hardware. Resources must at least be abstracted in some
way. You shall not e.g. access the address space directly.
- support for non-power related resources - that is out of the special case of
powering sequences and should be done by the driver

That should keep the "grammar" simple, and the sequences short enough to that
we can consider then as data belonging to the device, and not as code that is
interpreted.

> I think this will get very verbose in a hurry. Already this simple
> example is 45 lines long. Using the device tree structure to encode the
> language doesn't look like a very good fit. Not to mention that the
> order of operations is entirely based on the node name. Want to insert
> an operation between step0 and step1? Need to rename step1, step2, and
> step3 to do so.

I don't like that steps numbering thing neither, but it seems to be the best
way to do it so far.

As for the DT structure not being adapted for this - I would agree if we
wanted to implement a complete interpreter, but that's precisely not the case.
More about this later.

> This implementation also isn't very consistent. The gpio is referenced
> with a phandle in step3/step0, but the regulator and pwm are referenced
> by id.

Tomi made the same remark - the reason for using the phandle in GPIO is
because GPIO framework does not support referencing GPIOs by name yet. I
wanted to DT bindings to reflect the underlying framework as much as possible
until we have a function like gpio_get(device, id).

However I agree that this makes things inconsistent at the moment and would
require a bindings change. And in the case of the DT this is actually easy to
implement (I did it in some previous versions). I'll make sure to do it.

> As an alternative, what about something like the following?
>
> backlight {
> compatible = "pwm-backlight";
> ...
>
> /* resources used by the power sequences */
> pwms = <&pwm 2 5000000>;
> pwm-names = "backlight";
> regulators = <&backlight_reg>;
> gpios = <&gpio 28 0>;
>
> power-on-sequence = "r0e;d10000m;p0e;g0s";
> power-off-sequence = "g0c;p0d;d10000m;r0d";
> };

Well, *now* it really looks like bytecode. :)

> I'm thinking about the scripts as trivial-to-parse ascii strings that
> have a very simple set of commands. The commands use resources already
> defined in the node. ie. 'g0' refers to the first entry in the gpios
> property. 'r0' for the regulator, 'p0' for the pwms, 'd' means delay. By
> no means take this as the format to use, it is just an example off the
> top of my head, but it is already way easier to work with than putting
> each command into a node.

I'd argue that this opens the door wide open towards having a complete
interpreter in the device tree. At least DT nodes restrict what we can do
conveniently.

> The trick is still to define a syntax that doesn't fall apart when it
> needs to be extended. I would also like to get opinions on whether or
> not conditionals or loops should be supported (ie. loop waiting for a
> status to change). If they should then we need to be a lot more careful
> about the design (and due to my aforementioned nervousness, somebody may
> need to get me therapy).

That's IMHO the main argument in favor of using DT nodes here (the syntax
extension, not your therapy). They can be extended simply by adding properties
to them, and I was relying on this to make power seqs extensible while keeping
things consistent (and backward-compatible). For instance, when we want to
support voltage setting in regulators we can just add a "voltage" property for
that.

So to sum up the pros of the current node-base representation:
- give a "data like" representation of powering sequences (what they should
be, actually)
- puts sanity barriers for not turning power seqs into a real code interpreter
- easily extensible

There are probably a few cons, the numbering of steps being one, but at least
we don't need to design a new DSL and care too much about extensibility which
is, in the nodes case, built-in and free.

I also like to make it clear that I don't want to see this going out of
control and that any extension proposal would have to be thoroughly justified
and reviewed - and better not contradict any of the 3 points listed above.

If that makes you feel better, maybe we can try and fix what is wrong with the
current bindings instead of introducing a new language that will be, by
nature, more complex to handle and difficult to extend without breaking things?

Alex.

2012-11-21 08:14:21

On 2012-11-21 10:32, Alex Courbot wrote:

>> Ok. I'll need to dig up the conversation
>
> IIRC it was somewhere around here:
>
> https://lkml.org/lkml/2012/9/7/662
>
> See the parent messages too.

Thanks.

>> Did you consider any examples
>> of how some driver could handle the error cases?
>
> For all the (limited) use cases I considered, playing the power-off sequence
> when power-on fails just works. If power-off also fails you are potentially in
> more trouble though. Maybe we could have another "run" function that does not
> stop on errors for handling such cases where you want to "stop everything you
> can".

If the power-off sequence disables a regulator that was supposed to be
enabled by the power-on sequence (but wasn't enabled because of an
error), the regulator_disable is still called when the driver runs the
power-off sequence, isn't it? Regulator enables and disables are ref
counted, and the enables should match the disables.

> Failures might be better handled if sequences have some "recovery policy"
> about what to do when they fail, as mentioned in the link above. As you
> pointed out, the driver might not always know enough about the resources
> involved to do the right thing.

Yes, I think such recovery policy would be needed.

Tomi

Attachments:

signature.asc (897.00 B)
OpenPGP digital signature

2012-11-21 10:00:45

by Alexandre Courbot

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

On Wednesday 21 November 2012 16:48:45 Tomi Valkeinen wrote:
> If the power-off sequence disables a regulator that was supposed to be
> enabled by the power-on sequence (but wasn't enabled because of an
> error), the regulator_disable is still called when the driver runs the
> power-off sequence, isn't it? Regulator enables and disables are ref
> counted, and the enables should match the disables.

And there collapses my theory.

> > Failures might be better handled if sequences have some "recovery policy"
> > about what to do when they fail, as mentioned in the link above. As you
> > pointed out, the driver might not always know enough about the resources
> > involved to do the right thing.
>
> Yes, I think such recovery policy would be needed.

Indeed, from your last paragraph this makes even more sense now.

Oh, and I noticed I forgot to reply to this:

> This I didn't understand. Doesn't "<&pwm 2 xyz>" point to a single
> device, no matter where and how many times it's used?

That's true - however when dereferencing the phandle, the underlying framework
will try to acquire the PWM, which will result in failure if the same resource
is referenced several times.

One could compare the phandles to avoid this, but in your example you must
know that for PWMs the "xyz" part is not relevant for comparison.

This makes referencing of resources by name much easier to implement and more
elegant with respect to frameworks leveraging.

Alex.

2012-11-21 11:06:11

by Tomi Valkeinen

Mmmm so maybe I am misinterpreting things, but it looks like we
have just buried the power sequences here, haven't we?

Alex.

On Wed, Nov 21, 2012 at 10:32 PM, Tomi Valkeinen <[email protected]> wrote:
> On 2012-11-21 15:00, Thierry Reding wrote:
>> On Wed, Nov 21, 2012 at 02:04:17PM +0200, Tomi Valkeinen wrote:
>>> On 2012-11-21 13:40, Thierry Reding wrote:
>>>> On Wed, Nov 21, 2012 at 01:06:03PM +0200, Tomi Valkeinen wrote:
>>>
>>> (sorry for bouncing back and forth with my private and my @ti addresses.
>>> I can't find an option in thunderbird to only use one sender address,
>>> and I always forget to change it when responding...)
>>>
>>>>> My suggestion would be to go forward with an in-driver solution, and
>>>>> look at the DT based solution later if we are seeing an increasing bloat
>>>>> in the drivers.
>>>>
>>>> Assuming we go with your approach, what's the plan? We're actually
>>>> facing this problem right now for Tegra. Basically we have a DRM driver
>>>> that can drive the panel, but we're still missing a way to hook up the
>>>> backlight and panel enabling code. So we effectively can't support any
>>>> of the LVDS devices out there without this series.
>>>
>>> Could you describe the hardware setup you have related to the LCD and
>>> backlight? Is it a public board with public schematics?
>>
>> I don't think any of the schematics are public. The Tamonten Evaluation
>> Carrier is available publicly from our website and the schematics are
>> available on demand as well. If required I can probably arrange to send
>> you a copy.
>
> No need, I think your answer below is enough.
>
>>> I've understood that you don't have anything special in your board, just
>>> an LCD and a backlight, and the power sequences are related to powering
>>> up the LCD and the backlight, without anything board specific. If so,
>>> there's no need for board specific code, but just improving the panel
>>> and backlight drivers to support the models you use.
>>
>> Correct. Basically we have two GPIOs that each enable the panel or the
>> backlight respectively and one PWM to control the brightness. Are the
>
> The panel GPIO goes to the panel hardware device, and enables the panel?
> And similarly for the PWM GPIO, it goes to the PWM hardware device? Just
> making sure there are no other components involved.
>
>> panel drivers that you refer to those in drivers/video? I'm not sure if
>> adding more ad-hoc drivers there just to move them to a generic
>> framework in the next cycle is a good idea. I'd rather spend some time
>> on helping to get the framework right and have drivers for that instead.
>
> We have panel drivers for omap in drivers/video/omap2/displays/. I'm not
> sure if other platforms have their own versions of panel drivers, but
> probably adding a simple panel driver system for a platform would not be
> too difficult. It could even be quite hardcoded, i.e. embedded directly
> into the display subsystem driver, just to get something working until
> the common panel framework is available.
>
> Yes, I agree it's not good idea to add more platform specific panel
> drivers. But it's unclear when CPF will be merged, so if you need to get
> the panel working now, I don't see a simple ad-hoc driver as too
> horrible. But, of course, I'm not the one making the decision whether to
> merge or not =).
>
>> From what I understand by looking at the OMAP display drivers, they also
>> provide the timings for the displays. Steffen's videomode helpers can be
>> used to represent these easily in DT, but I suppose if all of those per-
>
> Right. Note that I didn't present omap panel drivers as perfect
> examples, just examples =).
>
>> panel specifics are represented in the drivers then that won't be needed
>> anymore either.
>
> Yes, for most panels with just one native mode and nothing else, the
> panel driver can contain the timings.
>
> However, this subject has been discussed earlier a few times. If the
> panel in question doesn't need any special power-on/off sequences, just,
> perhaps, one gpio or such, we could still use DT video modes. This would
> simplify the cases where you have lots of different very simple panels.
>
> Obviously the same questions apply to DT video modes than to the power
> sequences, and while I do think it's better to handle the timings inside
> the driver, I'm not too much against video timings in DT. The reason
> being that the video modes are quite clear, simple and stable data,
> versus the much more complex and open-ended power sequences.
>
>>> I don't see any problem with adding small Tegra specific panel drivers
>>> for the time being, with the intention of converting to common panel
>>> framework when that's available.
>>
>> I can take a look at how such a driver could be implemented, but again,
>
> Don't look at the mainline omap panel drivers, at least not too closely
> =). They contain hackery that will be cleaned up with CPF.
>
> I think there are two methods to implements simple panel drivers:
>
> The hardcoded one, where the display subsystem driver manages a few
> different panel models. This is obviously not very expandable or
> "correct", but should probably work just fine for a few models, until
> CPF is usable.
>
> Something like CPF will have: have the panel device/driver as a platform
> device/driver, which will register itself to the display subsystem. And
> with "itself" I mean some kind of struct panel_entity, with a few ops
> implemented by the panel driver.
>
> Well, this goes a bit out of subject. If you want to discuss panel
> drivers more, please start a new thread. Laurent's upcoming CPF v2
> should give you good ideas what the model will be.
>
> Tomi
>
>

2012-11-21 15:12:28

On Thu, Nov 22, 2012 at 11:01:34AM +0900, Alexandre Courbot wrote:

> The thing I don't understand here is why would anyone want power
> sequences without the DT representation. Guys, that's the whole point! :)

> If we are to implement things into drivers, then callback functions
> are going to serve us just as well - even better, for they are more
> flexible. All we need to do is define a dedicated ops structure and
> have the driver plug the right callback functions depending on the
> "compatible" property of the DT device node. We don't need a framework
> for that.

It allows drivers (both board drivers and actual drivers) to write these
things in a semi-scripted form instead of having to open code everything
each time, it'd save a bunch of tedious stuff with resource requesting
for example.

Attachments:

(No filename) (807.00 B)
signature.asc (836.00 B)
Digital signature Download all attachments

2012-11-22 19:39:08

by Alexandre Courbot

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

On Thu, Nov 22, 2012 at 11:06 AM, Mark Brown
<[email protected]> wrote:
> On Thu, Nov 22, 2012 at 11:01:34AM +0900, Alexandre Courbot wrote:
>
>> The thing I don't understand here is why would anyone want power
>> sequences without the DT representation. Guys, that's the whole point! :)
>
>> If we are to implement things into drivers, then callback functions
>> are going to serve us just as well - even better, for they are more
>> flexible. All we need to do is define a dedicated ops structure and
>> have the driver plug the right callback functions depending on the
>> "compatible" property of the DT device node. We don't need a framework
>> for that.
>
> It allows drivers (both board drivers and actual drivers) to write these
> things in a semi-scripted form instead of having to open code everything
> each time, it'd save a bunch of tedious stuff with resource requesting
> for example.

Mmm, I overlooked that point - that's fair enough. Guess I should
remove all DT support and stress that point in the documentation. Then
maybe we'll have a deal.

Alex.

2012-11-22 20:18:30

by Linus Walleij

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

On Wed, Nov 21, 2012 at 2:31 AM, Mark Brown
<[email protected]> wrote:

> As I said in my earlier reviews I think this is a useful thing to have
> as a utility library for drivers independantly of the DT bindings, it
> would allow drivers to become more data driven. Perhaps we can rework
> the series so that the DT bindings are added as a final patch? All the
> rest of the code seems OK.

I have the same (limited by experience) opinion. Working sort of
near som audio drivers I have understood that power sequencing
is a big issue not only for things like this backlight example, but
even more so in the area of audio to avoid clicks and pops.

Is it correct to assume that this library will be useful also for ALSA
SoC type of devices?

Then whether to couple that to DT or ACPI or SFI or whatever
is a different discussion altogether.

Yours,
Linus Walleij

2012-11-22 21:01:49

by Alexandre Courbot

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

On Thu, Nov 22, 2012 at 12:12 AM, Thierry Reding
<[email protected]> wrote:
> On Thu, Nov 22, 2012 at 12:02:47AM +0900, Alexandre Courbot wrote:
>> Mmmm so maybe I am misinterpreting things, but it looks like we
>> have just buried the power sequences here, haven't we?
>
> I don't think so. In fact I was just starting to think that maybe for
> Tegra we could have a generic panel driver which used power sequences
> to abstract away the pin differences for powering up the panel. Since
> most likely that will be where the differences are there is a lot of
> potential to factor things out into sequences.
>
> Perhaps what we may want to postpone for now is the DT representation
> since that's what Tomi and Grant seem to be mostly opposed to.

The thing I don't understand here is why would anyone want power
sequences without the DT representation. Guys, that's the whole point! :)

If we are to implement things into drivers, then callback functions
are going to serve us just as well - even better, for they are more
flexible. All we need to do is define a dedicated ops structure and
have the driver plug the right callback functions depending on the
"compatible" property of the DT device node. We don't need a framework
for that.

And if we are not going to use power seqs that's probably what we
should do in order to get panels to work on Tegra boards for now. Then
see how things turn out with the panel framework and whether there is
a use for power seqs in it. But by the meantime, I don't see any
motivation to merge power seqs sans DT support.

Alex.

2012-11-22 21:40:49

On Thu, Nov 22, 2012 at 09:57:22AM +0100, Linus Walleij wrote:

> Is it correct to assume that this library will be useful also for ALSA
> SoC type of devices?

ASoC has facilities for autogenerating the bulk of the sequences which
with modern devices is all that you really need.

Attachments:

(No filename) (281.00 B)
signature.asc (836.00 B)
Digital signature Download all attachments

2012-11-26 11:54:58

by Alexandre Courbot

[permalink] [raw]

Subject: Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

On Friday 23 November 2012 05:40:21 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 01:39:41PM +0000, Grant Likely wrote:
> [...]
>
> > I do think that each sequence should be contained within a single
> > property, but I'm open to other suggestions.
>
> IIRC a very early prototype did implement something like that. However
> because of the resource issues this had to be string based, so that the
> sequences looked somewhat like (Alex, correct me if I'm wrong):
>
> power-on = <"REGULATOR", "power", 1, "GPIO", "enable", 1>;

You're right. Back when the burning sun of July was beating down a little bit
too hard on my head.

https://lkml.org/lkml/2012/7/9/30

> Instead we could possibly have something like:
>
> power-on = <0 &reg 1,
> 1 &gpio 42 0 1>;
>
> Where the first cell in each entry defines the type (0 = regulator, 1 =
> GPIO) and the rest would be a regular OF specifier for the given type of
> resource along with some defined parameter such as enable/disable,
> voltage, delay in ms, ... I don't know if that sounds any better. It
> looks sort of cryptic but it is more "in the spirit of" DT, right Grant?
>
> Writing this down, it seems to me like even that proposal was already
> discussed at some point. Again, Alex may remember better.

The idea that we had was to use preprocessor support in DTC to use macros
instead of strings for the step type. We also thought about using phandles
directly in there as well, but this would require some more API support.

Anyway, at the current point we are not even sure whether we want or need
power seqs in the DT - so let's keep this topic on hold for a while. We can
still introduce the feature without DT support, and if it eventually turns out
during this winter that expressing power seqs in the DT makes sense, we will
have plenty of archives to read in front of the fire.

Alex.

2012-11-26 16:42:14

by Grant Likely

On Tue, Nov 27, 2012 at 04:37:32PM +0100, Laurent Pinchart wrote:

> One possibly crazy idea I had was to replace backlight devices as we know them
> with LED devices (a LED driver IC shouldn't be supported by different APIs
> depending on whether the LEDs it drives are used as a backlight or not), and
> have the panel hook up with the associated LED device to expose backlight
> operations through the CDF. Panels with a backlight controller tied to the
> panel controller (control through DSI for instance) would implement the
> backlight operations directly without instantiating a LED device. This still
> leaves the question of the userspace backlight brightness API open.

I remember looking at that before but never actually got round to it, it
seems like a sensible idea to me.

Attachments:

(No filename) (795.00 B)
signature.asc (836.00 B)
Digital signature Download all attachments