On 2018-04-10 5:09 PM, Pekka Paalanen wrote: > How do you define "one wl_output"? > > Do you mean it is the wl_output as identified by its global name (int), > and gets destroyed when the wl_registry sends the remove event?
Yes, I mean one wl_output as in one global on the registry. > Unplugging a monitor likely causes the corresponding wl_output global > to be destroyed, right? > > If so, that means a couple of things: > > - If a user unplugs and re-plugs the same monitor to the same connector, > you require the xdg-output name to be chosen different as the > wl_output is no longer the same. Not necessarily. Uniqueness is only consistent across all of the wl_output globals currently in existence. Once one goes away, a new wl_output can utilize the same name. > - When ever a compositor starts, all wl_outputs are new, which means > all xdg-output names must be new as well. So if an application saves > a name in its config, it will never find a match anymore after the > compositor gets restarted. Again, the only uniqueness constraint is across the current list of living wl_output globals. Nothing prevents the names from being the same across sessions, in fact it's strongly suggested that they are. > My recent work on Weston introduces the concept of "heads" which > essentially refer to connectors and share their names. Weston "outputs" > are basically rendering engine instances and in clone mode one > weston_output feeds the image into several heads at the same time. Then > we have wl_output that represents the monitor, carrying its make and > model, and being 1:1 to a "head" when the head is active (but not > necessarily connected to a monitor). > > Given that you say clones will not share the xdg-output name, then in a > Weston implementation I would use either the connector name or the > monitor info (EDID) as the base for creating xdg-output names. I still > don't know which one would be appropriate for the clients, though. I'd do HDMI-A-1-1, DP-1-2, etc, if subdividing one output into several logical wl_outputs. The specification is deliberately left vague on how the compositor comes up with the name. Do it however you feel is useful. > - If a user unplugs a monitor and replugs it into another connector, do > applications expect the xdg-output name for the new situation to be > different from the old situation? > > - If a user unplugs a monitor and replaces it with a different monitor > plugged into the same connector, do applications expect the > xdg-output name to be different from before? Up to your compositor. I'm just going to use the connector but this is again deliberately vague. > The reason why I am insisting on this is that you said that > applications are free to save the name and expect to find it later > under some circumstances. We need to establish those circumstances, so > that application writers can know what it actually means to find or not > find an xdg-output of a certain name they've seen before. If it's all > undefined, then it would be better to just specify that applications > should not expect to be able to find xdg-outputs with the same name as > they have seen some time before. I don't want to specify the degree to which the compositor embues the name with meaning, just that it does so somewhat consistently. The constraint is: at a bare minimum the same configuration of hardware and software produces the same names across settings. I do not want to bring into this already nicely generic API any underlying details of the output's hardware, like an EDID - whether or not we abstract it into some more generic sounding event name. "Name" is a nice vague term that compositors can give any meaning they like. Will it address your concerns if I: 1. Add a statement clarifying that the names are unique across all living wl_outputs and may be reused if the corresponding wl_output global is removed 2. Add a statement clarifying that persistence of names between sessions is only guaranteed for the same hardware & software configuration -- Drew DeVault _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
