Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

[Tomi Valkeinen <tomi.valkeinen@ti.com>]


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.

> 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.

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.

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.

> 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.

 Tomi

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel