On Thu, 5 Oct 2017 14:24:27 +0300 Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 05/10/17 13:43, Pekka Paalanen wrote: > > > in Weston, the initial window placement is essentially random. There is > > some guessing based on the current pointer location, but as there could > > be several pointers, that's not reliable either. When there is no > > pointer to guess from and Weston needs to pick an output, it simply > > picks the first in a list. We might as well randomize it too, since all > > outputs are equal in the current design. Only luck guarantees the order > > in the output list. > > Please don't make our lives harder, just because =). As you explain > above, it is not random at the moment. > > I understand relying on the above logic is not very good, and it can > change in the future, but as you explain below, we're not in a position > where we have a good way to deal with the use case at the moment. As long as you are aware it can break any time. *I* won't break it just for the sake of it. :-) But I also don't intend to make sure the behaviour stays the same. > > If an application wants to show up on a specific output, there is > > currently no Wayland extension that I recall to allow that, aside from > > IVI-shell/LayerManager infrastructure. If you really need something on > > a specific output, one way is to write a new protocol extension that > > suits your use case, especially if your use case is not a normal PC > > desktop. > > Yes, we really need something on a specific user-defined output. One of > the use cases is a board with an LCD with touchscreen and an HDMI. No > mouse. So the pointer is never on the HDMI. We may want to launch a > "view-only" application shown on the HDMI. > > Or, we may have a mouse, and use the HDMI as the "main screen", which > means that our launcher application is shown on the HDMI instead of the LCD. > > Or we may not have any mouse/touchscreen at all (although if I recall > right, this needs a hack in weston to get it start), and we want to > launch applications on specific screen. > > Just a few examples. Right, all those point in the direction of a custom shell plugin where you can have your window management rules. Trying to drive window management from outside a Wayland compositor is not a good idea... > And yes, if you create a real product, perhaps IVI-shell or such is the > way to go. Our use is more of a development/demo cases, although I don't > see why they would not be usable in a real product too. ..which is why I never liked the IVI LayerManager etc. approach much. IVI-shell is really just a wrapper that still wants you to write a plugin to do the actual window management. On the application facing side it removes all the desktop windowing features and literally just offers you a window ID number to base window management on. No provision for clients to tell the output, aside from what you can imply with an ID. > I think just having an env variable, which gives a hint to weston about > on which display the window should be openend, would cover our use cases. That is a very special environment where one could expect that to work. That would be possible given: - a protocol extension to relay the wanted output - client toolkit patch to read the env var and use the protocol extension - a new weston shell plugin to implement the protocol extension If one were to write a special protocol extension just for your use case, the extension could be dead simple. There is another plugin in Weston, fullscreen-shell, but it is in a bit bad shape and only supports a single client at a time, but allows explicit control of outputs. It has no window management as it has no windows: you associate a wl_surface for an output, and that's it. If you needed windows, you could use sub-surfaces. > > If your use case is a normal PC desktop, then you could participate in > > the xdg-shell protocol suite development to get a desktop standard for > > initial window placement. That would probably be preceded by designing > > a protocol extension that would let clients meaningfully choose an > > initial output to begin with. > > > > There is also the option of writing your own shell plugin to Weston, to > > give you exactly the window management behaviour you want, including > > the choice of the output. > > > > The very least, there was some work towards configuring the output > > layout in weston.ini that is still unfinished, which might perhaps > > provide a workaround similar to changing connector ordering but with > > only half the luck required. There is already a way to turn a connector > > off in weston.ini, and my current work is aiming to allow > > force-enabling disconnected connectors as well. > > > > Changing connector ordering in the kernel to get Weston to do something > > it has never deliberately intended in the first place is just wrong, so > > please do not use Weston as a justification for this kernel module > > parameter. > > Weston was just one piece of the puzzle. If it was just Weston, I guess > we'd have looked at patching Weston instead of the kernel. > > As the cover letter says, it's also about the fb emulation and custom > DRM apps. It seems quite common for these applications to just pick the > first connector. And the series also gives features for debugging, > testing, and disabling displays altogether. > > The series is an RFC, and kind of feels like a hack. I think the order > of the DRM connectors should be considered random, in a perfect world. > Still, this series fixes real issues without the need to go fix every > broken/not-finished legacy and non-legacy app out there that uses DRM, > and gives us some debug/test functionality. True. And then you will be stuck with it. It's also hard to care about fbdev. My point was not to NAK this series. My point was to remove Weston from the justification, that is all. Thanks, pq
Attachment:
pgpx5QkXwGO7a.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
