In T10462#176648, @nicolasfella wrote:

What's missing here is the Tablet use-case since I'm not sure if Phone and Tablet are just the same thing or should be treated as separate patterns.

That depends a bit on your definition of Tablet.

A 7'' tablet is not much different than a phone, but a larger tablet with an attachable keyboard is a very different device

In D18570#415752, @davidedmundson wrote:

In this case it seems better to me to not write the EGLStreams support directly into the DRM Backend at all, but create a new EGLStream Backend on same level as DRM Backend. Th

That sounds pointless.
There's less of a difference between EGL streams and GBM than there is between GBM and QPainter.

Other aspect which is important to me long-term: is multi-GPU support of different vendors possible with the current patches or a separate backend? Current patches don't seem to allow that easily to add later on. Depending on DRM access in a separate backend it might be simpler to do later.

In T10502#176649, @nicolasfella wrote:

For a large tablet a 3x2 split is also thinkable. What changes with the number of splits is the way they are controlled.

Right, but how is the way changed?

Other cases where the window geometry on the phone changes is when the screen is rotated or the virtual keyboard is pushing the window like @mart proposed

In D18570#412443, @ekurzinger wrote:

In D18570#408853, @romangg wrote:

First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard?

I'm really not happy, that the DrmOutput::present is not run and we have to export these internals from DrmOutput to the EglStreamBackend, which replaces the flip with an EGL function call. Why does the Nvidia driver not integrate with the libdrm API in regards to page flipping? It should be possible to at least offer a wrapper around it or not?

Well, our DRM-KMS driver technically does support atomic modesetting, however currently we only allow the presentation of GPU-accessible buffers through the EGLDevice / EGLOutput extensions. In fact, these use atomic modesetting capabilities in their implementation. As far as I know this will remain the case until work on the Unix device memory allocation library is complete and while this is still on the table it's a ways off yet. The new backend really just uses DrmOutputs to track whether a page flip is pending. If we don't want to expose these internals, an alternative might be to track this separately from DrmOutput::m_pageFlipPending and maybe install a different page flip handler when using EGL streams that would just clear this flag (and re-start the compositor). I'll see if I can get something like that thrown together, it might be a bit cleaner, actually.

FYI there is previous discussion in T9780 in regards to touch window resize/move. The goal must be that whatever is he result here is usable in all IOUPs with primary or additional touch input. Therefore let us continue discussion there.

True. Anyway I'm not sure if changing the scale is something we want or if the KWin internal scale should really only be influenced by the resolution/size in a uniform way over all devices.

Because of the low to middle viewing distance and primary input device being keyboard and mouse the window border size can be "None" till "Normal". Currently it's "Normal" per default I believe but there was some discussion to set it to "None" in the past. Another topic is the buttons sizes, which is independent of this value.

I've created some sub-tasks to discuss definition of some common usage patterns we might want to concentrate first: Desktop, Phone, TV.

In T10462#175716, @dcz-purism wrote:

...
That's not quite right, there are many cases when the usage patterns change, but the output doesn't. Some examples:

• tablet has a keyboard attached,
• convertible switches modes,
• a gamer picks up a controller and moves from the keyboard chair to a couch farther away.

That's true. So the Wayland event message must be sent also on these hot-plug events or when the user does a manual override, what maybe warrants a separate protocol.

In T10502#176600, @nicolasfella wrote:

Window geometry can not be changed

Android has a split screen mode where two windows are tiled. In this case this assumption would not be true.

ping

The problem is not so easy to solve I believe now and needs a more holistic approach. Let's go back to the drawing board.

I only saw this commit now through other review.

One thing we should keep in mind: at some point we want multi-screen support on Plasma Mobile / convergence. For that we will probably just use KScreen as well.

In D18810#410749, @bshah wrote:

21:01 <bshah> current kwinwrapper script is used for both normal drm and normal hwcomposer supported devices
21:01 <bshah> I can't just pass a random scale argument to call of kwin_wayland

In D18818#409260, @graesslin wrote:

I'll outline an idea how this could work: When virtual keyboard opens the focused window gets maximized and the virtual keyboard acts like a panel with strut - but just for the active window. Then we could use existing KWin functionality without having to track the geometry again.

First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard?

Impressive. Some small issues to resolve.

There are some open questions still:

• How to deal with desktop containments in a sensible way. With this patch applets and the launcher are moved above the virtual keyboard, which is already a great improvement. But we might want to deal with them in a more nicer way.
• Doe we want to expose the virtual keyboard position information somehow to the clients? The old text-input v2 protocol provided this information. We might want to let clients opt-in to not being size-changed, but placing the keyboard into their window instead at some proposed coordinates. I could imagine this could be nice on larger screens with multiple windows open. But this would need a text-input v4 protocol version or a separate protocol.
• Talking about multiple windows open: currently only the input focus window is moved. What's with other windows? I might be interested in them as well on a large screen while typing into the focused window.

In T10462#175694, @davidedmundson wrote:

Define a Wayland protocol to inform interested clients per surface, when this surface changes output.

wl_surface already has a protocol to informs clients when their surface changes output. It supports a surface being on N at once.
It should work right now.

From the sounds of it we just want to decorate either the wl_output/xdg_output/kde_output with some extra semantic values. Should be doable.

In D18810#407892, @davidedmundson wrote:

I can do, but I'll explain my rationale for this first.

When running nested it tends to be the user typing "kwin_wayland --scale" directly into a terminal.
On deployment it's hidden behind the startplasmamobile script.

Superseded by D17122.

Code looks fine. Scrolling through the git history, as Vlad said, the prefix should be [platforms/hwcomposer].

Context is missing. Do git diff -U 99999 to include it.

Let's test it on master then.

• Use QPainter render hint
• Remove ceil scale deduction
• rename Xwl arg according to fdo merge request change

In D18453#398379, @davidedmundson wrote:

romangg added a dependent revision: D18465: [platforms/wayland] Multi output support.

They don't seem dependent.

In D18452#398123, @graesslin wrote:

Cool stuff! I assume you want to push together with a patch fixing this?