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@xxxxxxxxxx/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
