Thanks for your answers! See reply below. 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました: > On Sun, 14 May 2017 14:43:44 +0200 > Philipp Kerling <pkerl...@casix.org> wrote: > > To start off: > > * Kodi should offer the user the opportunity to select inside the > > application on which monitor he/she wants to have Kodi displayed > > on > > when in full-screen mode. Now I see that I can do this with > > either > > wl_shell_surface::set_fullscreen and > > zxdg_toplevel::set_fullscreen, > > which expect a wl_output to display the window on. But I am not > > sure > > how I should match the wl_output instance I get from Wayland > > with > > the monitor that the user selected. As far as I can see, I can > > only > > identify the monitor by way of "make" and "model". This seems > > reasonable enough at first glance, but I think that in multi- > > monitor > > configurations it is not so uncommon to buy the same monitor > > model > > multiple times - I personally have done this. Naturally, the > > "make" > > and "model" of both monitors are identical, so I cannot discern > > which is which by looking at the wl_output metadata. Am I > > missing > > something here? > > That is all true, you are not missing anything. > > It is a missing piece of protocol - I believe no-one has had both the > need and the time to work on getting anything better yet. > > > Why isn't e.g. the connector the output is connected > > to exported? > > Because connector names are specific to DRM while Wayland (core > protocol at least) is not. I'm not sure I agree. See further below.
> Also, would you not want to identify the > monitor rather than which connector it happens to be plugged in? I think that it's not quite decided yet what we want the user experience to be on the Kodi side, i.e. do we want to bind output to the physical monitor (however it is identified) or the GPU connector? You can probably find use cases for both, so it's not an easy decision to make. With X11 it was limited to the latter, so my first approach was to mimic that. Ideally, both would be possible with Wayland and the application can decide what is best for its specific use case. I realize that this might be too much to ask for all at once, so I'll talk to my mentor to decide which case we want to focus on for Kodi. There are also two different points involved in this discussion: I. How the *user* identifies which output/monitor the fullscreen display should be on (e.g. with make+model+connector name, or by compositor-specific numbering). II. How *Kodi* or any other application then stores this, re-identifies this output/monitor and maps it to a wl_output on application start and hotplug. Possiblities include saving information pertaining to the output, the connector, the physical device, or any combination. > Would > a user even know which connector name matches to which monitor? Yes, I also thought about this. Tech-savvy users might actually be able to identify the connector name, but you are absolutely right that usually users should not be expected to. In fact, having make and model available actually is an improvement in that regard (on X11, Kodi *only* displays connector since that is what's available via RANDR). So: How do you suggest to identify a particular monitor then? As I said, make and model are not sufficient - but serial number will not help the user in identification. If there are multiple monitors of the same model, I do not think that they (i.e. the physical devices) can be reasonably discerned in a way that is transparent to the user. That's why I suggested the connector name. > To expose such a name in the protocol, we should define the space or > meaning of the names. Human-readable? That's not the connector name, > IMHO. Machine-parseable? Needs a very strict definition to work. > Both? RANDR output names (which are somewhat close to what I refer to as connector names - it's a matter of debate whether output or connector name would be more fitting for the Kodi use case) are specifically meant to be "presented to the user", but I can see your point. I think that machine-parseable is doable, also considering that RANDR did have a "ConnectorType" property which is probably part of what we'd want here. > A simple numbering with a way in the compositor to identify the > monitors? Maybe. What exactly do you mean by "a way in the compositor to identify the monitors"? Like you can tell the compositor to display the output names (briefly) on the outputs so the user knows which is which? If so, couldn't this also be done by the application at least with more or less arbitrarily assigned numbers by mapping a surface to each known output that displays said number? I'm beginning to think that something along those lines might be one of the more user-friendly options of solving I. above. > > This would allow way better matching and also give the > > user a chance to select the right monitor without having to try > > all > > options. Serial number (or anything similar - not sure if the > > EDID > > has this though) could also be OK. > > EDID may have a serial number, yes. > > Physical monitor devices are not the only things though. An output > could be just a window in another window system. An output could be > at > the end of a streaming network connection. Etc. So aiming for a > generic > solution here would have a really wide scope. Also answering the first question above: I don't see how "make" and "model" (and the mode list for that matter) in wl_output fit with this statement. They are also limited to traditional physical devices (monitors), yet are in the core protocol. I don't suppose that it makes sense to classify an output in another window system with a manufacturer and model. That said, I also don't see why "connector" (or something similar) would be fundamentally different from what is already there. > However, there already is a unique numbering for wl_outputs, even > though it's not exactly user-friendly. It is the wl_output "name" > advertised by wl_registry, which you use in wl_registry.bind request > to > create a wl_output instance. This "name" is the same for all clients. Is this name (which is usually the integer number of the protocol in enumeration order if I got that right) *guaranteed* to stay the same (for a given wl_output) * when I restart the application? * when I restart the compositor? * when I restart the computer? * when I connect additional monitors? * when I rearrange monitors in the compositor? * when I start the application with the monitor unplugged and plug it in later (while the app is running)? If not, this would not be useful to Kodi. Whether other clients see the same "name" or not is not especially relevant here. The specific use case is to save the monitor/output identifier to the configuration file and have it persist across both app and device restarts and output configuration changes. We would especially like to support the last point of the enumeration above, i.e. starting on a fallback (unspecified) monitor and then switching fullscreen output to the preferred monitor once it is connected by the user. > What we would really need is a new protocol extension designed to > cater > for specific use cases and offering the additional information to > help > make user-friendly UIs. Maybe compositors should a) number of the > outputs, and b) let the user give them arbitrary names to be shown in > application UIs? I don't see the real benefit in b), it is IMHO too much effort for the average user. I'm also not sure what I would personally label my screens as besides "Left screen" and "Right screen", which the compositor could as well figure out on its own :-) > But then, do you tie the output identity to the > connector or the physical device? Or an intelligent mix? As I said, best is probably if the application has enough information to be able to do either. > Would it be in scope for your work to design such an extension? It's > relatively easy to write a protocol proposal, but getting it reviewed > and hopefully ack'd by more than one DE project is often hard and > time > consuming. And then you'd need to provide an implementation on at > least > one compositor, unless you find someone else to collaborate with you. If the consensus is that this will, in some form or another, need a protocol extension, I'll have to discuss with my mentor whether this can be pursued as part of my GSoC work, especially the reference implementation part. I think that it is a possibility, but does require that there is a realistic expectation that at least mutter or KWin will support the extension in the future. Otherwise it could be very hard to justify. > > * Am I correct in that if I use zxdg_toplevel (i.e. give this role > > to > > a surface), I cannot also use wl_shell_surface? If so, this > > would be > > Yes. wl_shell and xdg_shell suites of protocol extensions are > mutually > exclusive, you cannot use both for the same wl_surface. wl_shell is > the > deprecated one, and xdg_shell suite is the replacement waiting to be > decleared stable. > > > quite a problem. I can see that zxdg_toplevel functionality is > > mostly superior to that of wl_shell_surface, but it has one > > omission > > that is crucial for Kodi: the ability to request a specific > > refresh > > rate for fullscreen display. This is needed for closely matching > > the > > display and video FPS so duplicated and skipped frames are kept > > to a > > minimum. Is this an intentional omission and/or is there > > anything > > that provides this functionality? > > Hopefully the xdg_shell designers would answer that, but I believe it > has been omitted for now to make it easier to declare the first > fundamental parts of xdg_shell stable. It is missing a lot, but the > foundation must agreed upon first before building more on top. So is there any realistic chance to have such functionality integrated? What steps would have to be done? > FYI, even wl_shell's framerate parameter is not a guarantee, it is a > wish. The player will have to be able to deal with arbitrary output > refresh rates in any case and it may dynamically change, too. That's OK. Obviously Kodi can run with any framerate (the output might only support 60 Hz anyway, for example). We just want to have the possiblity of influencing the refresh rate to improve the video playback experience where possible. Realistic route seems to be to focus on xdg_shell, since my relatively uneducated guess is that no real-world desktop compositor honors the wl_shell framerate parameter anyway. Weston just ignored it last time I checked. > The presentation timing extension should help with that very much. wp_presentation support is on the roadmap. - Philipp _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel