On 24/02/17 12:44, Hans de Goede wrote:
Hi,
On 24-02-17 11:23, Martin Peres wrote:
On 24/02/17 11:59, Hans de Goede wrote:
Hi,
On 24-02-17 10:48, Hans de Goede wrote:
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede
On Fri, 24 Feb 2017, Daniel Thompson wrote:
> On 24/02/17 08:43, Jani Nikula wrote:
> >> - "Some PWM based backlight allow adjusting the PWM modulation
> >> frequency." you don't need a motivation for *why* I would want to
> >> change the mod freq on the fly, actually in my experience you
> >>
On 24/02/17 08:43, Jani Nikula wrote:
>> - "Some PWM based backlight allow adjusting the PWM modulation
>> frequency." you don't need a motivation for *why* I would want to
>> change the mod freq on the fly, actually in my experience you
>> shouldn't since this can lead to flickery backlights.
>
>
Hi,
On 24-02-17 11:23, Martin Peres wrote:
On 24/02/17 11:59, Hans de Goede wrote:
Hi,
On 24-02-17 10:48, Hans de Goede wrote:
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede wrote:
On 24-02-17 09:43, Jani Nikula w
On 24/02/17 11:59, Hans de Goede wrote:
Hi,
On 24-02-17 10:48, Hans de Goede wrote:
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede wrote:
On 24-02-17 09:43, Jani Nikula wrote:
I don't think we have any good ideas h
Hi,
On 24-02-17 10:48, Hans de Goede wrote:
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede wrote:
On 24-02-17 09:43, Jani Nikula wrote:
I don't think we have any good ideas how to solve the property max
changing on
Hi,
On 24-02-17 10:46, Hans de Goede wrote:
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede wrote:
On 24-02-17 09:43, Jani Nikula wrote:
I don't think we have any good ideas how to solve the property max
changing on the fly. But based on the discussion so far, i
Hi,
On 24-02-17 10:34, Jani Nikula wrote:
On Fri, 24 Feb 2017, Hans de Goede wrote:
On 24-02-17 09:43, Jani Nikula wrote:
I don't think we have any good ideas how to solve the property max
changing on the fly. But based on the discussion so far, it's starting
to look like we'll need to study
On Fri, 24 Feb 2017, Hans de Goede wrote:
> On 24-02-17 09:43, Jani Nikula wrote:
>> I don't think we have any good ideas how to solve the property max
>> changing on the fly. But based on the discussion so far, it's starting
>> to look like we'll need to study that more thoroughly.
>
> As I menti
Hi,
On 24-02-17 09:43, Jani Nikula wrote:
On Thu, 23 Feb 2017, Stéphane Marchesin wrote:
On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
wrote:
On Wed, 22 Feb 2017, Stéphane Marchesin wrote:
On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
wrote:
If the KMS property exposes a fixed number of
On Thu, 23 Feb 2017, Stéphane Marchesin wrote:
> On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
> wrote:
>> On Wed, 22 Feb 2017, Stéphane Marchesin wrote:
>>> On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
>>> wrote:
If the KMS property exposes a fixed number of steps (say 100), it becomes
>
On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
wrote:
> On Wed, 22 Feb 2017, Stéphane Marchesin
> wrote:
> > On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
> > wrote:
> >> If the KMS property exposes a fixed number of steps (say 100), it
> becomes
> >> easy for the userspace to express the wanted
On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
wrote:
> On Wed, 22 Feb 2017, Stéphane Marchesin wrote:
>> On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
>> wrote:
>>> If the KMS property exposes a fixed number of steps (say 100), it becomes
>>> easy for the userspace to express the wanted brightne
Hi,
On 23-02-17 09:55, Jani Nikula wrote:
On Wed, 22 Feb 2017, Hans de Goede wrote:
My first thought was that your proposal is reasonable, but on second
thought I foresee trouble here with e.g. the backlight level save / restore
code in systemd still using the sysfs interface, while the deskto
Hi,
On 23-02-17 09:40, Jani Nikula wrote:
On Wed, 22 Feb 2017, Stéphane Marchesin wrote:
On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
wrote:
If the KMS property exposes a fixed number of steps (say 100), it becomes
easy for the userspace to express the wanted brightness. However, on drivers
On Wed, 22 Feb 2017, Hans de Goede wrote:
> My first thought was that your proposal is reasonable, but on second
> thought I foresee trouble here with e.g. the backlight level save / restore
> code in systemd still using the sysfs interface, while the desktop
> environment has moved on to the prop
On Wed, 22 Feb 2017, Stéphane Marchesin wrote:
> On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
> wrote:
>> If the KMS property exposes a fixed number of steps (say 100), it becomes
>> easy for the userspace to express the wanted brightness. However, on drivers
>> exposing less than these 100 step
On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the more likely to be interested in the discussion but
> plea
Can we at least suggest they try, again with a similar disclaimer that
"this might not work in practice"? The more I think about it, a normalized
0-100 API doesn't really simplify implementations for anybody, especially
if we don't have a natural step level.
On Wed, Feb 22, 2017 at 6:00 AM, Jani N
Hi,
On 22-02-17 16:05, Jani Nikula wrote:
On Mon, 20 Feb 2017, Daniel Thompson wrote:
=== 1) Backlight device interoperability ===
Since we need to keep backward compatibility of the backlight, we have
to keep the current backlight drivers.
Here are possible options:
- Exclusive access: Un
On Mon, 20 Feb 2017, Dave Airlie wrote:
> How do you tackle that end of the problem, how does the i915/drm core
> know when the driver for the one backlight it needs has appeared, and
> is working, by deferring this to userspace we let the system load all
> the drivers and the policy of picking th
On Mon, 20 Feb 2017, Thierry Reding wrote:
>> - The luminance curve of the backlight drivers is not specified, which
>> can lead to a bad user experience: Little changes in the highest levels
>> but drastic changes in the low levels.
>
> I think this is something that the backlight framework shou
On 22/02/17 17:05, Jani Nikula wrote:
On Mon, 20 Feb 2017, Daniel Thompson wrote:
=== 1) Backlight device interoperability ===
Since we need to keep backward compatibility of the backlight, we have
to keep the current backlight drivers.
Here are possible options:
- Exclusive access: Unregi
On 20/02/17 21:57, Hans de Goede wrote:
Hi,
On 20-02-17 20:27, Dave Airlie wrote:
On 17 February 2017 at 22:58, Martin Peres
wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the
people we
h
On Mon, 20 Feb 2017, Daniel Thompson wrote:
>>> === 1) Backlight device interoperability ===
>>>
>>> Since we need to keep backward compatibility of the backlight, we have
>>> to keep the current backlight drivers.
>>>
>>> Here are possible options:
>>>
>>> - Exclusive access: Unregister a backli
On Mon, 20 Feb 2017, Hans de Goede wrote:
> On 17-02-17 13:58, Martin Peres wrote:
> So 1 and 2 are closely related the problem is that if we expose a
> fixed number of steps we need to convert in both directions, and if
> userspace tries to increment by doing read, add 1, write and we expose
> 1-
On Tue, 21 Feb 2017, "Jasper St. Pierre" wrote:
> Instead of normalizing to 100, I think we should expose a max level, and
> specify that's max brightness. Every single step in the range should have a
> visible difference in output lumens.
The drivers can't guarantee that.
BR,
Jani.
--
Jani N
I don't work on this anymore, but, even disregarding the mess that is ACPI
backlight:
I think when people start interfacing with the Backlight API, they wonder
why it's not normalized. And then you start implementing it, and you
realize that some writes don't do anything. And that when you read ba
On Mon, Feb 20, 2017 at 2:27 PM, Dave Airlie wrote:
> On 17 February 2017 at 22:58, Martin Peres
> wrote:
>> Hey everyone,
>>
>> We have been working towards exposing the backlight as a KMS property
>> instead of relying on the backlight drivers. We have CC:ed the people we
>> have found to be t
Hi All,
On 17-02-17 13:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property instead
of relying on the backlight drivers. We have CC:ed the people we have found to
be the more likely to be interested in the discussion but please add everyo
Hi,
On 20-02-17 20:27, Dave Airlie wrote:
On 17 February 2017 at 22:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be inter
On 17 February 2017 at 22:58, Martin Peres wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the more likely to be interested in the discussion but
> please
Cc'ing Daniel, Lee and Jingoo, the backlight subsystem maintainers.
On 17/02/17 14:58, Martin Peres wrote:
> Hey everyone,
>
> We have been working towards exposing the backlight as a KMS property
> instead of relying on the backlight drivers. We have CC:ed the people we
> have found to be the mo
On 20/02/17 12:46, Martin Peres wrote:
+plasma-devel, as suggested by Martin Gräßlin.
This reply also adds the current drivers/video/backlight maintainers (I
forwarded the original mail to them separately, so I've been pretty
brutal with the delete key when quoting the original mail).
On
+plasma-devel, as suggested by Martin Gräßlin.
On 17/02/17 14:58, Martin Peres wrote:
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be interested i
Hey everyone,
We have been working towards exposing the backlight as a KMS property
instead of relying on the backlight drivers. We have CC:ed the people we
have found to be the more likely to be interested in the discussion but
please add everyone you think would have some experience with thi
36 matches
Mail list logo
