Hey folks, it appears this topic has gone stale, without any consensus being reached. A core issue impacting this discussion which remains undecided is the following:
- Is it in Mir's scope as a display server to provide a client api for configuring mir server settings like those for displays & input devices? Or should Mir expose a mirserver API for these settings, and require the shell to implement its own API via an alternative channel (e.g. DBus) for a settings client to use? If we clarify this point, then hopefully the path ahead will be more clear. What say all? -Gerry On 13/10/15 01:33, Christopher James Halse Rogers wrote: > > > On Mon, Oct 12, 2015 at 10:53 PM, Alexandros Frantzis > <alexandros.frant...@canonical.com> wrote: > > On Wed, Sep 30, 2015 at 12:50:14PM +0300, Alexandros Frantzis wrote: > >> On Wed, Sep 30, 2015 at 02:04:00PM +1000, Christopher James Halse > >> Rogers wrote: > >> > Forked from review¹. > >> > > >> > I think we're currently handling display configuration events > >> incorrectly, > >> > or at least in a way that will be surprising to clients. > >> > >> For a bit of background, the current scheme is: > >> > >> 1. User changes the hardware config (e.g. adds/removes a monitor) > >> 2. Update base config > >> 3.1 If base config was applied before then apply the new base config > >> 3.2 If per-session config was applied, do nothing, expect the client > >> to respond to the configuration_changed event by setting a new > >> session > >> config based on the updated base config. > >> > >> The reason for "do nothing" in 3.2 is to avoid applying the base > >> configuration before the client has applied its own new client config, > >> in order to avoid extra flickering. > >> > >> > When the hardware configuration changes we send the new > >> configuration to all > >> > clients. However, if a client has specified a different display > >> > configuration then we *don't* change it. The upshot is that > >> > mir_connection_create_display_configuration() will *not* return the > >> > currently active display configuration. > > > > A few additional thoughts and realizations after investigating LP > > #1498021 ([1]) and pondering on the current code some more. > > > > mir_connection_create_display_configuration() was originally created > > with a single purpose in mind, which was to allow clients to get a valid > > configuration on which to base their own custom configurations. It was > > not intended to give back either the current session config or the > > active config. The only guarantee was that it accurately represented > > the hardware state (connected monitors and available modes). The base > > config > > was used for this purpose although we could have used the more bare > > configuration as returned by the mg::Display class. > > > > Until recently, MediatingDisplayChanger honored this purpose by sending > > new configurations to clients only as a response to hardware changes. > > This was enough (sans bugs) for the use cases we had until then, which > > involved clients responding to configuration changes from the server. > > > > However, since then we have made changes that try to turn the value > > returned by mir_connection_create_display_configuration() to something > > it wasn't designed to be, i.e., an accurate representation of the > > current state. These changes, as Alan mentioned in an previous email, > > have conflated the various types of display configurations we have > > in Mir (base, active, session). > > > > A few questions and my take on them: > > > > 1. Which configuration types and changes to them does a normal > > (non-modesetting) client need to know about? > > > > None of the types are particularly useful. > > > > Perhaps it would be useful for the client to know about the active > > config (e.g. when another session with a custom config has the focus), > > but I can't think of any interesting use cases for this. I am all ears, > > though. > > I'd go the other way; we want unfocused, non-modesetting applications to > *not* receive notifications about the active config changing. Otherwise, > they'll react to the config change only to have to undo that reaction > when they receive focus. > > These clients may want to receive notifications for base config changes; > for example, presentation applications which want to put their > presentation on the newly-available projector. > > > > > > > 2. Which configuration types and changes to them does a > > modesetting client need to know about? > > > > In order for a client to set a custom config it needs at least a config > > that accurately represents the hardware state. The base config is useful > > if we want to allow clients to take it into account when setting a > > custom config, e.g., don't turn a screen on if it's off in the base > > config. > > > > Again I don't see an interesting use case for following the active > > config. > > > > 3. Which configuration types and changes does the display > > settings app need to know about > > modesetting) client need to know about? > > 3-𝜀: Can we get away with not supporting display settings apps? For > example: GNOME Shell has no display configuration application interface. > > > It needs to be able to get and set the current base configuration. > > > > > > So, my take is that the only config that clients need to be notified > > about is the base one. Clients also need to be able to set the session > > and base configs (subject to permission restrictions): > > > > // The same as the current mir_connection_create_display_configuration > > // with a more accurate name and guaranteed to always return the base > > config, > > // not just a valid hardware config > > mir_connection_create_base_display_config() > > > > // Set base configuration, used only be display settings app > > mir_connection_apply_base_display_config() > > I remain sceptical about adding API that should only be used by exactly > one client, that we control, and ship with Unity :). > > > > > // Set session configuration > > mir_connection_apply_display_config() > > I think we additionally want mir_connection_unapply_display_config(), > for an application that no longer needs its own display config. > > > > -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
