Handing clients among multiple servers
AFAIK, the handling of server crashes is still mostly an unresolved area. While in Arcan it's explicitly handled via SHMIF, there are only incompatible attempts to resolve this in Enlightenment and kwin_wayland, which allow the clients to wait for a while while a server is relaunched (and it needs to be the same server which knows some credentials from the previous run). I got an idea when reading this: https://www.linux.org.ru/forum/talks/16983280?cid=16984372 While the exact approach described there (moving the clients between nested and parent compositors for the need of grouping) may sound niche, there may be other uses for it. One of them is simplifying the testing of Wayland servers, so a nested server is launched and a client is moved to it temporarily, instead of re-launching test clients every time. Another, more practical, use is a backup server which the clients connect to in case of an emergency (the main server has crashed). Such a server does not even need to be presented to a user, it may run in background like screen/tmux, and it should be tiny, simple and robust. Similar examples: • backup BIOSes in some motherboards, which can be used for booting if the main BIOS was corrupted due to an incorrect upgrade; • a backup window manager in Windows 7, which is used when DWM.exe crashes (due to buggy GPU drivers, hardware problems in GPU, etc.); • compiz-reloaded has a crash handler and launches some other process (xterm by default, or any other fallback WM) instead of itself, so the session is not rendered unusable (and some display managers quit the whole X.Org session if the WM has crashed with no replacement). In the X11 world, the X server takes the role of such a backup server, but there is no such separate entity in the Wayland world yet. Handing over should be handled by the clients themselves, with security concerns (so a malicious server cannot steal the control over them). It seems to me though that the approaches for handing clients between multiple user-controlled servers, and between a main and a backup server, is fundamentally different. For multiple user-controlled servers (like parent and nested, or vice versa): 1a) a client requests the current server to connect to a new server (specified), or 1b) the current server informs the client about a new server (specified) to connect; 2) the current server grants the reconnect; 3) the client freezes its event queue, disconnects from the current server and connects to the new one. For a main server and a backup server: 1) the current servers informs the clients about the backup server beforehand; 2) a client determines that the main server has crashed; 3) the client freezes its event queue and connects to the backup server. Though, if the main server is always launched by the backup one, it can be simplified to a common approach: the current (or backup) server informs the client about a new (or main) server, and the client connects to it whenever needed. All the client needs to know is that the server A trusts the server B. The source of trust is another discussion point (should it be merely an executable path, or something more complicated?) What's your opinion on it? I'm not a Wayland expert, and I suppose there may be significant problems (like dealing with resource pointers). Do you have better ideas maybe?
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Fri, 09 Sep 2022, Hans de Goede wrote: > Hi all, > > Here is v2 of my "drm/kms: control display brightness through drm_connector > properties" RFC: > > Changes from version 1: > - Drop bl_brightness_0_is_min_brightness from list of new connector > properties. > - Clearly define that 0 is always min-brightness when setting the brightness > through the connector properties. > - Drop bl_brightness_control_method from list of new connector > properties. > - Phase 1 of the plan has been completed > > As discussed already several times in the past: > https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ > > https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ > > The current userspace API for brightness control offered by > /sys/class/backlight devices has various issues: > > 1. There is no way to map the backlight device to a specific >display-output / panel (1) > 2. Controlling the brightness requires root-rights requiring >desktop-environments to use suid-root helpers for this. > 3. The meaning of 0 is not clearly defined, it can be either off, >or minimum brightness at which the display is still readable >(in a low light environment) > 4. It's not possible to change both the gamma and the brightness in the >same KMS atomic commit. You'd want to be able to reduce brightness to >conserve power, and counter the effects of that by changing gamma to >reach a visually similar image. And you'd want to have the changes take >effect at the same time instead of reducing brightness at some frame and >change gamma at some other frame. This is pretty much impossible to do >via the sysfs interface. > > As already discussed on various conference's hallway tracks > and as has been proposed on the dri-devel list once before (2), > it seems that there is consensus that the best way to to solve these > 2 issues is to add support for controlling a video-output's brightness > through properties on the drm_connector. > > This RFC outlines my plan to try and actually implement this, > which has 3 phases: > > > Phase 1: Stop registering multiple /sys/class/backlight devs for a single > display > = > > On x86 there can be multiple firmware + direct-hw-access methods > for controlling the backlight and in some cases the kernel registers > multiple backlight-devices for a single internal laptop LCD panel. > > A plan to fix this was posted here: > https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ > And a pull-req actually implementing this plan has been send out this week: > https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/ > > > Phase 2: Add drm_connector properties mirroring the matching backlight device > = > > The plan is to add a drm_connector helper function, which optionally takes > a pointer to the backlight device for the GPU's native backlight device, > which will then mirror the backlight settings from the backlight device > in a set of read/write brightness* properties on the connector. > > This function can then be called by GPU drivers for the drm_connector for > the internal panel and it will then take care of everything. When there > is no native GPU backlight device, or when it should not be used then > (on x86) the helper will use the acpi_video_get_backlight_type() to > determine which backlight-device should be used instead and it will find > + mirror that one. > > > Phase 3: Deprecate /sys/class/backlight uAPI > > > Once most userspace has moved over to using the new drm_connector > brightness props, a Kconfig option can be added to stop exporting > the backlight-devices under /sys/class/backlight. The plan is to > just disable the sysfs interface and keep the existing backlight-device > internal kernel abstraction as is, since some abstraction for (non GPU > native) backlight devices will be necessary regardless. > > It is unsure if we will ever be able to do this. For example 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. > > > The drm_connector brightness properties > === > > The new uAPI for this consists of 2 properties: > > 1. "display brightness": rw 0-int32_max property controlling the brightness > setting > of the connected display. The actual maximum of this will
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Wed, Sep 28, 2022 at 01:04:01PM +0300, Jani Nikula wrote: > On Fri, 09 Sep 2022, Hans de Goede wrote: > > Hi all, > > > > Here is v2 of my "drm/kms: control display brightness through drm_connector > > properties" RFC: > > > > Changes from version 1: > > - Drop bl_brightness_0_is_min_brightness from list of new connector > > properties. > > - Clearly define that 0 is always min-brightness when setting the brightness > > through the connector properties. > > - Drop bl_brightness_control_method from list of new connector > > properties. > > - Phase 1 of the plan has been completed > > > > As discussed already several times in the past: > > https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ > > > > https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ > > > > The current userspace API for brightness control offered by > > /sys/class/backlight devices has various issues: > > > > 1. There is no way to map the backlight device to a specific > >display-output / panel (1) > > 2. Controlling the brightness requires root-rights requiring > >desktop-environments to use suid-root helpers for this. > > 3. The meaning of 0 is not clearly defined, it can be either off, > >or minimum brightness at which the display is still readable > >(in a low light environment) > > 4. It's not possible to change both the gamma and the brightness in the > >same KMS atomic commit. You'd want to be able to reduce brightness to > >conserve power, and counter the effects of that by changing gamma to > >reach a visually similar image. And you'd want to have the changes take > >effect at the same time instead of reducing brightness at some frame and > >change gamma at some other frame. This is pretty much impossible to do > >via the sysfs interface. > > > > As already discussed on various conference's hallway tracks > > and as has been proposed on the dri-devel list once before (2), > > it seems that there is consensus that the best way to to solve these > > 2 issues is to add support for controlling a video-output's brightness > > through properties on the drm_connector. > > > > This RFC outlines my plan to try and actually implement this, > > which has 3 phases: > > > > > > Phase 1: Stop registering multiple /sys/class/backlight devs for a single > > display > > = > > > > On x86 there can be multiple firmware + direct-hw-access methods > > for controlling the backlight and in some cases the kernel registers > > multiple backlight-devices for a single internal laptop LCD panel. > > > > A plan to fix this was posted here: > > https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ > > And a pull-req actually implementing this plan has been send out this week: > > https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/ > > > > > > Phase 2: Add drm_connector properties mirroring the matching backlight > > device > > = > > > > The plan is to add a drm_connector helper function, which optionally takes > > a pointer to the backlight device for the GPU's native backlight device, > > which will then mirror the backlight settings from the backlight device > > in a set of read/write brightness* properties on the connector. > > > > This function can then be called by GPU drivers for the drm_connector for > > the internal panel and it will then take care of everything. When there > > is no native GPU backlight device, or when it should not be used then > > (on x86) the helper will use the acpi_video_get_backlight_type() to > > determine which backlight-device should be used instead and it will find > > + mirror that one. > > > > > > Phase 3: Deprecate /sys/class/backlight uAPI > > > > > > Once most userspace has moved over to using the new drm_connector > > brightness props, a Kconfig option can be added to stop exporting > > the backlight-devices under /sys/class/backlight. The plan is to > > just disable the sysfs interface and keep the existing backlight-device > > internal kernel abstraction as is, since some abstraction for (non GPU > > native) backlight devices will be necessary regardless. > > > > It is unsure if we will ever be able to do this. For example 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. > > > > > > The drm_connecto
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Wed, Sep 28, 2022 at 01:57:18PM +0300, Ville Syrjälä wrote: > On Wed, Sep 28, 2022 at 01:04:01PM +0300, Jani Nikula wrote: > > On Fri, 09 Sep 2022, Hans de Goede wrote: > > > Hi all, > > > > > > Here is v2 of my "drm/kms: control display brightness through > > > drm_connector properties" RFC: > > > > > > Changes from version 1: > > > - Drop bl_brightness_0_is_min_brightness from list of new connector > > > properties. > > > - Clearly define that 0 is always min-brightness when setting the > > > brightness > > > through the connector properties. > > > - Drop bl_brightness_control_method from list of new connector > > > properties. > > > - Phase 1 of the plan has been completed > > > > > > As discussed already several times in the past: > > > https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ > > > > > > https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ > > > > > > The current userspace API for brightness control offered by > > > /sys/class/backlight devices has various issues: > > > > > > 1. There is no way to map the backlight device to a specific > > >display-output / panel (1) > > > 2. Controlling the brightness requires root-rights requiring > > >desktop-environments to use suid-root helpers for this. > > > 3. The meaning of 0 is not clearly defined, it can be either off, > > >or minimum brightness at which the display is still readable > > >(in a low light environment) > > > 4. It's not possible to change both the gamma and the brightness in the > > >same KMS atomic commit. You'd want to be able to reduce brightness to > > >conserve power, and counter the effects of that by changing gamma to > > >reach a visually similar image. And you'd want to have the changes take > > >effect at the same time instead of reducing brightness at some frame > > > and > > >change gamma at some other frame. This is pretty much impossible to do > > >via the sysfs interface. > > > > > > As already discussed on various conference's hallway tracks > > > and as has been proposed on the dri-devel list once before (2), > > > it seems that there is consensus that the best way to to solve these > > > 2 issues is to add support for controlling a video-output's brightness > > > through properties on the drm_connector. > > > > > > This RFC outlines my plan to try and actually implement this, > > > which has 3 phases: > > > > > > > > > Phase 1: Stop registering multiple /sys/class/backlight devs for a single > > > display > > > = > > > > > > On x86 there can be multiple firmware + direct-hw-access methods > > > for controlling the backlight and in some cases the kernel registers > > > multiple backlight-devices for a single internal laptop LCD panel. > > > > > > A plan to fix this was posted here: > > > https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ > > > And a pull-req actually implementing this plan has been send out this > > > week: > > > https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/ > > > > > > > > > Phase 2: Add drm_connector properties mirroring the matching backlight > > > device > > > = > > > > > > The plan is to add a drm_connector helper function, which optionally takes > > > a pointer to the backlight device for the GPU's native backlight device, > > > which will then mirror the backlight settings from the backlight device > > > in a set of read/write brightness* properties on the connector. > > > > > > This function can then be called by GPU drivers for the drm_connector for > > > the internal panel and it will then take care of everything. When there > > > is no native GPU backlight device, or when it should not be used then > > > (on x86) the helper will use the acpi_video_get_backlight_type() to > > > determine which backlight-device should be used instead and it will find > > > + mirror that one. > > > > > > > > > Phase 3: Deprecate /sys/class/backlight uAPI > > > > > > > > > Once most userspace has moved over to using the new drm_connector > > > brightness props, a Kconfig option can be added to stop exporting > > > the backlight-devices under /sys/class/backlight. The plan is to > > > just disable the sysfs interface and keep the existing backlight-device > > > internal kernel abstraction as is, since some abstraction for (non GPU > > > native) backlight devices will be necessary regardless. > > > > > > It is unsure if we will ever be able to do this. For example 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. > > > > >
