Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?

Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?

[Hans de Goede]

Hi All,

I will be at Plumbers Dublin next week and I was wondering if
anyone interested in this wants to get together for a quick
discussion / birds of a feather session about this?

I have just posted version 2 of the RFC:
https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redhat.com/T/#u

If you are interested in meeting up please send me
an email off-list (no need to spam the list further with this)
also please let me know if there are any times which do not
work for you, and/or times which have your preference.

I don't have a specific room/time for this yet, but if people
are interested I will try to get a room from the organization
and if that does not work out I'm sure we will figure something
out.

One of the things which I would like to discuss is using
the backlight brightness as connector object property vs
external (not part of the compositor) tools to control the
brightness like e.g. xbacklight, quoting from the RFC:

"people using
non fully integrated desktop environments like e.g. sway often use custom
scripts binded to hotkeys to get functionality like the brightness
up/down keyboard hotkeys changing the brightness. This typically involves
e.g. the xbacklight utility.

Even if the xbacklight utility is ported to use kms with the new connector
object brightness properties then this still will not work because
changing the properties will require drm-master rights and e.g. sway will
already hold those."

Note one obvious solution here would be for these use-cases to keep
using the old /sys/class/backlight interface for this, with the downside
that we will then be stuck to that interface for ever...

Regards,

Hans

Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?

[Simon Ser]

On Friday, September 9th, 2022 at 12:23, Hans de Goede <hdegoede@redhat.com> wrote:

> "people using
> non fully integrated desktop environments like e.g. sway often use custom
> scripts binded to hotkeys to get functionality like the brightness
> up/down keyboard hotkeys changing the brightness. This typically involves
> e.g. the xbacklight utility.
> 
> Even if the xbacklight utility is ported to use kms with the new connector
> object brightness properties then this still will not work because
> changing the properties will require drm-master rights and e.g. sway will
> already hold those."

I don't think this is a good argument. Sway (which I'm a maintainer of)
can add a command to change the backlight, and then users can bind their
keybinding to that command. This is not very different from e.g. a
keybind to switch on/off a monitor.

We can also standardize a protocol to change the backlight across all
non-fully-integrated desktop environments (would be a simple addition
to output-power-management [1]), so that a single tool can work for
multiple compositors.

Simon

[1]: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/114

Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?

[Ville Syrjälä]

On Fri, Sep 09, 2022 at 12:23:53PM +0200, Hans de Goede wrote:
> Hi All,
> 
> I will be at Plumbers Dublin next week and I was wondering if
> anyone interested in this wants to get together for a quick
> discussion / birds of a feather session about this?
> 
> I have just posted version 2 of the RFC:
> https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redhat.com/T/#u
> 
> If you are interested in meeting up please send me
> an email off-list (no need to spam the list further with this)
> also please let me know if there are any times which do not
> work for you, and/or times which have your preference.
> 
> I don't have a specific room/time for this yet, but if people
> are interested I will try to get a room from the organization
> and if that does not work out I'm sure we will figure something
> out.
> 
> One of the things which I would like to discuss is using
> the backlight brightness as connector object property vs
> external (not part of the compositor) tools to control the
> brightness like e.g. xbacklight, quoting from the RFC:
> 
> "people using
> non fully integrated desktop environments like e.g. sway often use custom
> scripts binded to hotkeys to get functionality like the brightness
> up/down keyboard hotkeys changing the brightness. This typically involves
> e.g. the xbacklight utility.
> 
> Even if the xbacklight utility is ported to use kms with the new connector
> object brightness properties then this still will not work because
> changing the properties will require drm-master rights and e.g. sway will
> already hold those."
> 
> Note one obvious solution here would be for these use-cases to keep
> using the old /sys/class/backlight interface for this, with the downside
> that we will then be stuck to that interface for ever...

Isn't xbacklight the thing that only works when you *have* the
backlight property? Ie. currently only works on intel ddx which
adds a custom property but doesn't work on modesetting ddx for
example.

-- 
Ville Syrjälä
Intel

Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?

[Daniel Stone]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Fri, 9 Sept 2022 at 12:50, Simon Ser <contact@emersion.fr> wrote:

> On Friday, September 9th, 2022 at 12:23, Hans de Goede <
> hdegoede@redhat.com> wrote:
> > "people using
> > non fully integrated desktop environments like e.g. sway often use custom
> > scripts binded to hotkeys to get functionality like the brightness
> > up/down keyboard hotkeys changing the brightness. This typically involves
> > e.g. the xbacklight utility.
> >
> > Even if the xbacklight utility is ported to use kms with the new
> connector
> > object brightness properties then this still will not work because
> > changing the properties will require drm-master rights and e.g. sway will
> > already hold those."
>
> I don't think this is a good argument. Sway (which I'm a maintainer of)
> can add a command to change the backlight, and then users can bind their
> keybinding to that command. This is not very different from e.g. a
> keybind to switch on/off a monitor.
>
> We can also standardize a protocol to change the backlight across all
> non-fully-integrated desktop environments (would be a simple addition
> to output-power-management [1]), so that a single tool can work for
> multiple compositors.


Yeah, I mean, as one of the main people arguing that non-fully-integrated
desktops are not the design we want, I agree with Simon.

Cheers,

Daniel

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?

[Hans de Goede]

Hi All,

On 9/9/22 12:23, Hans de Goede wrote:
> Hi All,
> 
> I will be at Plumbers Dublin next week and I was wondering if
> anyone interested in this wants to get together for a quick
> discussion / birds of a feather session about this?
> 
> I have just posted version 2 of the RFC:
> https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redhat.com/T/#u
> 
> If you are interested in meeting up please send me
> an email off-list (no need to spam the list further with this)
> also please let me know if there are any times which do not
> work for you, and/or times which have your preference.
> 
> I don't have a specific room/time for this yet, but if people
> are interested I will try to get a room from the organization
> and if that does not work out I'm sure we will figure something
> out.

I have a date, time and location for this now. The BOF session
is scheduled on Monday September 12th in the "Meeting 9" room:

https://lpc.events/event/16/contributions/1390/

Regards,

Hans