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.