<div dir="ltr"><div dir="ltr">On Fri, 9 Sept 2022 at 12:50, Simon Ser <<a href="mailto:contact@emersion.fr">contact@emersion.fr</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, September 9th, 2022 at 12:23, Hans de Goede <<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>> wrote:<br>
> "people using<br>
> non fully integrated desktop environments like e.g. sway often use custom<br>
> scripts binded to hotkeys to get functionality like the brightness<br>
> up/down keyboard hotkeys changing the brightness. This typically involves<br>
> e.g. the xbacklight utility.<br>
> <br>
> Even if the xbacklight utility is ported to use kms with the new connector<br>
> object brightness properties then this still will not work because<br>
> changing the properties will require drm-master rights and e.g. sway will<br>
> already hold those."<br>
<br>
I don't think this is a good argument. Sway (which I'm a maintainer of)<br>
can add a command to change the backlight, and then users can bind their<br>
keybinding to that command. This is not very different from e.g. a<br>
keybind to switch on/off a monitor.<br>
<br>
We can also standardize a protocol to change the backlight across all<br>
non-fully-integrated desktop environments (would be a simple addition<br>
to output-power-management [1]), so that a single tool can work for<br>
multiple compositors.</blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div>Daniel</div></div></blockquote></div>