If there are no objections I would push this soon.
- Rebase on master
- Use packaged dma-buf xml
Wed, Jul 10
A relevant link on future work on app identification.
One thing I'd like to ensure is that any additional security measures provided by Wayland are not detrimental to the user experience, because security that burdens and annoys the user will eventually irritate them into finding a way to bypass it, or just make them stop using the software out of frustration (and if they have to use it because it's employer or school provided, they will grow to hate it).
Tue, Jul 9
Sat, Jun 29
Thu, Jun 27
Tue, Jun 25
- D-pointer DmaBufBuffer
- Only allow one create request in any case
- Params in private interface class
- typedef for LinuxDmabufUnstableV1Interface
- Small cleanup
- Set buffer privates and delete impl on interface destroy
Mon, Jun 24
Since direct scanout or sampling can be done interchangeable at any point in time send the formats + modifiers in both results (intersection).
Regarding our rendering APIs:
This makes only sense when using OpenGl/EGL, not with QPainter.
Some good overview on what we need to do is given here: https://www.x.org/wiki/Events/XDC2017/widawsky_fb_modifiers.pdf
Sun, Jun 23
- Update protocol xml to wayland-protocols master
Sat, Jun 22
- Minor style changes
- Revert drm_fourcc.h whitespace changes
Rebase on master.
Thanks @fredrik for initiating this. I'll try to finish the patches up.
Jun 16 2019
Jun 14 2019
Mistakenly moved the task to Done on Plasma on Wayland board? The task is not yet fully done.
Jun 7 2019
Jun 6 2019
Jun 3 2019
May 8 2019
Sure, they need to use the "window geometry". That doesn't really have a huge impact on anything though.
The difference of opinion is do we write code patching rendering and input or write code patching the window management.
Currently I see three distinct geometries: the one that used in window management operations (e.g. resize, move, etc), input geometry, and render geometry (used during rendering operations to build window quads, etc).
As I said previously, I'd prefer a solution where Toplevel::geometry() is logical geometry of the client. This way we don't have to adjust lots of code and if we implement this in more or less "generic" way then it should be quite easy to add support for a bit controversial _GTK_FRAME_EXTENTS (distros could patch kwin for example). xdg-surface::set_window_geometry and _GTK_FRAME_EXTENTS look quite similar, except that the former provides us absolute values.
May 4 2019
On re-reading I didn't give a very good rationale of why I suggest this approach as opposed to the obvious other solution.
Apr 30 2019
Apr 5 2019
Apr 2 2019
Mar 5 2019
Feb 19 2019
This is wanted for KDE Connect too
KDE Connect needs something like that for the clipboard plugin too.
<Sho_> bshah: since there's no takers, i suggest you commandeer the revisions and finish them to the comments
<bshah> Okay, cool
Feb 5 2019
Feb 4 2019
Jan 16 2019
Jan 12 2019
Allow the creation of virtual screens in KWin.
There's supposedly some new keyboard applet coming