Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?
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-7b9791c86...@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
Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?
On Fri, 9 Sept 2022 at 12:50, Simon Ser wrote: > On Friday, September 9th, 2022 at 12:23, Hans de Goede < > hdego...@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
Re: Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?
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-7b9791c86...@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?
On Friday, September 9th, 2022 at 12:23, Hans de Goede 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
Meeting (BOF) at Plumbers Dublin to discuss backlight brightness as connector object property RFC?
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-7b9791c86...@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
