Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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,

Re: KMS backlight ABI proposition

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. >

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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:

Re: KMS backlight ABI proposition

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.

Re: KMS backlight ABI proposition

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: >>> >>> -

Re: KMS backlight ABI proposition

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,

Re: KMS backlight ABI proposition

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.

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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.

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

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

Re: KMS backlight ABI proposition

+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

KMS backlight ABI proposition

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