This is marked as resolved but I would also like to be looped in on how the mapping tablets to outputs effort goes as I am writing user-space drivers for a few tablets that get picked up by libinput.

• per-display
• KWin needs to support color management
• WIP color-management-unstable protocol: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
• colord is already used to upload calibration curves.
• colord-kde kcm needs working on, it should be able to callibrate displays too. See displaycal.
• HDR: yes, please. See https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

+1 please ping me, I'll be around.

I will be joining too. I used to work under wayland, with a functional Gnome 3 environment before migrating to KDE Plasma. I also worked with Linux Wacom project on some tricky bugs so I might be able to provide some useful info.

In T14971#265318, @woltherav wrote:

Note that neither @rempt nor @dkazakov are available this week. However, given that both are a little preoccupied with getting Krita 5 ready, perhaps it would be most fruitful to currently have a discussion with artists and discuss what kind of setups and needs they have, before discussing tech...

Note that neither @rempt nor @dkazakov are available this week. However, given that both are a little preoccupied with getting Krita 5 ready, perhaps it would be most fruitful to currently have a discussion with artists and discuss what kind of setups and needs they have, before discussing tech...

Thank you for starting this thread.

New PR: https://github.com/sddm/sddm/pull/1379

@davidedmundson I guess you meant https://lists.freedesktop.org/archives/wayland-devel/2016-February/027209.html

Not a revert but rather rollback of SNI part:
https://invent.kde.org/plasma/kwin/-/merge_requests/560

We are going to revert this in favor of https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/181:
it supports all the existing functional here plus missing one (problem with short layout names was solved):

• flags and/or short text for the layouts

If any objections, please tell.

see generic point

Is there a way to implement an "emulation" for applications that don't explicit support said back functionality?

Alright some notes from discussions:
There are 2 ways we can approach this: generic (sending mouse back events) and powerful (have a dedicated API for it)
There are pros and cons to each method
Generic:

• Pros: simple, doesn't require anything from app developers
• Cons: not extensible, won't work consistently with different apps, could lead to a poor experience nullifying the point

Powerful(API):

• Pros: Extensible, reliable, consistent
• Cons: Requires an implementation from developers (although gives users a good experience), not all apps will be supported

The patch has landed :
https://invent.kde.org/plasma/kwayland-server/-/merge_requests/15
https://invent.kde.org/plasma/kwin/-/merge_requests/27

Great. Thanks for the follow up.

I am. Patch is complete will upload soon.

In T11601#231487, @kleag wrote:

I see that @gladhorn has not commited since last september. Is anyone still working on this feature? @romangg , any insights on that subject?

I see that @gladhorn has not commited since last september. Is anyone still working on this feature? @romangg , any insights on that subject?

For the record, here is a link to the protocol in Qt 5.15 documentation :
https://doc.qt.io/qt-5/qtwaylandcompositor-attribution-wayland-primary-selection-protocol.html

The biggest problem with sharing the dmabuf buffers it that its memory management becomes quite complex (and I'm unsure it's really doable).
PipeWire has mechanisms to create the buffers it's going to need, juggling this with passing the buffer from the app/output and making sure it stays relevant feels messy and error-prone.
Copying from dmabuf->dmabuf shouldn't be very expensive though, as it shouldn't go through the buses (AFAIK, that is).

Oh, that's a good compromise given I'll want it anyway.

I wouldn't have a big problem with merging as is, it could make sense to have QFuture<QVariant> retrieveData as is. It would make it easier to time out when a client is being shitty and would allow to parallelize different queries.

That's now all done. Pending merge after 5.19 forks.

BTW, GDM seems already run so :)

It's also worth to have a look at libweston/input.c.

In T13060#228606, @apol wrote:

Sure, but this is not what this ticket is about.

Sure, but this is not what this ticket is about.

In T13060#228603, @apol wrote:

There's the org.kde.plasma.colorpicker that does this.

It's using dbus:

- snip -

Maybe it would be easier if you explained what you're trying to achieve?

There's the org.kde.plasma.colorpicker that does this.

The hard part is the seat handling.

_net_wm_sync_request is the best what we've got, unfortunately.

I would recommend to create an overview where XTime is actually used in KWin and how other compositors deal with it. Then try to create a theoretic solution and present that.

In T4424#227988, @meven wrote:

In T4424#227987, @romangg wrote:

Please confirm if that still stands.

Do you mean with regards to your patch in D28674? Tbh I don't know what it means and why updateXTime is important to have for XWayland. Is it only for net_wm_sync to have well synced X11/XWayland window resize?

Yes, mostly

Or are there other issues with the non-updated XTime?

And to prevent the bug of xtime wrapping every 49 days.
But this could be solved some other way as well, if we used CLOCK_MONOTONIC as base for our xtime for instance.

In T4424#227987, @romangg wrote:

Please confirm if that still stands.

Do you mean with regards to your patch in D28674? Tbh I don't know what it means and why updateXTime is important to have for XWayland. Is it only for net_wm_sync to have well synced X11/XWayland window resize?

Please confirm if that still stands.

Since https://gitlab.freedesktop.org/xorg/xserver/commit/a779fda224bee0c4d27636503367e55ae93b33c2
XWayland uses the CLOCK_MONOTONIC that should help.

Let me add in some background context.

In T12863#225186, @apol wrote:

Obviously, this would mean higher CPU usage, but it's better than nothing.

Higher CPU usage than what? no casting?

Obviously, this would mean higher CPU usage, but it's better than nothing.

I think a better (and simpler?) way to implement window thumbnails would be to re-use PipeWire screen/window capture functionality. T12863

I believe a simple protocol like this would be all that is necessary for the global menu applet and similar things to function:

I tested this some more and it seems to actually work fine and the issue I saw was only with one specific monitor that does not disconnect correctly when switching off, which is then not a software issue.

Important for Hans' recent work on XWayland: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/270

Have in mind that there are hotplugable GPU, e.g. Displaylink