Re: Discrepancies in object IDs printed by $WAYLAND_DEBUG output

[Derek Foreman]

On 2021-08-25 3:08 p.m., Hoosier, Matt wrote:
I observe that the IDs used to denote some wl_buffer protocol objects 
created by a server-side factory in the $WAYLAND_DEBUG trace, differ 
between the moment they're first announced in the callback event and 
the later use-sites when the objects are passed to subsequent Wayland 
protocol method invocations.



This happens because internally the id is replaced with a pointer to the 
object for the next steps in event queuing, and the debug printing code 
runs too late to see the original ids.



This is a timely complaint, as I wrote a patch for this just yesterday:

https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/172


Thanks,

Derek


For example, using weston-simple-dmabuf-egl normally uses 
"non-immediate" allocation of wl_buffers through the 
zwp_linux_dmabuf_v1 protocol extension. One distinguishing feature of 
this non-immediate technique is that the ID of the newly-built 
protocol object is not known at the time the method to request 
creation is made. The compositor is expected to supply it later in an 
asynchronous event.


This all works fine, but I notice in the log output that the ID of the 
newly built object is different at point it's first announced to the 
client:


[2902569.971]  -> 
zwp_linux_explicit_synchronization_v1@6.get_synchronization(new id 
zwp_linux_surface_synchronization_v1@10, wl_surface@3)
[2902570.062]  -> zwp_linux_dmabuf_v1@5.create_params(new id 
zwp_linux_buffer_params_v1@11)
[2902570.076]  -> zwp_linux_buffer_params...@11.add(fd 8, 0, 0, 1024, 
16777216, 2)
[2902570.095]  -> zwp_linux_buffer_params_v1@11.create(256, 256, 
875713112, 1)
[2902572.072]  -> zwp_linux_dmabuf_v1@5.create_params(new id 
zwp_linux_buffer_params_v1@12)
[2902572.105]  -> zwp_linux_buffer_params...@12.add(fd 10, 0, 0, 1024, 
16777216, 2)
[2902572.124]  -> zwp_linux_buffer_params_v1@12.create(256, 256, 
875713112, 1)
[2902572.240]  -> zwp_linux_dmabuf_v1@5.create_params(new id 
zwp_linux_buffer_params_v1@13)
[2902572.249]  -> zwp_linux_buffer_params...@13.add(fd 12, 0, 0, 1024, 
16777216, 2)
[2902572.262]  -> zwp_linux_buffer_params_v1@13.create(256, 256, 
875713112, 1)

...
[2902576.893] zwp_linux_buffer_params_v1@11.created(new id 
wl_buffer@2372643520)

[2902576.901]  -> zwp_linux_buffer_params_v1@11.destroy()
[2902576.906] zwp_linux_buffer_params_v1@12.created(new id 
wl_buffer@2372643856)

[2902576.913]  -> zwp_linux_buffer_params_v1@12.destroy()
[2902576.918] zwp_linux_buffer_params_v1@13.created(new id 
wl_buffer@2372644240)

[2902576.924]  -> zwp_linux_buffer_params_v1@13.destroy()

So, here are the ID's of the buffers built using the non-immediate mode:

  * wl_buffer@2372643520 (0x8d6baac0)
  * wl_buffer@2372643856 (0x8d6bac10)
  * wl_buffer@2372644240 (0x8d6bad90)


These ID's look suspicious to begin with. They do not have ID's in the 
usual range of server-allocated object ID's (these are supposed 
to begin at 0xff00).


But then later when the application uses these objects as parameter to 
subsequent requests, the ID's are printed differently:


    [2902577.702]  -> wl_surface@3.attach(wl_buffer@4278190080, 0, 0)
    ...
    [3183676.812]  -> wl_surface@3.attach(wl_buffer@4278190081, 0, 0)
    ...

So here, those are:

  * wl_buffer@4278190080 (0xff00)
  * wl_buffer@4278190081 (0xff01)



Those ID's are in the expected range for server-allocated protocol 
objects. Despite this discrepancy, the application clearly works fine; 
the right contents appear on-screen.


Is there some quirk that causes object ID's passed as parameters to 
events to be mis-printed?


-Matt

Re: Stepping down as release manager

[Derek Foreman]

On Mon, 8 Apr 2019 at 05:54, Daniel Stone  wrote:
>
> Hi,
>
> On Mon, 8 Apr 2019 at 11:02, Pekka Paalanen  wrote:
> > On Fri, 05 Apr 2019 18:01:45 + Simon Ser  wrote:
> > > Regarding the need for a new release manager for Wayland, I'd like to
> > > step in and volunteer for this role. I'm willing to take the time
> > > necessary to (1) learn the current release process and (2) apply it if
> > > the community is interested.
> >
> > I would be happy to have you. Let's see till Friday if anyone else has
> > anything to say.
>
> Yeah, I'd certainly be very happy with this as well.

As would I.

Thanks,
Derek

> > We are currently in a transition phase with Weston's Meson build,
> > autotools being just removed, so there are some tasks I think would be
> > good to do:
> >
> > - Copy releasing.txt from Weston to Wayland, since it documents the
> >   autotools release process and Wayland still uses that.
> >
> > - Streamline Wayland's releasing.txt, there are bits that only ever
> >   applied to Weston.
> >
> > - Figure out the new releasing process with Meson and document in
> >   Weston's releasing.txt. We've never done a release from Meson before.
>
> It would also be awesome to revive the work on GitLab CI: moving
> Wayland to the same CI templates that Weston/libinput/etc use,
> enabling 32-bit builds as well as ASan/MSan/UBSan builds ...
>
> > We should also decide when the next releases will be, and check which
> > things to prioritise for the next Wayland and Weston releases (this is
> > where we/I have traditionally sucked). ISTR Derek already announced
> > that Wayland and Weston do not necessarily release in sync anymore,
> > Wayland having settled down while Weston having lots of on-going work.
> > There is a lot of CI-related work on my and others' plates that is
> > probably a first priority for both projects.
> >
> > The (acting) release manager has practically had a minor exempt from
> > the "everything must be reviewed" rule in that he can push release
> > related version bumps directly and update the web site with releases.
>
> Indeed. I think documenting the release process and schedule is
> probably a good place to start though. :) Similarly we need to figure
> out the same for Weston, but as noted, there's no reason to keep on
> tying those two together anymore.
>
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Stepping down as release manager

[Derek Foreman]

Hi everyone,

I no longer have as much time to dedicate to this as I used to, so I
think it would be best if someone else could take over managing the
releases for Weston and Wayland.

Thanks for the opportunity to help out,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 6.0.0

[Derek Foreman]

Weston 6.0 is released with only a trivial build change since RC2.

Derek Foreman (1):
  configure.ac/meson.build: bump version to 6.0.0 for the official release

Marius Vlad (1):
  autotools: Fix tags/cscope targets with autools

git tag: 6.0.0

https://wayland.freedesktop.org/releases/weston-6.0.0.tar.xz
MD5:  7c634e262f8a464a076c97fd50ad36b3  weston-6.0.0.tar.xz
SHA1: feac9d9a77037580f39c0085a08a3c17a62dced0  weston-6.0.0.tar.xz
SHA256: 546323a90607b3bd7f48809ea9d76e64cd09718102f2deca6d95aa59a882e612
 weston-6.0.0.tar.xz
SHA512: 
127ab64b689f202acca4d9461e4decfd42357e4bbb63493af257b3b20b693a8ab4207b3c6b97663cefeed200505aad5f32b6a064db2e53fa1e201877613b394f
 weston-6.0.0.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-6.0.0.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.17.0

[Derek Foreman]

Wayland 1.17 is released, with no changes (except the version) since RC1.


Derek Foreman (1):
  configure.ac: bump to version 1.17.0 for the official release

git tag: 1.17.0

https://wayland.freedesktop.org/releases/wayland-1.17.0.tar.xz
MD5:  d91f970aea11fd549eae023d06f91af3  wayland-1.17.0.tar.xz
SHA1: 4d9e08a7a4a07fa37a25d7aa3ef83f08edec0600  wayland-1.17.0.tar.xz
SHA256: 72aa11b8ac6e22f4777302c9251e8fec7655dc22f9d94ee676c6b276f95f91a4
 wayland-1.17.0.tar.xz
SHA512: 
c5051aab5ff078b368c196ecfedb33ccd961265bb914845d7ed81de361bb86ae18299575baa6c4eceb0d82cf8b495e8293f31b51d1cbc05d84af0a199ab3f946
 wayland-1.17.0.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.17.0.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 5.0.94

[Derek Foreman]

This is the RC2 release for weston 6.0.

There's a fix for a bug in the meson build.  Since the plan is to drop
meson shortly after 6.0 is released, it's critical that autotools and
meson both build properly, so an RC2 is in order.

Perhaps a full release next Wednesday.

Changelog follows:

Derek Foreman (1):
  configure.ac/meson.build: bump to version 5.0.94 for the RC2 release

Stefan Agner (1):
  meson: fix building screen-share module

git tag: 5.0.94

https://wayland.freedesktop.org/releases/weston-5.0.94.tar.xz
MD5:  50b9a98ba1550314e258a34103e5bbd4  weston-5.0.94.tar.xz
SHA1: 014ef01fbfda1dc63fc0aac7db184436abec848a  weston-5.0.94.tar.xz
SHA256: 22243d99446b1e841b840257bbcbe9887ef2ab8b3fdda9684516d726913e7729
 weston-5.0.94.tar.xz
SHA512: 
daafd16c8e7993b96c7745adea10029501a3b0273f6564f38feaee9d5a27e7555902ffca388fa261fcab486012cf95a9632d7535f85181b51ddf262e7b717e8b
 weston-5.0.94.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-5.0.94.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.16.93

[Derek Foreman]

This is the first release candidate for the upcoming 1.17 release.

Sorry I missed the intended release date yesterday, the following
releases will be pushed back a day as well.

Changelog follows:

Chris Billington (1):
  wayland-util.h: add forward declaration for wl_object

Derek Foreman (1):
  configure.ac: bump version to 1.16.93 for the RC1 release

Pekka Paalanen (3):
  contributing: use Gitlab merge request workflow
  tests: add request_bogus_size
  connection: fix demarshal of invalid header

git tag: 1.16.93

https://wayland.freedesktop.org/releases/wayland-1.16.93.tar.xz
MD5:  5616385df8aaeb4bcbe50c015164b03b  wayland-1.16.93.tar.xz
SHA1: 7951873d5d58228e8d6511fe8223990c79d45f80  wayland-1.16.93.tar.xz
SHA256: a610dd8ffaa854932e1088f8c866289874fe47225c02adbc5a304319ca7c3609
 wayland-1.16.93.tar.xz
SHA512: 
99f34923bcea189b3485dd8f36773a9f1b98fb6cc76a63c64b4711d31435a8dd8e5cc812e63e16f1563938784b626d359886967c1e490dadfdd88a44bc1f5dff
 wayland-1.16.93.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.16.93.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 5.0.93

[Derek Foreman]

This is the first release candidate for the upcoming 6.0 release.

Sorry I missed the intended release date yesterday, the following
releases will be pushed back a day as well.

Changelog follows:

Derek Foreman (1):
  configure.ac: bump version to 5.0.93 for the RC1 release

Philipp Zabel (2):
  meson: allow to build weston-simple-dmabuf-egl
  compositor-drm: clear gbm_surface pointer after destroying the GBM surface

git tag: 5.0.93

https://wayland.freedesktop.org/releases/weston-5.0.93.tar.xz
MD5:  98d21d687835330a31b040e3f92e9214  weston-5.0.93.tar.xz
SHA1: 275ebe6911c6fa53a8b8b043dd79adbe4d3dc2ca  weston-5.0.93.tar.xz
SHA256: acb7d089acfed75f71b6f977bdebe2f979e220b8197b165b86141a6808f6309d
 weston-5.0.93.tar.xz
SHA512: 
cea65a444e551d24885b5d2718158a67472fdb158f9750d5df0f53bef15513d885117064d9ee7a26e677a269249d16233d010f9ae201c46b82b4cdffa8bfa70c
 weston-5.0.93.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-5.0.93.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EXT: Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

[Derek Foreman]

On Wed, 6 Mar 2019 at 04:49, Ray, Ian (GE Healthcare)  wrote:
>
>
>
> > On 6 Mar 2019, at 11.28, Pekka Paalanen  wrote:
> >
> > Going once, going twice...
> >
> > Any objections? More acks?

Acked-by: Derek Foreman 

Personally, I really see no harm in pushing this during code freeze,
since it's not code. :)

Thanks,
Derek

> >
> > Let's say I'll push this and enable MRs on Friday if there are no
> > further comments. More acks and I might do it sooner. :-)
> >
> >
>
> LGTM
>
> Acked-by: Ian Ray 
>
>
> > Thanks,
> > pq
> >
> >
> > On Wed, 27 Feb 2019 12:35:09 +0200
> > Pekka Paalanen  wrote:
> >
> >> From: Pekka Paalanen 
> >>
> >> The experience from Weston shows that the Gitlab merge request based 
> >> workflow
> >> works really well. Recently there have also been issues with the mailing 
> >> list
> >> that have made the email based workflow more painful than it used to be. 
> >> Those
> >> issues might have been temporary or occasional, but they probably are only
> >> going to increase.
> >>
> >> The MR workflow is different, it has its issues
> >> (https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/74) and we
> >> likely lose the explicit Reviewed-by etc. tags from commit messages, but 
> >> it is
> >> also much easier to work with: no more whitespace damaged patches, lost 
> >> email,
> >> setting up git-send-email; we gain automated CI before any human reviewer 
> >> even
> >> looks at anything, and people can jump in to an ongoing discussion even if 
> >> they
> >> weren't subscribed before.
> >>
> >> If you still want email, you can subscribe to that selectively(!) in Gitlab
> >> yourself.
> >>
> >> This text has been copied from Weston's CONTRIBUTING.md of the 5.0.91 
> >> release
> >> and slightly altered for Wayland.
> >>
> >> Fixes: https://gitlab.freedesktop.org/wayland/wayland/issues/49
> >>
> >> v2: fixed two left-over mentions of Weston
> >>
> >> Signed-off-by: Pekka Paalanen 
> >> v1 Reviewed-by: Simon Ser 
> >> Reviewed-by: Daniel Stone 
> >> ---
> >> CONTRIBUTING.md | 147 
> >> 1 file changed, 72 insertions(+), 75 deletions(-)
> >>
> >> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
> >> index 686ed63..dcc9f56 100644
> >> --- a/CONTRIBUTING.md
> >> +++ b/CONTRIBUTING.md
> >> @@ -4,8 +4,46 @@ Contributing to Wayland
> >> Sending patches
> >> ---
> >>
> >> -Patches should be sent to **wayland-devel@lists.freedesktop.org**, using
> >> -`git send-email`. See [git documentation] for help.
> >> +Patches should be sent via
> >> +[GitLab merge 
> >> requests](https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html).
> >> +Wayland is
> >> +[hosted on freedesktop.org's 
> >> GitLab](https://gitlab.freedesktop.org/wayland/wayland/):
> >> +in order to submit code, you should create an account on this GitLab 
> >> instance,
> >> +fork the core Wayland repository, push your changes to a branch in your 
> >> new
> >> +repository, and then submit these patches for review through a merge 
> >> request.
> >> +
> >> +Wayland formerly accepted patches via `git-send-email`, sent to
> >> +**wayland-devel@lists.freedesktop.org**; these were
> >> +[tracked using 
> >> Patchwork](https://patchwork.freedesktop.org/project/wayland/).
> >> +Some old patches continue to be sent this way, and we may accept small new
> >> +patches sent to the list, but please send all new patches through GitLab 
> >> merge
> >> +requests.
> >> +
> >> +
> >> +Formatting and separating commits
> >> +-
> >> +
> >> +Unlike many projects using GitHub and GitLab, Wayland has a
> >> +[linear, 'recipe' style 
> >> history](http://www.bitsnbites.eu/git-history-work-log-vs-recipe/).
> >> +This means that every commit should be small, digestible, stand-alone, and
> >> +functional. Rather than a purely chronological commit history like this:
> >> +
> >> +connection: plug a fd leak
> >> +plug another fd leak
> >> +connection: init fds to -1
> >> +close all fds
> >> +refactor checks into a new function
> >&g

[ANNOUNCE] wayland 1.16.92

[Derek Foreman]

This is the beta for the upcoming 1.17 release.

Changelog:
Derek Foreman (1):
  configure.ac: bump to version 1.16.92 for the beta release

Leonid Bobrov via wayland-devel (1):
  tests: fix main symbol duplication

Simon Ser (1):
  protocol: warn clients about some wl_output properties

git tag: 1.16.92

https://wayland.freedesktop.org/releases/wayland-1.16.92.tar.xz
MD5:  47b83f7b18795be0f69ee135e515566e  wayland-1.16.92.tar.xz
SHA1: 18d03c349c4737f3b77acde05db29b8611047cbd  wayland-1.16.92.tar.xz
SHA256: 18fd76c0f4fc21e14225a8fd03c89619e77751fb19b417c66cb7477d10be0660
 wayland-1.16.92.tar.xz
SHA512: 
d28eba0b9f4162378df08e59efe0aa099603942732735b09b5811700b5d5e130314833b5bd0604d4be5c1b89bb2b6a1e86dc14520703f73fd4c3a5cc7fab3ea2
 wayland-1.16.92.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.16.92.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 5.0.92

[Derek Foreman]

Here's the beta for the upcoming weston 6.0 release.  Mostly bug/typo
fixes here, as should be the case at this point in the cycle.

Changelog:
Alexandros Frantzis (1):
  clients/simple-dmabuf-egl: Create the EGL display using the GBM platform

Daniel Stone (1):
  compositor-drm: Add missing newline to debug print

Derek Foreman (1):
  configure.ac: bump to version 5.0.92 for the beta release

Emmanuel Gil Peyrot (1):
  Fix typos all around (thanks codespell!)

Philipp Zabel (1):
  compositor-drm: fix gbm_bo_get_handle_for_plane error handling

git tag: 5.0.92

https://wayland.freedesktop.org/releases/weston-5.0.92.tar.xz
MD5:  1409f3b4fa87cf72ec5dc0e1e2c6957c  weston-5.0.92.tar.xz
SHA1: 981b39d23d30a0c417f031df30306b67808819ed  weston-5.0.92.tar.xz
SHA256: 89b804a10f331c2933a8b5c3eaf1427cc94ca7743521836b2f5046e46c7fe1d8
 weston-5.0.92.tar.xz
SHA512: 
3d19e5f0e0470288793ff2608f340b20750ee03835fd29e482790cbdcde74335615dd05c59ebd202d47f0280dc101d8408ceb920d278dabd7e5a54eb85f27078
 weston-5.0.92.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-5.0.92.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] weston 5.0.91

[Derek Foreman]

Hello,

Yes, something is wrong with CI for the web repository.  It's constantly
failing and refusing to deploy the new changes (updates to the release page
and the tarballs referenced in the release emails)

Hopefully resolved soon. :(

Thanks,
Derek

On Wed, 20 Feb 2019 at 06:03, Marius Vlad  wrote:

> Hi,
>
> FYI, The links at the end all give 404. Releases page is missing alpha
> version entry as well.
>
> On 2/19/19 10:15 PM, Derek Foreman wrote:
> > This is the alpha release for weston 6.0.  A lot has happened for this
> > release, some big items to note are:
> > We now have xdg-shell stable support!
> >
> > We've moved to meson as our primary build system and have deprecated the
> > autotools build entirely.  You need to run configure with
> > --enable-autotools to use autotools, and we will be removing autotools
> > after the 6.0 release.
> >
> > Full commit history follows:
> >
> > Alexandros Frantzis (11):
> >   xwayland: Silence format-truncation compilation warnings
> >   clients: Add simple-dmabuf-egl
> >   clients/simple-dmabuf-egl: Support dmabuf format modifiers
> >   clients/simple-dmabuf-egl: Render a moving square
> >   libweston: Introduce zwp_linux_explicit_synchronization_v1
> >   libweston: Introduce an internal linux sync file API
> >   libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
> >   libweston: Support zwp_surface_synchronization_v1.get_release
> >   tests: Add tests for per commit zwp_buffer_release_v1 behavior
> >   clients: Support explicit synchronization in simple-dmabuf-egl
> >   clients: Add a mandelbrot set shader to simple-dmabuf-egl
> >
> > Arkadiusz Hiler (1):
> >   compositor-drm: Log atomic commits and flips
> >
> > Changwoo Cho (1):
> >   libweston: fix typo in comment
> >
> > Daniel Stone (14):
> >   CONTRIBUTING: How do I get started?
> >   compositor: Add weston_layer_mask_is_infinite
> >   compositor: Add scene-graph debug scope
> >   compositor-drm: Calculate atomic-commit flags earlier
> >   compositor-drm: Add backend pointer to drm_output
> >   compositor-drm: Add drm-backend log debug scope
> >   gl-renderer: Remove warning on missing extensions
> >   compositor-drm: Don't warn about missing backlight control
> >   tests: Rename surface-screenshot
> >   tests: fix include in input-timestamps-helper.c
> >   Add Meson build system
> >   CI: Add Meson build
> >   gitlab-ci: Actually capture Meson logs
> >   compositor-drm: Fall back if GBM surface fails with modifiers
> >
> > David Fort (1):
> >   rdp-compositor: fix compilation with FreeRDP 2.0-rc4
> >
> > Deepak Rawat (1):
> >   compositor-drm: Read FB2_MODIFIERS capability
> >
> > Derek Foreman (2):
> >   configure.ac: Reopen master for regular development
> >   configure.ac: bump to version 5.0.91 for the alpha release
> >
> > Dima Ryazanov (4):
> >   Don't look for weston.ini in the current working directory
> >   Revert "Fix a crash when unlocking or unconfining a pointer"
> >   clients: Delete an unused variable
> >   clients: A better fix for a crash when unlocking or unconfining a
> > pointer
> >
> > Emil Velikov (2):
> >   libweston: split EGL and GL info logging
> >   libweston: print EGL information as early as possible
> >
> > Emmanuel Gil Peyrot (1):
> >   ivi-shell: Add missing sentence point
> >
> > Emre Ucan (7):
> >   ivi-shell: Add build_view_list function
> >   ivi-shell: unmap views which are not in scenegraph
> >   ivi-shell: check ivi_view mappedness in commit_changes()
> >   ivi-shell: don't use input panel implementation
> >   ivi-shell: remove input panel implementation
> >   ivi-shell: remove unused functions and members
> >   ivi-shell: remove input-method section from config
> >
> > Eric Engestrom (2):
> >   meson: fix -Wno-foo argument testing
> >   Revert "meson: fix -Wno-foo argument testing"
> >
> > Eric Toombs (3):
> >   man: fix small typo: directroy
> >   weston: deprecate enable_tap in favour of enable-tap
> >   weston: add more libinput config options
> >
> > Greg V (8):
> >   build: use pkg-config to find libjpeg in meson
> >   build: use '-Wl,' wrapper for the -export-dynamic linker flag
> >   build: add missing wayland-client dep in meson
> >   de

[ANNOUNCE] weston 5.0.91

[Derek Foreman]

This is the alpha release for weston 6.0.  A lot has happened for this
release, some big items to note are:
We now have xdg-shell stable support!

We've moved to meson as our primary build system and have deprecated the
autotools build entirely.  You need to run configure with
--enable-autotools to use autotools, and we will be removing autotools
after the 6.0 release.

Full commit history follows:

Alexandros Frantzis (11):
  xwayland: Silence format-truncation compilation warnings
  clients: Add simple-dmabuf-egl
  clients/simple-dmabuf-egl: Support dmabuf format modifiers
  clients/simple-dmabuf-egl: Render a moving square
  libweston: Introduce zwp_linux_explicit_synchronization_v1
  libweston: Introduce an internal linux sync file API
  libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
  libweston: Support zwp_surface_synchronization_v1.get_release
  tests: Add tests for per commit zwp_buffer_release_v1 behavior
  clients: Support explicit synchronization in simple-dmabuf-egl
  clients: Add a mandelbrot set shader to simple-dmabuf-egl

Arkadiusz Hiler (1):
  compositor-drm: Log atomic commits and flips

Changwoo Cho (1):
  libweston: fix typo in comment

Daniel Stone (14):
  CONTRIBUTING: How do I get started?
  compositor: Add weston_layer_mask_is_infinite
  compositor: Add scene-graph debug scope
  compositor-drm: Calculate atomic-commit flags earlier
  compositor-drm: Add backend pointer to drm_output
  compositor-drm: Add drm-backend log debug scope
  gl-renderer: Remove warning on missing extensions
  compositor-drm: Don't warn about missing backlight control
  tests: Rename surface-screenshot
  tests: fix include in input-timestamps-helper.c
  Add Meson build system
  CI: Add Meson build
  gitlab-ci: Actually capture Meson logs
  compositor-drm: Fall back if GBM surface fails with modifiers

David Fort (1):
  rdp-compositor: fix compilation with FreeRDP 2.0-rc4

Deepak Rawat (1):
  compositor-drm: Read FB2_MODIFIERS capability

Derek Foreman (2):
  configure.ac: Reopen master for regular development
  configure.ac: bump to version 5.0.91 for the alpha release

Dima Ryazanov (4):
  Don't look for weston.ini in the current working directory
  Revert "Fix a crash when unlocking or unconfining a pointer"
  clients: Delete an unused variable
  clients: A better fix for a crash when unlocking or unconfining a
pointer

Emil Velikov (2):
  libweston: split EGL and GL info logging
  libweston: print EGL information as early as possible

Emmanuel Gil Peyrot (1):
  ivi-shell: Add missing sentence point

Emre Ucan (7):
  ivi-shell: Add build_view_list function
  ivi-shell: unmap views which are not in scenegraph
  ivi-shell: check ivi_view mappedness in commit_changes()
  ivi-shell: don't use input panel implementation
  ivi-shell: remove input panel implementation
  ivi-shell: remove unused functions and members
  ivi-shell: remove input-method section from config

Eric Engestrom (2):
  meson: fix -Wno-foo argument testing
  Revert "meson: fix -Wno-foo argument testing"

Eric Toombs (3):
  man: fix small typo: directroy
  weston: deprecate enable_tap in favour of enable-tap
  weston: add more libinput config options

Greg V (8):
  build: use pkg-config to find libjpeg in meson
  build: use '-Wl,' wrapper for the -export-dynamic linker flag
  build: add missing wayland-client dep in meson
  desktop-shell: extract view_get_transform, make it reliable
  xwayland: fix clipboard related crash
  xwm: fix resize grab related crash
  desktop-shell: fix resize grab related crash
  desktop-shell: remove surface destroy listener when focus state is
destroyed

Jonas Ã…dahl (1):
  gitlab-ci.yml: Install meson from 0.49 branch

Marius Vlad (25):
  pixel-formats: Added pixel_format_get_info_shm() helper for printing
SHM buffers
  compositor: Make pixel format printing in human-friendly form
  Fix compiler warnings generated by older toolchains/compiler
  Fix compiler warnings: clobber variables
  Fix compiler warnings: invalid type format
  Fix compiler warning: unused variable when building with DEBUG
  libweston/compositor-drm: Print composition mode in weston-debug
  libweston/compositor-drm: No need to test for invalid alpha for the
view
  libweston/compositor-drm: Add missing debug message for scanout_view
  clients/screenshot: Avoid using global variables to pass down data
between functions
  clients/screenshot: Allow weston-screenshooter to be called directly
  libweston/weston-debug: Add a easy way to determine if the debug
protocol has been enabled
  libweston: Allow taking screenshots when debug protocol is enabled
  ivi-shell/hmi-controller: Include config.h as to not break ivi-

[ANNOUNCE] wayland 1.16.91

[Derek Foreman]

This is the alpha release for wayland 1.17.

In addition to some clean-ups and bug fixes, we now have protocol to
express an internal server error message, and a new version of the wl_seat
protocol with no changes other than keymaps must be private.

Full commit history follows:

Christopher James Halse Rogers (2):
  server: Split out varargs version of wl_resource_post_error.
  proto, server: Add internal server error message. (v2)

Daniel Stone (6):
  scanner: Plug two memory leaks
  scanner: Mark fail() as noreturn
  scanner: Reverse expat/libxml include order
  tests: Use volatile pointer for NULL dereference
  tests: Overly elaborate compiler warning workaround
  tests: Remove memory leak checking infrastructure

Derek Foreman (3):
  configure.ac: Reopen master for regular development
  protocol: Bump seat to version 7 and require keymaps be private
  configure.ac: bump version to 1.16.91 for the alpha release

Eric Engestrom (1):
  TODO: remove "SDL port", it's been done by now

Simon Ser (2):
  protocol: prefer wl_surface.damage_buffer
  Print NULL strings as "nil" in wl_closure_print

git tag: 1.16.91

https://wayland.freedesktop.org/releases/wayland-1.16.91.tar.xz
MD5:  711fea532899f2de096ebafdc54d1e3f  wayland-1.16.91.tar.xz
SHA1: 35eae388ad02b42e8e5004e214ef92230afb5eaa  wayland-1.16.91.tar.xz
SHA256: d51b83a51034ed5474517e0b0bca2d4e7056e4c51d720ea885f0c34f243fee90
wayland-1.16.91.tar.xz
SHA512:
5c1a96cbe31d36386f66b9d02fce4f5eb96e93b3a602124a57966f06f1103d8fd7035a8084816c4b51f21adea4dde73f5d293295fbd7227b270ca95efa19b56f
wayland-1.16.91.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.16.91.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston/wayland release schedule

[Derek Foreman]

Hello,

Thanks everyone for the flurry of activity reviewing and landing important
patches for the release!

In agreement with Daniel's suggestion to freeze and release today, I'm
going to start rolling the alpha shortly.  Here's the final release
schedule:

Alpha: today, February 19th
Beta: March 5th
Rc1: March 12th
March 19th - first potential final release date.

Thanks,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Upcoming release

[Derek Foreman]

On 1/30/19 6:58 AM, Alexandros Frantzis wrote:
> On Fri, Jan 25, 2019 at 10:05:47AM -0600, Derek Foreman wrote:
>> On 1/18/19 4:20 PM, Derek Foreman wrote:
>>> Hi all,
>>>
>>> It's been quite some time since our last weston release, and there's
>>> been some discussion of getting the next one out in the January to March
>>> timeframe (this would be the last release to have an autotools build, btw).
>>>
>>> Does anyone have objections to an early February freeze and a March
>>> release?  Anyone with large series near completion?
>>>
>>> Also, I'd like to float the idea of removing the fbdev backend for this
>>> release (or the next).  The bulk of the interesting features target the
>>> drm backend, and it feels like fbdev can sometimes be a bit of a pain to
>>> update when changes are required elsewhere.  Any strong opinions either way?
>>
>> Ok, I've heard no complaints, and we really are overdue...
>>
>> There's been some reasonable pushback against dropping fbdev
>> immediately, so let's leave that in for this release.
>>
>> As to the release schedule, maybe:
>> February 1, Alpha
>> February 15, Beta
>> March 1, RC1
>> March 8 as a first potential final release date.
>>
>> Is this too soon to enter freeze?  It's not a lot of warning.
>>
>> Wayland has had enough changes that I think another joint release makes
>> sense.
>>
>> Thanks,
>> Derek
> 
> Hi Derek,
> 
> it would be nice if we could also try to get the weston support for the
> zwp_linux_explicit_synchronization_unstable_v1 protocol in the next
> release, given that the protocol itself has landed since some time now
> (wayland-protocols 1.17).
> 
> The MR for the explicit sync implementation is at:
> 
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/32

At this point I'm thinking at least a one week push on the proposed
release schedule.  Is that enough to get this one in?

Thanks,
Derek

> Thanks,
> Alexandros
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Upcoming release

[Derek Foreman]

On 1/30/19 6:19 AM, Pekka Paalanen wrote:
> On Mon, 28 Jan 2019 12:13:12 +0200
> Pekka Paalanen  wrote:
> 
>> On Fri, 25 Jan 2019 10:05:47 -0600
>> Derek Foreman  wrote:
>>
>>> On 1/18/19 4:20 PM, Derek Foreman wrote:  
>>>> Hi all,
>>>>
>>>> It's been quite some time since our last weston release, and there's
>>>> been some discussion of getting the next one out in the January to March
>>>> timeframe (this would be the last release to have an autotools build, btw).
>>>>
>>>> Does anyone have objections to an early February freeze and a March
>>>> release?  Anyone with large series near completion?
>>>>
>>>> Also, I'd like to float the idea of removing the fbdev backend for this
>>>> release (or the next).  The bulk of the interesting features target the
>>>> drm backend, and it feels like fbdev can sometimes be a bit of a pain to
>>>> update when changes are required elsewhere.  Any strong opinions either 
>>>> way?
>>>
>>> Ok, I've heard no complaints, and we really are overdue...
>>>
>>> There's been some reasonable pushback against dropping fbdev
>>> immediately, so let's leave that in for this release.
>>>
>>> As to the release schedule, maybe:
>>> February 1, Alpha
>>> February 15, Beta
>>> March 1, RC1
>>> March 8 as a first potential final release date.
>>>
>>> Is this too soon to enter freeze?  It's not a lot of warning.
>>>
>>> Wayland has had enough changes that I think another joint release makes
>>> sense.  
>>
>> Hi,
>>
>> here are my picks from the pending reviews. I don't mean that we should
>> wait on them unless noted explicitly below.

Thanks for putting this list together.

>> Wayland:
>>
>> I reviewed https://patchwork.freedesktop.org/series/49379/ and it needs
>> work.
>>
>> https://patchwork.freedesktop.org/series/38564/ is probably something I
>> should look into to have in the alpha.
> 
> That one landed.
> 
>>
>> Weston:
>>
>> https://gitlab.freedesktop.org/wayland/weston/merge_requests/66 is
>> something I'd like to land, but it needs a small touch.
>>
>> https://gitlab.freedesktop.org/wayland/weston/merge_requests/62 is
>> probably important enough, that I'd be willing to postpone the release
>> until we get that in. Looks like it is very close.

Jonas mentioned this one on IRC too.  Looks like it's close enough to
delay the release for, and I think everyone would really like to see it
landed.

>> Since Meson is a new thing,
>> https://gitlab.freedesktop.org/wayland/weston/merge_requests/85 would
>> probably be nice to decide on.
>>
>> Getting NEWS files would be cool too. This was just the first attempt
>> that got useful feedback but I never had the time to take it further:
>> https://patchwork.freedesktop.org/series/16218/
>>
> 
> I took a look at the Weston changes since 5.0.0 release:
> 
> - the exported symbols from weston executable have changed, backwards
>   incompatible, but this probably shouldn't count against libweston
>   major
> 
> - struct weston_head gained a new member
> 
> - struct weston_compositor gained new members
> 
> - struct weston_surface gained a new member
> 
> I guess these are reasons enough to bump the major to 6, right?
> 
> Would have been interesting to release a 5.1.0, too bad. :-)

Thanks for looking into this, as I wasn't sure yet what the new release
would be called. :)

Sounds like a 6 to me.

We'll definitely be in a holding pattern until the xdg-shell (MR 62)
stuff lands.

Thanks,
Derek

> 
> Thanks,
> pq
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Upcoming release

[Derek Foreman]

On 1/18/19 4:20 PM, Derek Foreman wrote:
> Hi all,
> 
> It's been quite some time since our last weston release, and there's
> been some discussion of getting the next one out in the January to March
> timeframe (this would be the last release to have an autotools build, btw).
> 
> Does anyone have objections to an early February freeze and a March
> release?  Anyone with large series near completion?
> 
> Also, I'd like to float the idea of removing the fbdev backend for this
> release (or the next).  The bulk of the interesting features target the
> drm backend, and it feels like fbdev can sometimes be a bit of a pain to
> update when changes are required elsewhere.  Any strong opinions either way?

Ok, I've heard no complaints, and we really are overdue...

There's been some reasonable pushback against dropping fbdev
immediately, so let's leave that in for this release.

As to the release schedule, maybe:
February 1, Alpha
February 15, Beta
March 1, RC1
March 8 as a first potential final release date.

Is this too soon to enter freeze?  It's not a lot of warning.

Wayland has had enough changes that I think another joint release makes
sense.

Thanks,
Derek

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Upcoming release

[Derek Foreman]

Hi all,

It's been quite some time since our last weston release, and there's
been some discussion of getting the next one out in the January to March
timeframe (this would be the last release to have an autotools build, btw).

Does anyone have objections to an early February freeze and a March
release?  Anyone with large series near completion?

Also, I'd like to float the idea of removing the fbdev backend for this
release (or the next).  The bulk of the interesting features target the
drm backend, and it feels like fbdev can sometimes be a bit of a pain to
update when changes are required elsewhere.  Any strong opinions either way?

Thanks,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Bump seat to version 7 and require keymaps be private

[Derek Foreman]

On 11/2/18 6:15 AM, Pekka Paalanen wrote:
> On Thu,  1 Nov 2018 11:15:46 -0500
> Derek Foreman  wrote:
> 
>> Weston commit 76829fc4eaea329d2a525c3978271e13bd76c078 (and similar
>> commits for other compositors) protects the compositor's keyboard
>> mapping from client damage by duplicating the keymap for every
>> client.
>>
>> On some systems there are other potential fixes for this - such as
>> using sealed memfds on linux - but we can't use them since
>> essentially all client code anywhere has mapped the keyboard map
>> with a MAP_SHARED mmap() call.
>>
>> While we can't break years worth of code, we can require any future
>> clients to use MAP_PRIVATE if they use a seat version above 6.
>>
>> If a compositor can't use sealing or a similar facility, it should
>> still protect itself with copied keymaps, but clients must always
>> assume shared mapping of a keymap will fail.
>>
>> Signed-off-by: Derek Foreman 
>> ---
>>  protocol/wayland.xml | 11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> Acked-by: Pekka Paalanen 

And landed now.

Thanks,
Derek

> 
> Thanks,
> pq
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] protocol: prefer wl_surface.damage_buffer

[Derek Foreman]

On 11/5/18 1:44 PM, Derek Foreman wrote:
> On 11/5/18 7:57 AM, Simon Ser wrote:
>> This commit makes wl_surface.damage_buffer preferred over wl_surface.damage.
>> wl_surface.damage can be implemented in a non-optimal way by the compositor
>> (e.g. by always damaging the whole buffer).
>>
>> Having two requests makes it complicated for the compositor to handle damage,
>> making it necessary to transform one into the other's coordinates.
>>
>> Moreover, integration with wp_viewporter is tricky.
>>
>> Signed-off-by: Simon Ser 
> 
> Obnoxious nitpick: for some reason that file uses different formatting
> than others in the repo, and 8 spaces are compressed into a single tab.
> 
> Otherwise, this is:
> Reviewed-by: Derek Foreman 

This is landed now, I changed the formatting to match the surrounding
text when I did so.

Thanks!
Derek

>> ---
>>  protocol/wayland.xml | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index 141038b..df2b6d2 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -1397,9 +1397,9 @@
>>  and clears pending damage. The server will clear the current
>>  damage as it repaints the surface.
>>  
>> -Alternatively, damage can be posted with wl_surface.damage_buffer
>> -which uses buffer coordinates instead of surface coordinates,
>> -and is probably the preferred and intuitive way of doing this.
>> +Note! New clients should not use this request. Instead damage can be
>> +posted with wl_surface.damage_buffer which uses buffer coordinates
>> +instead of surface coordinates.
>>
>>
>>
>>
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] wayland-server: update the client fd when it failed to flush with EAGAIN

[Derek Foreman]

On 11/22/18 11:08 PM, Jeonghyun Kang wrote:
> When a wayland compositor gets an EAGAIN error whenever
> sending or receiving event(s) to a client in the
> wl_closure_send() or the wl_closure_queue(), the error
> variable of the wl_client for the client will be set to
> true and the client is going to be killed by the
> compositor later soon. This patch fixes the problem by
> updating the socket fd's event mask as we're doing
> in wl_display_flush_clients() for having another chance
> to do it again.
> 
> Actually, this kind of problem can be watched in an
> environment in which massive input events are coming
> from multi-touch screen or multi-pen devices. In this
> kind of environment, a client receiving the massive
> input events are trying to drawing something very hard
> but it's being killed sooner or later. With the given
> patch, the client receiving the input events is not being
> destroyed and is working well even though it doesn't get
> the whole input events from the compositor.

This is actually intentional behavior to avoid infinitely growing send
queues for clients that process events too slowly.

I don't think dropping events randomly (or at all) because the client
can't keep up is something we should do in libwayland. It'll just make
for nearly impossible to reproduce and debug problems when client and
compositor state fall out of sync.

What if it's a frame event that gets dropped and not an input event?  Or
a resource destroy?

The disconnect is a clear indication that there's a problem that needs
to be fixed somewhere else. The client needs to process events in a
timely fashion, or the compositor needs to send less events.

Thanks,
Derek

> Signed-off-by: jeon  >
> 
> ---
>  src/wayland-server.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index eae8d2e..5afaa28 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -222,8 +222,15 @@ handle_array(struct wl_resource *resource, uint32_t
> opcode,
>  
>     log_closure(resource, closure, true);
>  
> -   if (send_func(closure, resource->client->connection))
> -   resource->client->error = 1;
> +   if (send_func(closure, resource->client->connection)) {
> +   if (errno == EAGAIN) {
> +   wl_event_source_fd_update(resource->client->source,
> + WL_EVENT_WRITABLE |
> + WL_EVENT_READABLE);
> +   } else {
> +   resource->client->error = 1;
> +   }
> +   }
>  
>     wl_closure_destroy(closure);
>  }
> 
> -- 
> 2.7.4
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] Add alpha-compositing protocol

[Derek Foreman]

This looks nice to me, and I have need of something like this.

A couple of comments below.

On 11/14/18 7:00 PM, Scott Anderson wrote:
> This protocol specifies a set of interfaces used to control the alpha
> compositing and blending of surface contents, based on the Chromium
> Wayland protocol of the same name [1].
> 
> Signed-off-by: Scott Anderson 
> 
> [1] 
> https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
> ---
> 
> Changes in v3:
>   - Rename "blending" event to "blending_equation"
>   - Add enum specifier to "blending_equation" event and "set_blending"
> request.
>   - Fix typos
> 
> Changes in v2:
>   - Add additional "fromsource" blending equation used by [3]
>   - Allow the server to advertise which blending equations it supports
>   - Added a protocol error for using an unsupported equation
>   - Added a protocol error for using an invalid alpha value
>   - Added clarification about wl_surface.set_opaque_region
>   - Added clarification about per-pixel alpha values
> 
>  Makefile.am   |   1 +
>  unstable/alpha-compositing/README |   5 +
>  .../alpha-compositing-unstable-v1.xml | 175 ++
>  3 files changed, 181 insertions(+)
>  create mode 100644 unstable/alpha-compositing/README
>  create mode 100644 
> unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 6394e26..ac6c9f8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -21,6 +21,7 @@ unstable_protocols =
> \
>   unstable/xdg-output/xdg-output-unstable-v1.xml  
> \
>   unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
>   unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> + unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
> \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/alpha-compositing/README 
> b/unstable/alpha-compositing/README
> new file mode 100644
> index 000..5826967
> --- /dev/null
> +++ b/unstable/alpha-compositing/README
> @@ -0,0 +1,5 @@
> +Alpha compositing protocol
> +
> +Maintainers:
> +David Reveman 
> +Alexandros Frantzis 
> diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml 
> b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
> new file mode 100644
> index 000..d3c41d5
> --- /dev/null
> +++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml
> @@ -0,0 +1,175 @@
> +
> +
> +
> +  
> +Copyright 2016  The Chromium Authors.
> +Copyright 2017-2018 Collabora Ltd
> +Copyright 2018  NXP
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +This protocol specifies a set of interfaces used to control the alpha
> +compositing and blending of surface contents.
> +
> +Warning! The protocol described in this file is experimental and backward
> +incompatible changes may be made. Backward compatible changes may be 
> added
> +together with the corresponding interface version bump. Backward
> +incompatible changes are done by bumping the version number in the 
> protocol
> +and interface names and resetting the interface version. Once the 
> protocol
> +is to be declared stable, the 'z' prefix and the version number in the
> +protocol and interface names are removed and the interface version 
> number is
> +reset.
> +  
> +
> +  
> +
> +  The global interface exposing compositing and blending capabilities is
> +  used to instantiate an interface extension for a wl_surface object.
> +  This extended interface will then allow 

Re: [PATCH] protocol: deprecate wl_surface.damage

[Derek Foreman]

On 11/5/18 7:43 AM, Simon Ser wrote:
> On Monday, November 5, 2018 11:07 AM, Pekka Paalanen  
> wrote:
>> How about writing what Derek said: that the old damage request may be
>> unoptimal rather than deprecated.
>>
>> I don't like "deprecated" because to me it implies that this request
>> will be removed (i.e. can be left unimplemented) some time in the future.
> 
> Fair enough, I'll rephrase with words like "should" and "preferred".
> 
> It would be nice to really deprecate this request at some point.

Have we ever considered having a way to deprecate requests (beyond
deprecating entire xml files like the old xdg versions)?

We could generate compile time warnings and perhaps print a log message.

Actually removing protocol might be kind of scary, but we can give
people some way to know that they might get better performance with some
changes.

Or is this so infrequent an occurrence that it doesn't need to be
bothered with?

Thanks,
Derek

>> Xwayland is still using exclusively wl_surface.damage, for instance.
> 
> Sent a patch to fix this [1].
> 
> [1]: https://lists.x.org/archives/xorg-devel/2018-November/057678.html
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] protocol: prefer wl_surface.damage_buffer

[Derek Foreman]

On 11/5/18 7:57 AM, Simon Ser wrote:
> This commit makes wl_surface.damage_buffer preferred over wl_surface.damage.
> wl_surface.damage can be implemented in a non-optimal way by the compositor
> (e.g. by always damaging the whole buffer).
> 
> Having two requests makes it complicated for the compositor to handle damage,
> making it necessary to transform one into the other's coordinates.
> 
> Moreover, integration with wp_viewporter is tricky.
> 
> Signed-off-by: Simon Ser 

Obnoxious nitpick: for some reason that file uses different formatting
than others in the repo, and 8 spaces are compressed into a single tab.

Otherwise, this is:
Reviewed-by: Derek Foreman 

> ---
>  protocol/wayland.xml | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 141038b..df2b6d2 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1397,9 +1397,9 @@
>   and clears pending damage. The server will clear the current
>   damage as it repaints the surface.
>  
> - Alternatively, damage can be posted with wl_surface.damage_buffer
> - which uses buffer coordinates instead of surface coordinates,
> - and is probably the preferred and intuitive way of doing this.
> +Note! New clients should not use this request. Instead damage can be
> +posted with wl_surface.damage_buffer which uses buffer coordinates
> +instead of surface coordinates.
>
>
>
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] protocol: deprecate wl_surface.damage

[Derek Foreman]

IMHO this is a win.

Reviewed-by: Derek Foreman 

I think we can follow it up by removing surface damage in surface
co-ordinates from weston clients - if we don't want people using it, we
shouldn't be giving then good examples of how.

I also think it's reasonable for compositor writers to take the easy way
out of handling legacy surface damage by just treating any
wl_surface.damage request as full surface damage...

Thanks,
Derek

On 11/4/18 2:38 AM, Simon Ser wrote:
> This commit deprecates wl_surface.damage in favor of wl_surface.damage_buffer.
> 
> Having two requests makes it complicated for the compositor to handle damage,
> making it necessary to transform one into the other's coordinates.
> 
> Moreover, integration with wp_viewporter is tricky.
> 
> Signed-off-by: Simon Ser 
> ---
> 
> Based on the discussion in [1].
> 
> [1]: 
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/41#note_74071
> 
>  protocol/wayland.xml | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 141038b..c75ea3a 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1397,9 +1397,9 @@
>   and clears pending damage. The server will clear the current
>   damage as it repaints the surface.
>  
> - Alternatively, damage can be posted with wl_surface.damage_buffer
> - which uses buffer coordinates instead of surface coordinates,
> - and is probably the preferred and intuitive way of doing this.
> + Note! This request is deprecated and should not be used in new
> + clients. Instead damage can be posted with wl_surface.damage_buffer
> + which uses buffer coordinates instead of surface coordinates.
>
>
>
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Bump seat to version 7 and require keymaps be private

[Derek Foreman]

On 11/1/18 12:18 PM, Philipp Kerling wrote:
> Actually...  (below)

Yes, you are of course strictly correct.

However, the recent previous commits that bumped wl_seat version 9a18a8
and c5356e have also kept all three children in sync, and it's become
de-facto convention to do so.

Thanks,
Derek

> 2018-11-01 (木) の 11:15 -0500 に Derek Foreman さんは書きました:
>> Weston commit 76829fc4eaea329d2a525c3978271e13bd76c078 (and similar
>> commits for other compositors) protects the compositor's keyboard
>> mapping from client damage by duplicating the keymap for every
>> client.
>>
>> On some systems there are other potential fixes for this - such as
>> using sealed memfds on linux - but we can't use them since
>> essentially all client code anywhere has mapped the keyboard map
>> with a MAP_SHARED mmap() call.
>>
>> While we can't break years worth of code, we can require any future
>> clients to use MAP_PRIVATE if they use a seat version above 6.
>>
>> If a compositor can't use sealing or a similar facility, it should
>> still protect itself with copied keymaps, but clients must always
>> assume shared mapping of a keymap will fail.
>>
>> Signed-off-by: Derek Foreman 
>> ---
>>  protocol/wayland.xml | 11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index 141038b..802d433 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -1660,7 +1660,7 @@
>>  
>> 
>>  
>> -  
>> +  
>>  
>>A seat is a group of keyboards, pointer and touch devices.
>> This
>>object is published as a global during start up, or when such
>> a
>> @@ -1769,7 +1769,7 @@
>>  
>>
>>  
>> -  
>> +  
> What is the reason for this version bump? The wl_pointer behavior is
> unaffected by the wl_keyboard change, right? As far as I understood the
> protocol versioning rules, bumping all child interfaces when updating
> one child interface is not required. In fact that would make their
> version counters quite superfluous.
> 
> (Same for wl_touch)
> 
>>  
>>The wl_pointer interface represents one or more input devices,
>>such as mice, which control the pointer location and
>> pointer_focus
>> @@ -2092,7 +2092,7 @@
>>  
>>
>>  
>> -  
>> +  
>>  
>>The wl_keyboard interface represents one or more keyboards
>>associated with a seat.
>> @@ -2113,6 +2113,9 @@
>>
>>  This event provides a file descriptor to the client which can
>> be
>>  memory-mapped to provide a keyboard mapping description.
>> +
>> +From version 7 onwards, the fd must be mapped with MAP_PRIVATE
>> by
>> +the recipient, as MAP_SHARED may fail.
>>
>>> summary="keymap format"/>
>>
>> @@ -2203,7 +2206,7 @@
>>  
>>
>>  
>> -  
>> +  
>>  
>>The wl_touch interface represents a touchscreen
>>associated with a seat.
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] protocol: Bump seat to version 7 and require keymaps be private

[Derek Foreman]

Weston commit 76829fc4eaea329d2a525c3978271e13bd76c078 (and similar
commits for other compositors) protects the compositor's keyboard
mapping from client damage by duplicating the keymap for every
client.

On some systems there are other potential fixes for this - such as
using sealed memfds on linux - but we can't use them since
essentially all client code anywhere has mapped the keyboard map
with a MAP_SHARED mmap() call.

While we can't break years worth of code, we can require any future
clients to use MAP_PRIVATE if they use a seat version above 6.

If a compositor can't use sealing or a similar facility, it should
still protect itself with copied keymaps, but clients must always
assume shared mapping of a keymap will fail.

Signed-off-by: Derek Foreman 
---
 protocol/wayland.xml | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 141038b..802d433 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1660,7 +1660,7 @@
 

 
-  
+  
 
   A seat is a group of keyboards, pointer and touch devices. This
   object is published as a global during start up, or when such a
@@ -1769,7 +1769,7 @@
 
   
 
-  
+  
 
   The wl_pointer interface represents one or more input devices,
   such as mice, which control the pointer location and pointer_focus
@@ -2092,7 +2092,7 @@
 
   
 
-  
+  
 
   The wl_keyboard interface represents one or more keyboards
   associated with a seat.
@@ -2113,6 +2113,9 @@
   
This event provides a file descriptor to the client which can be
memory-mapped to provide a keyboard mapping description.
+
+   From version 7 onwards, the fd must be mapped with MAP_PRIVATE by
+   the recipient, as MAP_SHARED may fail.
   
   
   
@@ -2203,7 +2206,7 @@
 
   
 
-  
+  
 
   The wl_touch interface represents a touchscreen
   associated with a seat.
-- 
2.17.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] server: add wl_signal_emit_safe

[Derek Foreman]

On 2018-08-08 07:00 AM, Simon Ser wrote:
> This new function allows listeners to remove themselves or any
> other listener when called. This version only works if listeners
> are properly removed before they are free'd.
> 
> wl_signal_emit tries to be safe but it fails: it works fine if a
> handler removes its own listener, but not if it removes another
> one.
> 
> It's not possible to patch wl_signal_emit directly as attempted
> in [1] because some projects using libwayland directly free
> destroy listeners without removing them from the list. Using this
> new strategy fails in this case, causing read-after-free errors.
> 
> [1]: https://patchwork.freedesktop.org/patch/204641/
> 
> Signed-off-by: Simon Ser 

Hi Simon,

Is there intent to use this internally in libwayland (or in weston?)
somewhere in a further patch?

Since there's no way to know from the callback whether the signal is
being emit "safely" or not, I'm a little concerned that developers might
get confused about what style of callback they're writing. Or people
will see "safe" and just lazily use that everywhere, even for destroy
signals...

Also, it looks at a glance like all of the struct members and such
touched by this function are in public headers?  I think the safe emit
function doesn't strictly need to be in libwayland at all?

I don't really mean to block this work, just wondering what follows next.

Some tiny comments inlined further down.

> ---
> 
> Addressed Markus' comments [1].
> 
> [1]: 
> https://lists.freedesktop.org/archives/wayland-devel/2018-July/039042.html
> 
>  src/wayland-server-core.h |  3 ++
>  src/wayland-server.c  | 50 +++
>  tests/signal-test.c   | 86 +++
>  3 files changed, 139 insertions(+)
> 
> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index 2e725d9..4a2948a 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -468,6 +468,9 @@ wl_signal_emit(struct wl_signal *signal, void *data)
>   l->notify(l, data);
>  }
>  
> +void
> +wl_signal_emit_safe(struct wl_signal *signal, void *data);
> +
>  typedef void (*wl_resource_destroy_func_t)(struct wl_resource *resource);
>  
>  /*
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index eae8d2e..3d851f4 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1932,6 +1932,56 @@ wl_client_for_each_resource(struct wl_client *client,
>   wl_map_for_each(>objects, resource_iterator_helper, );
>  }
>  
> +static void
> +handle_noop(struct wl_listener *listener, void *data) {

I think wayland coding style is to put the { on a new line by itself.

> + /* Do nothing */
> +}
> +
> +/** Emits this signal, safe against removal of any listener.
> + *
> + * wl_signal_emit tries to be safe but it fails: it works fine if a handler
> + * removes its own listener, but not if it removes another one.
> + *
> + * \note This function can only be used if listeners are properly removed 
> before
> + *   being free'd.
> + *
> + * \param signal The signal object that will emit the signal
> + * \param data The data that will be emitted with the signal
> + *
> + * \sa wl_signal_emit()
> + *
> + * \memberof wl_signal
> + */
> +WL_EXPORT void
> +wl_signal_emit_safe(struct wl_signal *signal, void *data) {

Same as above.

No further complaints. :)

Thanks,
Derek

> + struct wl_listener cursor;
> + struct wl_listener end;
> +
> + /* Add two special markers: one cursor and one end marker. This way, we 
> know
> +  * that we've already called listeners on the left of the cursor and 
> that we
> +  * don't want to call listeners on the right of the end marker. The 'it'
> +  * function can remove any element it wants from the list without 
> troubles.
> +  * wl_list_for_each_safe tries to be safe but it fails: it works fine
> +  * if the current item is removed, but not if the next one is. */
> + wl_list_insert(>listener_list, );
> + cursor.notify = handle_noop;
> + wl_list_insert(signal->listener_list.prev, );
> + end.notify = handle_noop;
> +
> + while (cursor.link.next != ) {
> + struct wl_list *pos = cursor.link.next;
> + struct wl_listener *l = wl_container_of(pos, l, link);
> +
> + wl_list_remove();
> + wl_list_insert(pos, );
> +
> + l->notify(l, data);
> + }
> +
> + wl_list_remove();
> + wl_list_remove();
> +}
> +
>  /** \cond INTERNAL */
>  
>  /** Initialize a wl_priv_signal object
> diff --git a/tests/signal-test.c b/tests/signal-test.c
> index 7bbaa9f..dc762a4 100644
> --- a/tests/signal-test.c
> +++ b/tests/signal-test.c
> @@ -115,3 +115,89 @@ TEST(signal_emit_to_more_listeners)
>  
>   assert(3 * counter == count);
>  }
> +
> +struct signal
> +{
> + struct wl_signal signal;
> + struct wl_listener l1, l2, l3;
> + int count;
> + struct wl_listener *current;
> +};
> +
> +static void 

[ANNOUNCE] weston 5.0.0

[Derek Foreman]

This is the official release of weston 5.0.0.

There are a few minor fixes pending that didn't make it in time for the
release, so I think this time I'll follow up with a 5.0.1 in around a
month or so.

For the next major release, I think 3 months until the alpha has worked
ok in the past - anyone with another preference, please speak up!


Derek Foreman (1):
  configure.ac: bump to version 5.0.0 for the official release

Stefan Agner (1):
  compositor-drm: add DPI connector type

git tag 5.0.0

https://wayland.freedesktop.org/releases/weston-5.0.0.tar.xz
MD5: 752a04ce3c65af4884cfac4e57231bdb weston-5.0.0.tar.xz
SHA1: 56b42b1fbea9e120a8127736328e4c71ac781a57 weston-5.0.0.tar.xz
SHA256: 15a23423bcfa45e31e1dedc0cd524ba71e2930df174fde9c99b71a537c4e4caf
weston-5.0.0.tar.xz
SHA512:
b6f97eca014ea47f3de0c5ddd89712f896cd66423d0eb499e1d88d35aab616cef1e735ebb8e0cefd8b60085314b6ec3d56b39d7c4776188bb56d58efc84a52cf
weston-5.0.0.tar.xz

PGP: https://wayland.freedesktop.org/releases/weston-5.0.0.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.16.0

[Derek Foreman]

This is the official release of wayland 1.16.0.

Since RC2, only a test case for the bug that prompted RC2's existence
has been added.

I'm of the opinion that wayland no longer needs to be released in
lock-step with weston, and should be released as necessary when critical
bug fixes or important changes occur.

At this point I don't see a need to schedule a next wayland release, but
if one hasn't occurred when we near the time weston's ready for its next
major release, we can look at what's landed and decide if there's a need.

If that's a bad idea, please speak up!


Derek Foreman (1):
  configure.ac: bump to version 1.16.0 for the official release

Michal Srb (1):
  tests: Demarshalling of very long array/string lengths.

git tag 1.16.0

https://wayland.freedesktop.org/releases/wayland-1.16.0.tar.xz
MD5: 0c215e53de71d6fb26f7102cdc6432d3 wayland-1.16.0.tar.xz
SHA1: 24c63a5045c653dcfa24efd10fa7c7de89aca9ef wayland-1.16.0.tar.xz
SHA256: 4e72c2b56109ccfb6610d776e465f4ca0af2280c9c2f7d5cc23f0ed2548752f5
wayland-1.16.0.tar.xz
SHA512:
64eca2b1c0bc7913508a5499dae87e2723c712d8024acbb4c77c3c4a6c20de78c10704ae9827fd034116ca540a547aeec28c5a1e3bd382b23f85231424b0f49c
wayland-1.16.0.tar.xz

PGP: https://wayland.freedesktop.org/releases/wayland-1.16.0.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Derek Foreman]

On 2018-08-24 12:23 PM, Jamey Sharp wrote:
> For what it's worth, I'm happy to use backported patches. I just hope
> this gets addressed upstream eventually.
> 
> It's a little more than just cosmetic if you have a graphical
> application that can be driven purely by keyboard, and sometimes you
> don't have a working pointer input device so you can't get focus back
> after a VT switch. I grant that's a somewhat niche use case, but it's
> the one I'm dealing with... :-)

Sorry if it seemed I was dismissing this work entirely.  This bug has
been annoying me for quite some time and I hadn't looked into it at all
myself. For my use case, I can use the keyboard focus switch shortcut to
focus something, so it hasn't been a showstopper.

I think we're going to do a weston 5.0.1 in a month or so, and this will
be among the fixes it contains. :)

> I was confused about the state of these patches too, because I didn't
> see the original mails. Hopefully next week I can test the combination
> of Quentin's revert+fix pair with my patch and make sure it passes the
> tests I set up.

That would be great!

> On that note, I would offer my test framework upstream, except I set up
> an entire qemu image using NixOS to test this, and that seems a little
> heavyweight. I can't think of an easier way to test drm-backend stuff
> though...

Would still be interesting to take a look at, I think.

Thanks,
Derek

> Jamey
> 
> On Fri, Aug 24, 2018 at 7:11 AM, Derek Foreman
>  <mailto:derek.foreman.sams...@gmail.com>> wrote:
> 
> On 2018-08-16 02:33 AM, Quentin Glidic wrote:
> > On 8/16/18 5:24 AM, Peter Hutterer wrote:
> >> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:
> >>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:
> >>>> On 8/2/18 10:29 AM, Quentin Glidic wrote:
> >>>>> From: Quentin Glidic  <mailto:sardemff7%2b...@sardemff7.net>>
> >>>>>
> >>>>> If we start a special (grabbing) client when Weston is
> unfocused, it
> >>>>> would lose focus when coming back to Weston.
> >>>>>
> >>>>> A first attempt to fix this was
> >>>>> 85d55540cb64bf97a08b40f79dc66843f8295d3b
> >>>>> but it messed with VT switching.
> >>>>>
> >>>>> This fix just updates the saved focus, so when Weston gets focused
> >>>>> back,
> >>>>> it will focus the correct client.
> >>>>>
> >>>>> Signed-off-by: Quentin Glidic  <mailto:sardemff7%2b...@sardemff7.net>>
> >>>>> ---
> >>>>>
> >>>>> Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
> >>>>> didn’t happen yet. :-)
> >>>>>
> >>>>> I think this patch won’t conflict with VT switching, and it does
> >>>>> fix the
> >>>>> issue I had initially.
> >>>
> >>> I'm a bit confused as to where we're at with this.
> >>>
> >>> How did the reverted patch "mess with" or "conflict with" VT
> switching?
> >>
> >> it ended up always setting the keyboard focus to NULL on VT switch
> >> (due to
> >> how libinput devices are handled), so on vt switch back you had
> no focus.
> >>  
> >>> Is it intended that these two patches be applied, and then
> Jamey's patch
> >>> (marked as "superseded" in patchwork) be applied on top to
> resolve the
> >>> loss of focus on VT switch away/back?
> >>
> >> AIUI, these two need supersede Jamey's patchl but I'm not 100%
> sure on
> >> that,
> >> sorry.
> >>
> >> Cheers,
> >>     Peter
> >>
> >>>
> >>> Thought this might be important to land before the release, but
> it's not
> >>> terribly clear what it actually fixes.  I'd assumed it was the
> VT switch
> >>> thing, but that remains unresolved.
> >>>
> >>> Help? :)
> > Sorry for the confusion. This (second) patch is a cleaner fix of the
> > issue that was “fixed” by the reverted commit. Then on top of it,
> you’ll
> > have to apply Jamey’s patch, which is an independent issue+fix (which
> > the old fix conflicted with). I’m not sure why it was marked
> > superseeded, maybe Patchwork detecting my patch as a reply?
> >
> 
> Thanks guys.  Due to hilariously misconfigured inbox filters I didn't
> catch these replies until today.  Sorry.
> 
> I think the VT switch problem has been around for at least 1 release
> now, possibly a few more, so I think it's ok to release with the long
> standing (mostly cosmetic) bug, and deal with these fixes shortly after.
> 
> Thanks again,
> Derek
> 
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Derek Foreman]

On 2018-08-16 02:33 AM, Quentin Glidic wrote:
> On 8/16/18 5:24 AM, Peter Hutterer wrote:
>> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:
>>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:
>>>> On 8/2/18 10:29 AM, Quentin Glidic wrote:
>>>>> From: Quentin Glidic 
>>>>>
>>>>> If we start a special (grabbing) client when Weston is unfocused, it
>>>>> would lose focus when coming back to Weston.
>>>>>
>>>>> A first attempt to fix this was
>>>>> 85d55540cb64bf97a08b40f79dc66843f8295d3b
>>>>> but it messed with VT switching.
>>>>>
>>>>> This fix just updates the saved focus, so when Weston gets focused
>>>>> back,
>>>>> it will focus the correct client.
>>>>>
>>>>> Signed-off-by: Quentin Glidic 
>>>>> ---
>>>>>
>>>>> Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
>>>>> didn’t happen yet. :-)
>>>>>
>>>>> I think this patch won’t conflict with VT switching, and it does
>>>>> fix the
>>>>> issue I had initially.
>>>
>>> I'm a bit confused as to where we're at with this.
>>>
>>> How did the reverted patch "mess with" or "conflict with" VT switching?
>>
>> it ended up always setting the keyboard focus to NULL on VT switch
>> (due to
>> how libinput devices are handled), so on vt switch back you had no focus.
>>  
>>> Is it intended that these two patches be applied, and then Jamey's patch
>>> (marked as "superseded" in patchwork) be applied on top to resolve the
>>> loss of focus on VT switch away/back?
>>
>> AIUI, these two need supersede Jamey's patchl but I'm not 100% sure on
>> that,
>> sorry.
>>
>> Cheers,
>>     Peter
>>
>>>
>>> Thought this might be important to land before the release, but it's not
>>> terribly clear what it actually fixes.  I'd assumed it was the VT switch
>>> thing, but that remains unresolved.
>>>
>>> Help? :)
> Sorry for the confusion. This (second) patch is a cleaner fix of the
> issue that was “fixed” by the reverted commit. Then on top of it, you’ll
> have to apply Jamey’s patch, which is an independent issue+fix (which
> the old fix conflicted with). I’m not sure why it was marked
> superseeded, maybe Patchwork detecting my patch as a reply?
> 

Thanks guys.  Due to hilariously misconfigured inbox filters I didn't
catch these replies until today.  Sorry.

I think the VT switch problem has been around for at least 1 release
now, possibly a few more, so I think it's ok to release with the long
standing (mostly cosmetic) bug, and deal with these fixes shortly after.

Thanks again,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 4.0.94

[Derek Foreman]

Hello,

The RC2 release candidate for weston 5.0 is now available.

We've gone to RC2 here as well, as a patch has landed to fix a bug
allowing clients to corrupt the compositor's keyboard mapping.

Derek Foreman (3):
  input: add weston_keyboard_send_keymap helper function
  input: Send unique keymap file descriptors to clients
  configure.ac: bump to version 4.0.94 for the RC2 release

git tag: 4.0.94

https://wayland.freedesktop.org/releases/weston-4.0.94.tar.xz
MD5: 314e684e1977e0fd8c5ee751c7d3d2b0 weston-4.0.94.tar.xz
SHA1: 36ca96b4a2edf889903c2494f87fc264a76ab265 weston-4.0.94.tar.xz
SHA256: 3561319d546aba0d49c53882b1656c3e6a5a34f94bec87799e587c551374bceb
weston-4.0.94.tar.xz
SHA512:
865a97ebc116ef79cf764dd2abacac3eb6ab173557b959bde72e7d062e1cebba6ed84ff347de3595d39004d882f531f0dfa7f6cbd818cf4990261ea3e242aa2c
weston-4.0.94.tar.xz

PGP: https://wayland.freedesktop.org/releases/weston-4.0.94.tar.xz.sig




signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.15.94

[Derek Foreman]

Hello,

The RC2 release candidate for wayland 1.16 is now available.

We've had to go to RC2 as this release contains a bug fix for a pointer
overflow condition.

Some discussion at:
https://gitlab.freedesktop.org/wayland/wayland/issues/50


Derek Foreman (1):
  configure.ac: bump to version 1.15.94 for the RC2 release

Michal Srb (2):
  connection: Prevent integer overflow in DIV_ROUNDUP.
  connection: Prevent pointer overflow from large lengths.

git tag 1.15.94

https://wayland.freedesktop.org/releases/wayland-1.15.94.tar.xz
MD5: 076875e953d76a8b0d5101d676499d2a wayland-1.15.94.tar.xz
SHA1: 6144586fd49d72e8a049774941a8237add14c6e2 wayland-1.15.94.tar.xz
SHA256: beec070b723f76362dc7d60a485a21fd4fabe24fe913aa7eff287a148a2ff9ba
wayland-1.15.94.tar.xz
SHA512:
bd1c37ffe43f4cd437951cbc55bb87e52209674dd261dce05f1bc6c54a7bdf089d8d0636a797afe7ab263c2d0cb23aa3b232c2b762afa8601993c26854a5ffb2
wayland-1.15.94.tar.xz

PGP: https://wayland.freedesktop.org/releases/wayland-1.15.94.tar.xz.sig




signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 3/3] connection: Prevent pointer overflow from large lengths.

[Derek Foreman]

On 2018-08-17 05:53 AM, Pekka Paalanen wrote:
> On Tue, 14 Aug 2018 13:07:53 +0200
> Michal Srb  wrote:
> 
>> If the remote side sends sufficiently large `length` field, it will
>> overflow the `p` pointer. Technically it is undefined behavior, in
>> practice it makes `p < end`, so the length check passes. Attempts to
>> access the data later causes crashes.
>>
>> This issue manifests only on 32bit systems, but the behavior is
>> undefined everywhere.
>> ---
>>  src/connection.c | 12 +++-
>>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> Hi,
> 
> this looks correct to me and should address Jann's concerns too. I also
> checked that (end - p) cannot become negative.
> 
> Reviewed-by: Pekka Paalanen 

Also
Reviewed-by: Derek Foreman 

I'll land this and the 2nd patch in the series today before rolling the
RC2 releases.

Looks like the test needs a follow up, so that can land later.

Thanks,
Derek

> I'm still playing with the tests patch a bit.
> 
> 
> Thanks,
> pq
> 
>>
>> diff --git a/src/connection.c b/src/connection.c
>> index 31396bc..a0f10ae 100644
>> --- a/src/connection.c
>> +++ b/src/connection.c
>> @@ -683,7 +683,7 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  struct wl_map *objects,
>>  const struct wl_message *message)
>>  {
>> -uint32_t *p, *next, *end, length, id;
>> +uint32_t *p, *next, *end, length, length_in_u32, id;
>>  int fd;
>>  char *s;
>>  int i, count, num_arrays;
>> @@ -739,8 +739,8 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  break;
>>  }
>>  
>> -next = p + div_roundup(length, sizeof *p);
>> -if (next > end) {
>> +length_in_u32 = div_roundup(length, sizeof *p);
>> +if ((uint32_t) (end - p) < length_in_u32) {
>>  wl_log("message too short, "
>> "object (%d), message %s(%s)\n",
>> closure->sender_id, message->name,
>> @@ -748,6 +748,7 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  errno = EINVAL;
>>  goto err;
>>  }
>> +next = p + length_in_u32;
>>  
>>  s = (char *) p;
>>  
>> @@ -798,8 +799,8 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  case 'a':
>>  length = *p++;
>>  
>> -next = p + div_roundup(length, sizeof *p);
>> -if (next > end) {
>> +length_in_u32 = div_roundup(length, sizeof *p);
>> +if ((uint32_t) (end - p) < length_in_u32) {
>>  wl_log("message too short, "
>> "object (%d), message %s(%s)\n",
>> closure->sender_id, message->name,
>> @@ -807,6 +808,7 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  errno = EINVAL;
>>  goto err;
>>  }
>> +next = p + length_in_u32;
>>  
>>  array_extra->size = length;
>>  array_extra->alloc = 0;
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 




signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/3] connection: Prevent integer overflow in DIV_ROUNDUP.

[Derek Foreman]

On 2018-08-17 05:39 AM, Pekka Paalanen wrote:
> On Tue, 14 Aug 2018 13:07:52 +0200
> Michal Srb  wrote:
> 
>> The DIV_ROUNDUP macro would overflow when trying to round values higher
>> than MAX_UINT32 - (a - 1). The result is 0 after the division. This is
>> potential security issue when demarshalling an array because the length
>> check is performed with the overflowed value, but then the original huge
>> value is stored for later use.
>>
>> The issue was present only on 32bit platforms. The use of size_t in the
>> DIV_ROUNDUP macro already promoted everything to 64 bit size on 64 bit
>> systems.
>> ---
>>  src/connection.c | 23 ++-
>>  1 file changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/connection.c b/src/connection.c
>> index 294c521..31396bc 100644
>> --- a/src/connection.c
>> +++ b/src/connection.c
>> @@ -44,7 +44,12 @@
>>  #include "wayland-private.h"
>>  #include "wayland-os.h"
>>  
>> -#define DIV_ROUNDUP(n, a) ( ((n) + ((a) - 1)) / (a) )
>> +static inline uint32_t div_roundup(uint32_t n, size_t a) {
>> +// The cast to uint64_t is necessary to prevent overflow when rounding
>> +// values close to UINT32_MAX. After the division it is again safe to
>> +// cast back to uint32_t.
>> +return (uint32_t) (((uint64_t) n + (a - 1)) / a);
>> +}
> 
> The above has a few style issues:
> - div_roundup should start on a new line as it is a function now
> - use /* */ comment style
> - use tabs for indent
> - missing Signed-off-by
> 
> But aside from those, this patch is:
> 
> Reviewed-by: Pekka Paalanen 

It's also
Reviewed-by: Derek Foreman 

I'd like to land this today, so I'll deal with the trivial style
complaints when landing.

Thanks,
Derek

>>  
>>  struct wl_buffer {
>>  char data[4096];
>> @@ -734,7 +739,7 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  break;
>>  }
>>  
>> -next = p + DIV_ROUNDUP(length, sizeof *p);
>> +next = p + div_roundup(length, sizeof *p);
>>  if (next > end) {
>>  wl_log("message too short, "
>> "object (%d), message %s(%s)\n",
>> @@ -793,7 +798,7 @@ wl_connection_demarshal(struct wl_connection *connection,
>>  case 'a':
>>  length = *p++;
>>  
>> -next = p + DIV_ROUNDUP(length, sizeof *p);
>> +next = p + div_roundup(length, sizeof *p);
>>  if (next > end) {
>>  wl_log("message too short, "
>> "object (%d), message %s(%s)\n",
>> @@ -1068,7 +1073,7 @@ buffer_size_for_closure(struct wl_closure *closure)
>>  }
>>  
>>  size = strlen(closure->args[i].s) + 1;
>> -buffer_size += 1 + DIV_ROUNDUP(size, sizeof(uint32_t));
>> +buffer_size += 1 + div_roundup(size, sizeof(uint32_t));
>>  break;
>>  case 'a':
>>  if (closure->args[i].a == NULL) {
>> @@ -1077,7 +1082,7 @@ buffer_size_for_closure(struct wl_closure *closure)
>>  }
>>  
>>  size = closure->args[i].a->size;
>> -buffer_size += (1 + DIV_ROUNDUP(size, 
>> sizeof(uint32_t)));
>> +buffer_size += (1 + div_roundup(size, 
>> sizeof(uint32_t)));
>>  break;
>>  default:
>>  break;
>> @@ -1139,11 +1144,11 @@ serialize_closure(struct wl_closure *closure, 
>> uint32_t *buffer,
>>  size = strlen(closure->args[i].s) + 1;
>>  *p++ = size;
>>  
>> -if (p + DIV_ROUNDUP(size, sizeof *p) > end)
>> +if (p + div_roundup(size, sizeof *p) > end)
>>  goto overflow;
>>  
>>  memcpy(p, closure->args[i].s, size);
>> -p += DIV_ROUNDUP(size, sizeof *p);
>> +p += div_roundup(size, sizeof *p);
>>  break;
>>  case 'a':
>>  if (closure->args[i].a == NULL) {
>> @@ -1154,11 +1159,11 @@ serialize_closure(struct wl_closure *closure, 
>> uint32_t *buffer

[ANNOUNCE] weston 4.0.93

[Derek Foreman]

Hello,

The RC1 release candidate for weston 5.0 is now available.

Daniel Stone (3):
  doc: Update CONTRIBUTING for Weston
  README: Move to Markdown, rewrite introduction
  doc: Use GitLab MRs for patches, not the list

Derek Foreman (1):
  configure.ac: bump to version 4.0.93 for the RC1 release

Harsha M M (2):
  libweston: Remove signals from the list during de-init
  ivi-shell: Remove the compositor destory listener from list during
de-init

Pekka Paalanen (1):
  Add CONTRIBUTING.md document

Will Thompson (1):
  doc: fix typos in CONTRIBUTING.md

git tag: 4.0.93

https://wayland.freedesktop.org/releases/weston-4.0.93.tar.xz
MD5: 562188a000fb1037f069da93fe999094 weston-4.0.93.tar.xz
SHA1: bbf309a00ff8f5f8d26662422563a49a96ba0ae1 weston-4.0.93.tar.xz
SHA256: e12984033d5ef51a02c8b898efb479a2971c89f52c4d7e8f07cee65e7a7f9c97
weston-4.0.93.tar.xz
SHA512:
53e27e9e663fe48176297af8c1164400722cc135ce1f88557c6fcfbc285a5a3efcb6d8f931b0ecac615c1e50722011d2170fada4738bb17dd86900cad4ff9737
weston-4.0.93.tar.xz

PGP: https://wayland.freedesktop.org/releases/weston-4.0.93.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland-1.15.93

[Derek Foreman]

Hello,

The RC1 release candidate for wayland 1.16 is now available.

Daniel Stone (1):
  contributing: Weston now uses GitLab MRs

Derek Foreman (1):
  configure.ac: bump to version 1.15.93 for the RC1 release

git tag: 1.15.93

https://wayland.freedesktop.org/releases/wayland-1.15.93.tar.xz
MD5: 10188223dca324b4bd6107275ea830b9 wayland-1.15.93.tar.xz
SHA1: 93b53a0447056baa1302e319891f32e88a8d34ff wayland-1.15.93.tar.xz
SHA256: ffea7644103213aa06391731217c371464e03e7ff0ab756d3755035c02ac6642
wayland-1.15.93.tar.xz
SHA512:
723cb7fe01692fa24e3b689882f0b5075af4119ae1bbb1664f846c4fdc6cca242173cfbe17331aaffec33a5b091f309dac5318799b4db4206b6145eb5da694c1
wayland-1.15.93.tar.xz

PGP: https://wayland.freedesktop.org/releases/wayland-1.15.93.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Derek Foreman]

On 2018-08-02 03:32 AM, Quentin Glidic wrote:
> On 8/2/18 10:29 AM, Quentin Glidic wrote:
>> From: Quentin Glidic 
>>
>> If we start a special (grabbing) client when Weston is unfocused, it
>> would lose focus when coming back to Weston.
>>
>> A first attempt to fix this was 85d55540cb64bf97a08b40f79dc66843f8295d3b
>> but it messed with VT switching.
>>
>> This fix just updates the saved focus, so when Weston gets focused back,
>> it will focus the correct client.
>>
>> Signed-off-by: Quentin Glidic 
>> ---
>>
>> Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
>> didn’t happen yet. :-)
>>
>> I think this patch won’t conflict with VT switching, and it does fix the
>> issue I had initially.

I'm a bit confused as to where we're at with this.

How did the reverted patch "mess with" or "conflict with" VT switching?

Is it intended that these two patches be applied, and then Jamey's patch
(marked as "superseded" in patchwork) be applied on top to resolve the
loss of focus on VT switch away/back?

Thought this might be important to land before the release, but it's not
terribly clear what it actually fixes.  I'd assumed it was the VT switch
thing, but that remains unresolved.

Help? :)

Thanks,
Derek

>> Cheers,
> 
> Forgot to CC everyone.
> 
>>   libweston/input.c | 38 +-
>>   1 file changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/libweston/input.c b/libweston/input.c
>> index f1017dc1b..6a7f584fd 100644
>> --- a/libweston/input.c
>> +++ b/libweston/input.c
>> @@ -1507,6 +1507,17 @@ weston_pointer_set_focus(struct weston_pointer
>> *pointer,
>>   wl_signal_emit(>focus_signal, pointer);
>>   }
>>   +static void
>> +destroy_device_saved_kbd_focus(struct wl_listener *listener, void *data)
>> +{
>> +    struct weston_seat *ws;
>> +
>> +    ws = container_of(listener, struct weston_seat,
>> +  saved_kbd_focus_listener);
>> +
>> +    ws->saved_kbd_focus = NULL;
>> +}
>> +
>>   static void
>>   send_enter_to_resource_list(struct wl_list *list,
>>   struct weston_keyboard *keyboard,
>> @@ -1528,7 +1539,8 @@ weston_keyboard_set_focus(struct weston_keyboard
>> *keyboard,
>>     struct weston_surface *surface)
>>   {
>>   struct wl_resource *resource;
>> -    struct wl_display *display = keyboard->seat->compositor->wl_display;
>> +    struct weston_seat *seat = keyboard->seat;
>> +    struct wl_display *display = seat->compositor->wl_display;
>>   uint32_t serial;
>>   struct wl_list *focus_resource_list;
>>   @@ -1540,6 +1552,17 @@ weston_keyboard_set_focus(struct
>> weston_keyboard *keyboard,
>>   if (surface && !surface->resource)
>>   surface = NULL;
>>   +    /* If we have a saved focus, this means Weston itself is
>> unfocused.
>> + * In this case, we just want to update our to-be-restored focus.
>> + */
>> +    if (seat->saved_kbd_focus != NULL && surface != NULL) {
>> +    wl_list_remove(>saved_kbd_focus_listener.link);
>> +    seat->saved_kbd_focus = surface;
>> +    wl_signal_add(>destroy_signal,
>> +  >saved_kbd_focus_listener);
>> +    return;
>> +    }
>> +
>>   focus_resource_list = >focus_resource_list;
>>     if (!wl_list_empty(focus_resource_list) && keyboard->focus !=
>> surface) {
>> @@ -2229,17 +2252,6 @@ notify_pointer_focus(struct weston_seat *seat,
>> struct weston_output *output,
>>   }
>>   }
>>   -static void
>> -destroy_device_saved_kbd_focus(struct wl_listener *listener, void *data)
>> -{
>> -    struct weston_seat *ws;
>> -
>> -    ws = container_of(listener, struct weston_seat,
>> -  saved_kbd_focus_listener);
>> -
>> -    ws->saved_kbd_focus = NULL;
>> -}
>> -
>>   WL_EXPORT void
>>   notify_keyboard_focus_in(struct weston_seat *seat, struct wl_array
>> *keys,
>>    enum weston_key_state_update update_state)
>> @@ -2262,8 +2274,8 @@ notify_keyboard_focus_in(struct weston_seat
>> *seat, struct wl_array *keys,
>>     if (surface) {
>>   wl_list_remove(>saved_kbd_focus_listener.link);
>> -    weston_keyboard_set_focus(keyboard, surface);
>>   seat->saved_kbd_focus = NULL;
>> +    weston_keyboard_set_focus(keyboard, surface);
>>   }
>>   }
>>  
> 
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 4.0.92

[Derek Foreman]

Hello,

Here is the beta release for weston 5.0.

Daniel Stone (3):
  compositor-drm: Remove unnecessary libdrm defines
  compositor-drm: Don't test render-only atomic configuration
  compositor-drm: Remove addfb warning for user buffers

Derek Foreman (1):
  configure.ac: bump to version 4.0.92 for the beta release

Emre Ucan (2):
  ivi-shell: listen compositor wake_signal
  ivi-shell: use install paths in example config

Greg V (1):
  xwayland/selection: do not remove NULL property_source

git tag: 4.0.92

https://wayland.freedesktop.org/releases/weston-4.0.92.tar.xz
MD5: fdd052493285dbaac5bc7349aa3b49e3  weston-4.0.92.tar.xz
SHA1:  3bdc662be10c743286d21b2980abf9e570a1080a  weston-4.0.92.tar.xz
SHA256: de45d2c1d64b205a0c7b882e89caba7ac984bfb3e3fc61089db6ec4ce8834981
 weston-4.0.92.tar.xz
SHA512:
41f73f64f7456da1aae587d5c99de8c4305bc50c5028d03056ba9a361dfdec0063b786ebcf972fdd540e18fbbc4d55ae2bd1ed0181e09e8ff3e9e204787f02d4
 weston-4.0.92.tar.xz

PGP: https://wayland.freedesktop.org/releases/weston-4.0.92.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.15.92

[Derek Foreman]

Hello,

Here is the beta for the 1.16 release.

Daniel Stone (3):
  build: Remove execinfo.h check
  build: Remove support for non-pkg-config Expat
  spec: Delete old unused directory

Derek Foreman (2):
  wayland-server: Finally remove deprecated struct wl_buffer definition
  configure.ac: bump to version 1.15.92 for the beta release

Simon Ser (1):
  protocol: allow to send a zero physical output size

git tag: 1.15.92

https://wayland.freedesktop.org/releases/wayland-1.15.92.tar.xz
MD5:  6d0379854adf8ef1bb55797ea1699e9b wayland-1.15.92.tar.xz
SHA1: 5946c28920191d233b0bd3c5fd4ca2c9cfb9864d wayland-1.15.92.tar.xz
SHA256: d6a2b10a06a155be72a074f77cd055e50e15c4f7cbfb73a14bd52f0307be8518
wayland-1.15.92.tar.xz
SHA512:
c3c16f4c9c699f9b3f81a3391388319a3332623b7e5ff37ebe2a0670a1481250677287b0dbfba5a9028b89b7eca3d5a547df90e1ab50b76867d0fb3d3b0e6c65
wayland-1.15.92.tar.xz

PGP: https://wayland.freedesktop.org/releases/wayland-1.15.92.tar.xz



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] compositor-drm: Remove addfb warning for user buffers

[Derek Foreman]

On 2018-07-12 06:16 AM, Daniel Stone wrote:
> THe KMS AddFB call can fail for any reason at all: format/modifier not
> suitable, stride not aligned, allocation not contiguous, etc. If this
> happens with Weston's own buffers, the result is bad - no composition
> output.
> 
> Failing AddFB from user-supplied buffers though, is not an error. The
> user can't necessarily allocate suitable buffers, nor does it have to.
> Don't spam the log with warnings when we fail on user buffers.
> 
> Signed-off-by: Daniel Stone 
> Reported-by: Pekka Paalanen 

Reviewed-by: Derek Foreman 

And I'm going to land it just before I make the release shortly. Not a
high priority bug fix, but nobody likes irrelevant log spam.

> ---
>  libweston/compositor-drm.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 95b379740..f57be6265 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -1184,10 +1184,8 @@ drm_fb_get_from_dmabuf(struct linux_dmabuf_buffer 
> *dmabuf,
>   goto err_free;
>   }
>  
> - if (drm_fb_addfb(fb) != 0) {
> - weston_log("failed to create kms fb: %m\n");
> + if (drm_fb_addfb(fb) != 0)
>   goto err_free;
> - }
>  
>   return fb;
>  
> @@ -1258,7 +1256,8 @@ drm_fb_get_from_bo(struct gbm_bo *bo, struct 
> drm_backend *backend,
>   }
>  
>   if (drm_fb_addfb(fb) != 0) {
> - weston_log("failed to create kms fb: %m\n");
> + if (type == BUFFER_GBM_SURFACE)
> + weston_log("failed to create kms fb: %m\n");
>   goto err_free;
>   }
>  
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] compositor-drm: Don't test render-only atomic configuration

[Derek Foreman]

On 2018-07-20 01:55 PM, Daniel Stone wrote:
> In the RENDERER_ONLY state proposal mode, we don't actually have a
> viable configuration to test, because we won't get a renderer buffer
> until after assign_planes - where we're called from - has completed.
> 
> This can result in us trying to test a configuration with the CRTC and
> connectors active, but no planes active, which the kernel can
> legitimately fail.
> 
> If we're working in renderer-only mode, just return the state we have
> without trying to test it first, and let the kernel fill it in later.
> 
> Signed-off-by: Daniel Stone 

This looks right to me, and is apparently quite important as it fixes VT
switching.

I'm not really well versed enough in this code to give a solid RB, but
I'm going to land it shortly with
Acked-by: Derek Foreman 


> ---
>  libweston/compositor-drm.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 98e6ff839..704ac32c7 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -3488,6 +3488,11 @@ drm_output_propose_state(struct weston_output 
> *output_base,
>   pixman_region32_fini(_region);
>   pixman_region32_fini(_region);
>  
> + /* In renderer-only mode, we can't test the state as we don't have a
> +  * renderer buffer yet. */
> + if (mode == DRM_OUTPUT_PROPOSE_STATE_RENDERER_ONLY)
> + return state;
> +
>   /* Check to see if this state will actually work. */
>   ret = drm_pending_state_test(state->pending_state);
>   if (ret != 0)
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 1/2] spec: Delete old unused directory

[Derek Foreman]

On 2018-07-22 04:17 AM, Daniel Stone wrote:
> The protocol spec used to live here, but it's now part of the regular
> doc build. The PNG files are created as part of the doc build. Delete
> the pre-generated versions.
> 
> Signed-off-by: Daniel Stone 

Nice find.

Reviewed-by: Derek Foreman 

> ---
>  spec/.gitignore   |   3 ---
>  spec/wayland-architecture.png | Bin 29162 -> 0 bytes
>  spec/x-architecture.png   | Bin 37306 -> 0 bytes
>  3 files changed, 3 deletions(-)
>  delete mode 100644 spec/.gitignore
>  delete mode 100644 spec/wayland-architecture.png
>  delete mode 100644 spec/x-architecture.png
> 
> diff --git a/spec/.gitignore b/spec/.gitignore
> deleted file mode 100644
> index 4962683d..
> --- a/spec/.gitignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -main.aux
> -main.log
> -main.pdf
> diff --git a/spec/wayland-architecture.png b/spec/wayland-architecture.png
> deleted file mode 100644
> index 
> 4f92e0fb93825a68095b75d499bac00e968419e5..
> GIT binary patch
> literal 0
> HcmV?d1
> 
> literal 29162
> zcma%iWmJ@3)GrOfPy#Y^cZ1SMN(+c|BOu*f14DyIhe(`Iq@$oHB{eii$H36<
> z0zBY}RwC~L
> z@DImVNyC5u_zNSjPXN9@@KQJR#lU#z_wR$b^qMIMcu3>-%*5}d=WD+}TOS9Ez`#I3
> zXAf6jJ6kUYK~EpY`~z893=C!r4HZR$pn|=^z;_f=7xBwPT8F*HFQluOd09({$_R{9
> znoGEO(S~H#v)2i@d?@R6K-66?IWqypNJ76+;et3HE# zn_D06b>z&~9e3a2u77gLsho}9g>4D_qd;6Dt;chpO#|}YVs4_DU6s1S(`L17Os+MI
> zt144^1Ort@);fRXe-ed7$q+n^Hb=+SpS<-@s?$Mw)9DA;#
> z$48tyS57@|MLLuZR_gVlrXn4vsQLv!t6oIODXur}9(=rBhhki2l}q8!N1t(Ao>L
> zOU6U#G-is2=E;=pDGAXoankrSXHNzkh3!A$2*-g?_C3TRDyljYLds7tA-G?MzA#6#
> zB!bnuATmp;-~qO7v_lnP!bsq&9*`(FBSE`_Zzn_*cx9dG-s8|I`G^Kont`XytZbOt
> z>+5qAhfK7c_Q8XU;xAUfMo`N{q7da;qP$mwJ8Q5$t7QRrsH?#8kBAenT^
> z)(k#d7@l%R1?I%yJc06^*Wh7X5Us5+C5GU+8=)}!gIHNbLTO;}(JW&;SOrX;Y@pJY
> z1c~FXqA0 zMYH%&>WKj?DV38wgwELrcPQ5f(b*8ZReJa16fZje-Qmj(?ZRMldJ9u
> zWuM}t`5b7SW-xr`EV@i{B$@{`4N*1T{GqeSLlm
> z$%QP9ivj5};xwR@)h_g+C@9A>5+O6dpg6diy5W_|MQG-+@u(q6u@P}9LaO{W$-_Kf
> z0x|uCq8wTAXN(JCIaV)^?Y9V8Z+B-HH_JaM|=
> zpb^oPlTW@$%M|4$roDsYu*K_VzY#f68AGe?Z&`9W1R>8RZ8nu8!yb23Jul*OV7~Bq
> zd6(v6h!{~r>*tYvgd-(vmRSy6QzUPC%@`>lQJntB-cV%S=5e!_enZeh(aruh?E{O(
> zgY?{N9!~((Q2)uqgT5Hy`yr*pG{fQI9qo94{cgA7$;@D+vx}QIGWZ9)3OjV`#Je
> z{YQhy<1_wMv}0kI#}`icP4*FD^~YeNofi6-<8pyGE@ z7!vhz*g|f!q zt+EL2)?4U2Mf}o!4OYfNc5NBA_Jm30)KN|BM+M9+7k7h57@!UA>u-+wFQAB9RAW10
> zgAbx6Hso8-3l`sx#J(Q`8~p0>nw!((hYN0`epG(_sG^wAzXqp0{QMO<5c_czW}#VZ
> zK=1rHJPt?f`q3d?Fee-6x&4a?xh=Bo9hWe0h*)DU+yg)GS2NT+jc|4R1n
> zSzo)S;013QH3KhcIJ3O$hGu{Kg<`B|KjH%wUM*?N`wPgTINFvmONcnPfT|;TdXm_(
> z>EWY#av3v;nA3S|WNon~(2a!yi$kQv)Oo#mhP8-8)O_??I`M?4?W!Vra?
> zUwqmfsaVeqUWdxGpC=W|i-mW!Fvww1R27`QXZwJWAE1;8nS4&7Qf?-^+E7rmx+VXm
> zVor4QZny-#^_n66sqUAn{iA-l(!}N6OnZyHpfsU~L!F~dn<@kGtx#<1N8b0SCqa8`
> zG`vR})u|4kzeDEOGjbcG9Va}qp~Ba@0)Mq;MCtEL4^ab$`vObB-0M%ScaKJVwlAW>
> zilBp@zjQhvRS6mLRA1rqfnViNAD4-I+-7i!u0g80h`T$A@|EMhqiz4Cna#$tB79LI
> zxq!Hf!#{?}Xez%lPKYOjV=4bWs7UPR{I_wRrxuc!JbUJ%`+!pFNo_;PIjAlO{
> zUrv(bGsDoi@+5q!4i_eP=ak3SLDD^5u1M3~G2dtCuh~(26A$*K1NU= z%i*gi6fqI4y-wmn|Ge$r1)t;uNu{D<&%dv?>PAGSei+bNTe zNENeD&^>nAswbPMM}+s|N=X#h;zer7tl!_L&-PL4^gT-v`1?h!x71Mi68cV($SR-v
> zm357zMNkM*`U=LrwDjv1dG@nELZ+K%Nh@v=chPok}
> zQ*?U%MJC8#N>E|r=$>yAu+x(%9$GU(_h}pSM|M0boQQUJo-#fcD7lK~tf#3^`
> z+%ZP%iRIOBm@C~ep|M-c1SEzITg5VTi%!aF=E)fcX|xdH;JM^yPr)^Z{X6{fj|l2c
> zhiJI}4XQD@@Ukz$%3RXRM0PrNc#9Giul7~0>oaz8gaL%C;M!|^% z>?k~ur86}0nl)_k`V`NaKU`_y%W7@R8^O>QTXrsu30X^up!cJxKxbQ}=mPzz=^|
> zP$pmn-o>w@T=G!@@Ie7Rw+<4IQO653{GX`z#GdeqryN)8CLve?GhO4Rp) z9l1{WfP4Q;utFsnW0QaUu1H_FBwjY+V!mLjVOel30HghU^!85}k1;Pg^!aYm%!k$>
> zmwxaMu_ocAJq?c5py%f^Ta8)XVwLtSrA^CRChfcn-p=ZqTQ(zBQbvtr<`a$^oIw#S
> zvJsBz$zI~)##*KReTcLvMJ-KneIbCFAvEE)wt%au`6_MUBn$wMK
> zzOp`g1ZA^DH zMHc|iv0TlDCh)@le(#?k7U!A#LE-ASM$&0D^2@ZvDCMmyg0@@1A|!{Ob6hB;-GqCX
> z?(=42R-0}Wk1{@#yTV@E6ZOc{g~AC}p(%7Hs2O@E1gh3D7@9CW3`9148<1KmJd|A0
> zXssk#H5Y70g?mO2>qfAak%1iXCa4{qzpK3*x(>Z136|UKnAsgooxvBK6Gjt*Pouvn
> zZH+L-OB-Utth!?8Q(a974ic8XKKH3Jl?p2KkN%xUoh>J$D83(apAy#>!=axO+%;b-
> zu6#_SLhz)hd}~D}?(%RLj>75A9XC0Ferd>a zKkHg*^s4Vz%ofSlGFY~JDf-mlQ--!j1yznnZxJaz(;@Bb%fZ979Z^n`7I4_@o3J^)
> ztOv50U{HPOp^LCE+{qA~N}d=qK~(UkniM0s>c$HP2Y30v>-!bTPfwI;%Fv7Ymhz
> z*) z<35aa{1of$1vDs(86jVAENAVrYZVpNtRwe=lV z$4Y*iAUpr}g&+gp1J%!A%?_ix~a31st_?4o8S|I)L`)20rtEUlR
> zBezj+FBqgY84kOu z@y_lS!4?+xHxfNv`BTwiatQahlxzo?=91uWDM2fWZgGYJrqwTMcJmD^cY`W7cNQee
> zH@p+r0*oGW3SEVBUoR8wSCp1Ko|nx1x{XI>3!Sv>{PoMLy!Gb+L0%4LNVk23<*tP}
> zKWZT4SE7KN2r_tQeli;c@7yULEd@dmpnNjOt?otUbx)}L!r7}M+zsXn5A@d2^vp^-
> z{*QBZ$>yA7m~?28-81(I(wQFN2w~9JKfw%K@Z40|F=}(o_*9_p6` zld<)MD+qr~v5nW##vxVVVRFV$#T%l@*615uz

Re: [PATCH] compositor-drm: Remove unnecessary libdrm defines

[Derek Foreman]

On 2018-07-20 05:06 AM, Daniel Stone wrote:
> The backend begins with a series of #defines of libdrm tokens, in case
> the libdrm we build against is too old.
> 
> Commit efdebbc4e82b ("configure.ac: bump libdrm requirement to 2.4.68")
> did what it said on the box; since we now depend on a relatively modern
> libdrm, we can get rid of most of our compatibility defines.
> 
> DRM_CAP_TIMESTAMP_MONOTONIC was added in libdrm 2.4.47 (f8f1f6e37ae2).
> DRM_CLIENT_CAP_UNIVERSAL_PLANES was added in libdrm 2.4.55
> (8fc62ca8ac01).
> DRM_CAP_CURSOR_WIDTH and HEIGHT were added in libdrm 2.4.68
> (cc9a53f076d4).

Thank you for making this so trivial to review! :)

> Remove these four fallback definitions.
> 
> Signed-off-by: Daniel Stone 

Reviewed-by: Derek Foreman 

> ---
>  libweston/compositor-drm.c | 16 
>  1 file changed, 16 deletions(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index da9cf5e4f..e3e127a2d 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -91,26 +91,10 @@
>  #include "linux-dmabuf.h"
>  #include "linux-dmabuf-unstable-v1-server-protocol.h"
>  
> -#ifndef DRM_CAP_TIMESTAMP_MONOTONIC
> -#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> -#endif
> -
> -#ifndef DRM_CLIENT_CAP_UNIVERSAL_PLANES
> -#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2
> -#endif
> -
>  #ifndef DRM_CLIENT_CAP_ASPECT_RATIO
>  #define DRM_CLIENT_CAP_ASPECT_RATIO  4
>  #endif
>  
> -#ifndef DRM_CAP_CURSOR_WIDTH
> -#define DRM_CAP_CURSOR_WIDTH 0x8
> -#endif
> -
> -#ifndef DRM_CAP_CURSOR_HEIGHT
> -#define DRM_CAP_CURSOR_HEIGHT 0x9
> -#endif
> -
>  #ifndef GBM_BO_USE_CURSOR
>  #define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
>  #endif
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 2/2] build: Remove support for non-pkg-config Expat

[Derek Foreman]

On 2018-07-21 06:13 AM, Daniel Stone wrote:
> The Expat XML library has shipped a pkg-config file for long enough to
> be in Debian's oldstable (Jessie, April 2015) and Ubuntu's oldest
> supported LTS (Trusty, 14.04). The pkg-config file was added in Expat
> upstream's commit 352cfc8f59a7, in September 2007.
> 
> Drop build support for versions of Expat which do not ship a
> pkg-config file.
> 
> Signed-off-by: Daniel Stone 

Looks good to me
Reviewed-by: Derek Foreman 

> ---
>  configure.ac | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 8c2fb822..0022dcda 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -111,16 +111,7 @@ if test "x$enable_libraries" = "xyes"; then
> [[#include ]])
>  fi
>  
> -PKG_CHECK_MODULES(EXPAT, [expat], [],
> - [AC_CHECK_HEADERS(expat.h, [],
> - [AC_MSG_ERROR([Can't find expat.h. Please install expat.])])
> -  SAVE_LIBS="$LIBS"
> -  AC_SEARCH_LIBS(XML_ParserCreate, expat, [],
> - [AC_MSG_ERROR([Can't find expat library. Please install 
> expat.])])
> -  EXPAT_LIBS="$LIBS"
> -  LIBS="$SAVE_LIBS"
> -  AC_SUBST(EXPAT_LIBS)
> - ])
> +PKG_CHECK_MODULES(EXPAT, [expat])
>  
>  AM_CONDITIONAL([DTD_VALIDATION], [test "x$enable_dtd_validation" = "xyes"])
>  if test "x$enable_dtd_validation" = "xyes"; then
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 1/2] build: Remove execinfo.h check

[Derek Foreman]

On 2018-07-21 06:13 AM, Daniel Stone wrote:
> The check for the execinfo.h header is only advisory; the build will not
> fail if it is not present, and set HAVE_EXECINFO_H if it is. The check
> was added in commit 5cfdbef3d299 ("build: Allow disabling building of
> wayland libraries") with no obvious use or reasoning.

5cfdbe3d299 just moved it, it was added in commit bc3e020475

It appears to have been accidentally included there, as it doesn't look
relevant to the bug ticket referenced in the commit.

> Remove the no-op check.
> 
> Signed-off-by: Daniel Stone 

Reviewed-by: Derek Foreman 

Though, I wouldn't mind seeing a more accurate commit log. ;)

> ---
>  configure.ac | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 81cf4077..8c2fb822 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -109,7 +109,6 @@ if test "x$enable_libraries" = "xyes"; then
>   AC_CHECK_DECL(CLOCK_MONOTONIC,[],
> [AC_MSG_ERROR("CLOCK_MONOTONIC is needed to compile 
> wayland libraries")],
> [[#include ]])
> - AC_CHECK_HEADERS([execinfo.h])
>  fi
>  
>  PKG_CHECK_MODULES(EXPAT, [expat], [],
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland] wayland-server: Finally remove deprecated struct wl_buffer definition

[Derek Foreman]

On 2018-07-14 09:46 AM, Daniel Stone wrote:
> Hey Derek,
> On Fri, 16 Feb 2018 at 16:55, Derek Foreman  wrote:
>> commit d94a8722cb29d8b897672be66ff3c9ff79eab6fe
>> warned this was coming, back in 2013.
>>
>> I've seen libraries that have wayland client and server using functions
>> in the same file.  Since struct wl_buffer still exists as an opaque
>> entity in client code, the vestigial deprecated wl_buffer from the
>> server include will generate warnings when not building with
>> WL_HIDE_DEPRECATED.
> 
> I wonder if it's now too late to land this for the next release. Seems
> good to me though, and certainly people have had enough notice ...
> 
> For landing whenever (I'll happily take your judgement), this is:
> Reviewed-by: Daniel Stone 

I think it's a slight, but not huge, stretch to call this a bug fix,
since it should be possible to include client and server headers in the
same file even without defining WL_HIDE_DEPRECATED.

I've pushed this now.

Thanks,
Derek

> Cheers,
> Daniel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged

[Derek Foreman]

On 2018-07-22 05:55 AM, Daniel Stone wrote:
> Hey Derek,
> 
> On Thu, 22 Feb 2018 at 22:16, Derek Foreman  wrote:
>> Keep track of what cusor image buffer is attached to the cursor
>> surface and avoid re-attaching it if we don't have to.
>>
>> This isn't just an obviously pointless optimization, it turns all
>> of toy toolkit into a test case for handling this properly.
>>
>> Signed-off-by: Derek Foreman 
>> ---
>>
>> Continuing my streak of posting unpopular patches, this patch breaks
>> weston, so I'm not pushing for inclusion, but I think we need to
>> resolve why it breaks, and fix either weston or wayland documentation
>> to reflect expected behaviour.
>>
>> I think this can be attributed to a weston bug, and we should be able to
>> expect that the compositor will be able to redisplay the surface without
>> needing to attach a new buffer, and that if the compositor has released
>> the buffer then it has a kept copy somewhere...
>>
>> Any other opinions?
> 
> Hmm, I'm really not sure what to think about this.
> 
> I take it the problem is that the client sets a particular surface as
> the pointer surface, loses focus, sets the same surface as the pointer
> surface on re-enter after not changing the content, and then the
> content is never shown?

That's my understanding of what I'm seeing, yes.

Note that it only happens when the cursor can be placed in the cursor
plane (ie: it's wayland_shm).

The old cursor continues to be shown - if I move into an EFL client from
the desktop, the desktop cursor arrow is sometimes unchanged.

I do get a surface enter for my pointer surface, though.

I'm reasonably confident the first time I saw this I would get no cursor
at all on re-enter, but now I get the existing cursor.  Though sometimes
it updates to my client cursor, despite no damage or new buffer attach
on the surface.

> If so, the two solutions would be:
>   - the surface content should be preserved across leave/enter; Weston
> is buggy for not showing the content on re-enter
>   - mouse leave and your surface no longer being shown as a pointer
> surface causes the surface to lose that role; Wayland protocol spec
> should explicitly state this

Does losing the role imply the content is removed from the surface? If
so, yes, these are the only two options I can think of.

> I have a very slight lean towards the latter because it more closely
> matches my recollection of what the XDG roles do. But that
> recollection might be totally wrong, who knows.

I have no strong preference, though I won't have to fix my client code
to deal with the former. ;)

> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.15.91

[Derek Foreman]

This is the alpha for wayland 1.16.

It's not so large as the weston release, but still some notable changes
here:
The client definition of wl_global is removed - this really shouldn't
hurt anyone since it's been deprecated for a very long time.

Some long standing oddness has been fixed with destroy signals - this
should only be noticed in cases that were previously problematic.

The code generator now supports referencing foreign enums.

And let's not forget we're now hosted on gitlab and have CI. :)
(and the new contributing documentation is worth a read)

It may take a few minutes for the download URLs to work for both of
these releases.

Full change history:
Daniel Stone (2):
  Add .gitlab-ci.yml
  doc: Update URLs for GitLab transition

Derek Foreman (4):
  configure.ac: Reopen master for regular development
  tests: Test for use after free in resource destruction signals
  server: Add special case destroy signal emitter
  configure.ac: bump to version 1.15.91 for the alpha release

Dipen Somani (1):
  wayland-server: Properly handle EAGAIN from wl_connection_read()

Emil Velikov (1):
  .gitlab-ci.yml: collect the distcheck error logs

Markus Ongyerth (1):
  tests: Add free-without-remove test

Pekka Paalanen (9):
  doc: move Contributing
  contributing: format as markdown
  contributing: add review guidelines
  contributing: commit rights
  client: remove definition of wl_global
  contributing: how to read the review rules
  contributing: review rules for bugs
  contributing: about re-sending patches
  contributing: document the release cycle freezes

Simon Ser (2):
  scanner: allow referencing foreign enums
  doc: update IANA MIME types registry URL

git tag: 1.15.91

https://wayland.freedesktop.org/releases/wayland-1.15.91.tar.xz
MD5:  b61efaa03d90f335987fef008b3870ca  wayland-1.15.91.tar.xz
SHA1: 605c137b856d3f2c47b6ecbc41767338daf8568e  wayland-1.15.91.tar.xz
SHA256: 05c439613c21367936ea1835fa8f19bc148e879bb612bbe8cf6675d11819a711
 wayland-1.15.91.tar.xz
SHA512:
a3e5306e1a62793912a691e19d27c5925d8209bf047d3b7237fe278cc85705ec083a4e127e6acf10540e3d54bb58800c3f219353bb68a52f690d4f0d402b246f
 wayland-1.15.91.tar.xz
PGP: https://wayland.freedesktop.org/releases/wayland-1.15.91.tar.xz.sig

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 4.0.91

[Derek Foreman]

This is the alpha for weston 5.0.

Lots of changes from lots of people - highlights include, but certainly
aren't limited to:
The use of hardware planes in atomic mode setting
Clone mode, and all the infrastructure changes to make it possible
A new touchscreen calibrator


Full change history:
Ankit Nautiyal (3):
  man: add description for specifying modes with aspect-ratio in
weston.ini
  compositor-drm: Add aspect-ratio parsing support
  man: Remove description of DRM specific mode-options from
weston.ini.man

Daniel Stone (37):
  Add .gitlab-ci.yml
  simple-dmabuf-drm: Fallback DRM_FORMAT_MOD_LINEAR definition
  doc: Update for GitLab migration
  tests: Don't rely on build directory layout
  tests: Reshuffle IVI layout tests
  compositor-drm: Property accessor can be const
  compositor-drm: Remove unnecessary picked_scanout variable
  compositor-drm: Make alpha-to-opaque handling common
  compositor-drm: Extract buffer->plane co-ord translation
  compositor-drm: Fully account for buffer transformation
  compositor-drm: Only check final co-ordinates for overlay scaling
  compositor-drm: Use plane_state_coords_for_view for scanout
  compositor-drm: Use plane_state_coords_for_view for cursor
  compositor-drm: Extract overlay FB import to helper
  compositor-drm: Use plane FB-import helper for scanout
  compositor-drm: Extract drm_fb_addfb into a helper
  compositor-drm: Support modifiers for drm_fb
  compositor-drm: Define DPMS property as an enum
  compositor-drm: Avoid cast by using unsigned loop index
  compositor-drm: Don't set fb->size for non-dumb buffers
  helpers: Move static_assert definition to shared
  compositor-drm: Add modifiers to GBM dmabuf import
  compositor-drm: Use GBM modifier API
  compositor-drm: Split drm_assign_planes in two
  compositor-drm: Ignore views on other outputs
  compositor-drm: Ignore occluded views
  compositor-drm: Disallow overlapping overlay planes
  compositor-drm: Use sprites_are_broken for scanout plane
  compositor-drm: Add modes to drm_output_propose_state
  compositor-drm: Return plane state from plane preparation
  compositor-drm: Add test-only mode to state application
  compositor-drm: Never lift solid surfaces to planes
  compositor-drm: Add planes-only mode to state proposal
  compositor-drm: Incrementally test plane states in mixed mode
  compositor-drm: Allow scanout plane to be occluded by overlay
  compositor-drm: Relax plane restrictions for atomic
  compositor-drm: Enable planes for atomic

David Fort (1):
  rdp-compositor: fix compilation against FreeRDP 2.0.0 rc2

Derek Foreman (3):
  configure.ac: Reopen master for regular development
  configure.ac: Bump libweston version to match weston version
  configure.ac: bump to version 4.0.91 for the alpha release

Dima Ryazanov (1):
  Fix a crash when unlocking or unconfining a pointer

Emilio Pozuelo Monfort (2):
  simple-dmabuf-drm: require zwp_linux_dmabuf_v1 v3
  simple-dmabuf-drm: fix build with --disable-egl

Guido Günther (7):
  simple-dmabuf-drm: 0 is a valid fd (freedreno)
  simple-dmabuf-drm: simplify fd_map_bo
  simple-dmabuf-drm: support etnaviv drm as well
  simple-dmabuf-drm: drop superfluous declaration
  simple-dmabuf-drm: don't exit from create_display
  simple-dmabuf-drm: support DRM_FORMAT_LINEAR for NV12 as well
  compositor-drm: ignore case of {h,v}sync flags in modeline

Louis-Francis Ratté-Boulianne (7):
  libweston: fix weston_touch_start_grab() arg name
  input: introduce weston_touch_device
  input: move touchpoint counting up
  input: introduce touch event mode for calibrator
  libweston: implement touch calibration protocol
  weston: add touchscreen_calibrator option
  clients: add a new touchscreen calibrator

Markus Ongyerth (2):
  weston-info: Add support for tablet-unstable-v2
  weston-info: destroy wl_keyboard

Matheus Santana (1):
  man: remove redundant word in weston.ini(5)

Matt Hoosier (1):
  log: improve handling of use-before-init

Pekka Paalanen (109):
  libweston: introduce weston_head
  libweston: move wl_output to weston_head
  libweston: use head in wl_output global
  libweston: make wl_output point to weston_head
  libweston: refactor weston_mode_switch_finish
  libweston: introduce weston_output::head_list
  libweston: properly orphan wl_output resources
  libweston: strdup head make, model, serial_number
  cms-colord: find a good head
  libweston: add name to weston_head
  libweston: add weston_head::connected
  libweston: add weston_head_is_enabled()
  libweston: add compositor list of heads
  libweston: add heads_changed_signal
  libweston: new head-based output management API
  libweston: add weston_head destroy signal
  lib

Re: [PATCH wayland 1/4] contributing: how to read the review rules

[Derek Foreman]

On 2018-07-13 09:52 AM, Daniel Stone wrote:
> Hi,
> 
> On Tue, 3 Jul 2018 at 11:32, Pekka Paalanen  wrote:
>> This is to avoid fighting around the letter of the guidelines. This is
>> not a protocol spec.
> 
> Seems entirely sensible to me; thanks for writing this up!
> 
> Series is:
> Reviewed-by: Daniel Stone 

Agreed.

Reviewed-by: Derek Foreman 

I'll land the series right before I do the release today.

Thanks,
Derek

> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Upcoming release reminder

[Derek Foreman]

On 2018-07-03 04:33 PM, Derek Foreman wrote:
> Hi all,
>
> Just a quick reminder that we're due for alpha shortly, with the
> following intended release schedule:
I'd like to push this back to Friday, it looks like some atomic patches
are just about ready to land, and it seems a shame to block that with a
release schedule that was fairly arbitrarily advanced in the first place.

Let's just add 3 to every number in the original release plan, and do it
all on Fridays this time around.

Thanks,
Derek
> Alpha - July 10th
> Beta - July 24th
> RC1 - August 7th
> First possible release August 14th.
>
> Thanks,
> Derek


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Upcoming release reminder

[Derek Foreman]

Hi all,

Just a quick reminder that we're due for alpha shortly, with the
following intended release schedule:

Alpha - July 10th
Beta - July 24th
RC1 - August 7th
First possible release August 14th.

Thanks,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 0/2] Document review and commit access requirements

[Derek Foreman]

On 2018-06-18 08:42 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> Hi,
> 
> for years we have relied on unwritten traditions on how to review
> patches. Gaining commit access has been a secret rite no-one really knew
> what was required for to ask or grant it. I would dare claim that this
> has been partially the reason for why there are so few people who
> routinely review and land patches. At least I hope so, because
> "unwritten" is something we can fix.
> 
> Let's try to write down the existing conventions and criteria we use to
> review patches. These will not be rules to be followed to the letter but
> to the spirit.
> 
> Once we have documented guidelines for quality assurance on patch
> review, we can set up rules for granting commit rights. The movement to
> document commit rights requirements started in the kernel DRM commmunity
> as a tool to give out commits rights to more people and get more people
> involved and reviewing patches. I believe we would certainly want more
> people involved with Wayland and Weston, but it won't work if we don't
> also get more reviewers and committers.
> 
> So here goes. Documenting what is expected from reviewers and commmit
> rights holders should make everyone's lives easier. These patches are my
> first take on it, and build on others' as referenced. I want to ensure
> that I am replaceable. That everyone is.
> 
> The guidelines will not be perfect from the start. They should we honed
> over time.
> 
> 
> Thanks,
> pq
> 
> 
> Pekka Paalanen (2):
>   contributing: add review guidelines
>   contributing: commit rights

Really like these, and both are:
Reviewed-by: Derek Foreman 

I like Daniel's suggestions too, but am fine with those being follow up
work.

Thanks,
Derek

> 
>  CONTRIBUTING.md | 82 
> +
>  1 file changed, 82 insertions(+)
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Release schedule

[Derek Foreman]

On 2018-06-14 02:08 AM, Pekka Paalanen wrote:
> On Wed, 13 Jun 2018 21:05:03 -0400
> ferreiradaselva  wrote:
> 
>> Any chance of the XDG decoration protocol being part of this release plan?
> 
> Hi,
> 
> wayland-protocols is not part of this release plan. It is much more
> free to release at arbitrary times and usually does not go through a
> freeze period either.

Right, exactly that - I don't see a weston/wayland release having any
impact on XDG decoration protocol in any way.

> Unless you mean a Weston implementation of that?

Weston isn't always the first to implement new protocol anymore (xdg
shell stable, for example), so weston being released without an
implementation of XDG decoration won't grief any other compositor
wishing to do so.

At this point I've seen no other concerns about the proposed schedule on
or off list, so let's go with:

Alpha - July 10th
Beta - July 24th
RC1 - August 7th
First possible release August 14th.

This will be a combined weston + wayland release, but following this one
I think it's time to start releasing them independently.  That's a
discussion we can have in late August.

Thanks,
Derek

> 
> Thanks,
> pq
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Release schedule

[Derek Foreman]

On 2018-06-08 03:21 AM, Pekka Paalanen wrote:
> On Thu, 7 Jun 2018 15:45:00 -0500
> Derek Foreman  wrote:
> 
>> On 2018-06-04 07:14 AM, Daniel Stone wrote:
>>> Hi Pekka,
>>>
>>> On 4 June 2018 at 12:29, Pekka Paalanen  wrote:  
>>>> On Sun, 3 Jun 2018 10:52:49 +0100
>>>> Daniel Stone  wrote:  
>>>>> On 1 June 2018 at 17:52, Derek Foreman  wrote:
>>>>> Maybe? There's certainly a ton of change in the tree now, and a few
>>>>> more which look like they could land (IVI/XDG, the last bits of
>>>>> atomic, etc). It'd be a pretty hefty release whenever we released it.
>>>>> I don't have a strong opinion on when we get it out the door, to be
>>>>> honest.  
>>>>
>>>> for a project I'm working on, it would be very nice to get the current
>>>> Weston master released ASAP. OTOH, I'm on vacation from July 12 to
>>>> Aug 1, so I definitely won't be around at that time.  
>>>
>>> I know you didn't mean it like this, but I think it's good to be clear
>>> that this isn't a corporate demand to fix releases at a certain point.
>>> That user is just another one of our downstreams and another datapoint
>>> to take into consideration. (But a good one!)
>>>   
>>>> We have been in the development cycle for two months now. How would you
>>>> feel about trying to get, say, rc1 out around July 10?
>>>>
>>>> That would mean rc1 at five weeks from now. I could be around during the
>>>> alpha and beta time, hoping there wouldn't be much regressions to fix
>>>> after rc1.
>>>>
>>>> Is it too soon? How soon could we do it?  
>>>
>>> When does it mean alpha/beta?  
>>
>> I'm traveling from July 16-20, and will have very poor internet access.
>>
>> This would put as at:
>> Alpha June 12
>> Beta June 26
>> RC1 July 10
>> Final July 24 (normally we're 1 week between RCs but july 17 is
>> problematic for me.)
>>
>> So that's coming up fast.
> 
> Hi Derek,
> 
> very fast. Even too fast.
> 
> I suppose I could be happy with just alpha coming in a month, or at
> most in two months. I don't personally mind being on vacation during
> the freezes, but I though it would be nice for others to be around. I
> would also be ok if your travels were during some freeze period, we
> could extend it respectively.
> 
> Please, suggest a schedule you would be comfortable with.

Hmm, how about we enter alpha in the second week of July?
Alpha - July 10th
Beta - July 24th
RC1 - August 7th
First possible release August 14th.

Which pretty much puts you on holidays for most of the freeze.  I'm not
terrified by this, I think having you around prior is what's most important.

Is that still fast enough?

Thanks,
Derek

>>>> What do we want to have in the 5.0.0 release?  
>>>
>>> I'd want to have the rest of the 'atomic series' (now really about
>>> overlay plane usage & modifiers) in for sure. It's all got positive
>>> review and I have some very clearly and definitively carved-out time
>>> coming in the next week or two to spend on just getting that landed. I
>>> think it's pretty important to land as it does fix some bugs, and full
>>> modifier support is becoming more important: we need it in order to
>>> run on Etnaviv/i.MX at all, it helps RPi, and we don't get composition
>>> bypass / direct scanout for fullscreen windows on Intel anymore, since
>>> we need modifiers to describe the client buffers it generates from
>>> Mesa.  
>>
>> That looks like a fair bit of stuff - can we get there with the proposed
>> timeline or should we push back?
> 
> I think we should push the alpha back some, I'd like to see that stuff
> in too.
> 
>>> I also have some work on weston-debug and IVI shell coming up, but I
>>> don't think those will get finalised in the next couple of weeks, so
>>> I'm comfortable giving those more time.  
>>
>> grumble grumble xdg shell stable grumble.
>>
>>>> How long do we need for the alpha and beta stages?  
>>>
>>> I don't have a good answer to this one. I think we've traditionally
>>> done two weeks for each, right?  
>>
>> That's my recollection, at least for the last release.
> 
> Alright, sounds good to me.
> 
>>>>>> I think we also no longer need to rigidly release wayland and weston at
>>>>>> the same time, as wayland itself is quite mature and may not receive
>>>

Re: Release schedule

[Derek Foreman]

On 2018-06-04 07:14 AM, Daniel Stone wrote:
> Hi Pekka,
> 
> On 4 June 2018 at 12:29, Pekka Paalanen  wrote:
>> On Sun, 3 Jun 2018 10:52:49 +0100
>> Daniel Stone  wrote:
>>> On 1 June 2018 at 17:52, Derek Foreman  wrote:
>>> Maybe? There's certainly a ton of change in the tree now, and a few
>>> more which look like they could land (IVI/XDG, the last bits of
>>> atomic, etc). It'd be a pretty hefty release whenever we released it.
>>> I don't have a strong opinion on when we get it out the door, to be
>>> honest.
>>
>> for a project I'm working on, it would be very nice to get the current
>> Weston master released ASAP. OTOH, I'm on vacation from July 12 to
>> Aug 1, so I definitely won't be around at that time.
> 
> I know you didn't mean it like this, but I think it's good to be clear
> that this isn't a corporate demand to fix releases at a certain point.
> That user is just another one of our downstreams and another datapoint
> to take into consideration. (But a good one!)
> 
>> We have been in the development cycle for two months now. How would you
>> feel about trying to get, say, rc1 out around July 10?
>>
>> That would mean rc1 at five weeks from now. I could be around during the
>> alpha and beta time, hoping there wouldn't be much regressions to fix
>> after rc1.
>>
>> Is it too soon? How soon could we do it?
> 
> When does it mean alpha/beta?

I'm traveling from July 16-20, and will have very poor internet access.

This would put as at:
Alpha June 12
Beta June 26
RC1 July 10
Final July 24 (normally we're 1 week between RCs but july 17 is
problematic for me.)

So that's coming up fast.

>> Does it clash with the GitLab migration?
> 
> We've already moved the repos and the site. I think it would be good
> to move our issues just before the release, so by 5.0.0rc (or beta?)
> we had all our issues already in GitLab and could have that as a clean
> cut-off point. From my (migration) point of view, we can absolutely
> have Bugzilla migrated - we could pretty much do that now - and I'm
> moderately confident of having Phabricator migrated by then as well.
> But I don't think it's so bad even if the Phab migration does slip a
> little after the Bugzilla migration.
> 
> If we have split release cycles for Wayland and Weston, we can choose
> to migrate Wayland's bugs later if that makes sense.
> 
>> What do we want to have in the 5.0.0 release?
> 
> I'd want to have the rest of the 'atomic series' (now really about
> overlay plane usage & modifiers) in for sure. It's all got positive
> review and I have some very clearly and definitively carved-out time
> coming in the next week or two to spend on just getting that landed. I
> think it's pretty important to land as it does fix some bugs, and full
> modifier support is becoming more important: we need it in order to
> run on Etnaviv/i.MX at all, it helps RPi, and we don't get composition
> bypass / direct scanout for fullscreen windows on Intel anymore, since
> we need modifiers to describe the client buffers it generates from
> Mesa.

That looks like a fair bit of stuff - can we get there with the proposed
timeline or should we push back?

> I also have some work on weston-debug and IVI shell coming up, but I
> don't think those will get finalised in the next couple of weeks, so
> I'm comfortable giving those more time.

grumble grumble xdg shell stable grumble.

>> How long do we need for the alpha and beta stages?
> 
> I don't have a good answer to this one. I think we've traditionally
> done two weeks for each, right?

That's my recollection, at least for the last release.

>>>> I think we also no longer need to rigidly release wayland and weston at
>>>> the same time, as wayland itself is quite mature and may not receive
>>>> many significant patches during a weston cycle.  I'm wondering if
>>>> libwayland releases should break from timed cycles entirely?
>>>
>>> That sounds good to me. libwayland is so quiet that I don't think we
>>> need to force it out the door every so often; I think moving it out of
>>> forced major releases could get us actually doing patch releases as
>>> well, which would be nice.
>>
>> Sounds fine to me!

Nod, I think patch releases for libwayland make sense now.

So, let's sit on this a little bit to give anyone that thinks this
release comes too soon a chance to speak, and if nobody complains by
June 11 we can go with the June 12 to July 24 plan.

This is a bit of a surprise, so anyone with any reason feel free to stop
me - on or off list if you don't want to make a scene here. ;)

Also, there's been some small change in libwayland, s

Release schedule

[Derek Foreman]

Hi all,

Our last release for wayland and weston was April 9th, and there has
been some talk on IRC about release schedules, so maybe it's time to
start planning for the next one.

Previously it looks like we've been on a 6 month cycle with releases in
February and August.  Following that duration we'd be looking at an
October release.  It feels like there's already a lot of significant
change, so I'm not sure waiting til October makes sense?

Are we moving fast enough to do releases every 4 months instead of 6?

I think we also no longer need to rigidly release wayland and weston at
the same time, as wayland itself is quite mature and may not receive
many significant patches during a weston cycle.  I'm wondering if
libwayland releases should break from timed cycles entirely?

If nobody has any opinions, we'll continue the way things are and aim
for an October release of both wayland and weston.

Thanks,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] wayland-server: Properly handle EAGAIN from wl_connection_read()

[Derek Foreman]

On 2018-04-19 09:18 AM, Derek Foreman wrote:
> On 2018-04-19 09:01 AM, Derek Foreman wrote:
>> From: Dipen Somani <dipen.som...@samsung.com>
>>
>> commit 3cddb3c692acd3536a7cc8542a29f0cc3c0ac3d6 casted len to an
>> unsigned value to compare to sizeof results.  However,
>> wl_connection_read() can fail, setting errno to EAGAIN and returning
>> a value of -1.
>>
>> When cast to an unsigned type this leads to a loop condition of true
>> when it should be false.
>>
>> Signed-off-by: Dipen Somani <dipen.som...@samsung.com>
>> Signed-off-by: Derek Foreman <der...@osg.samsung.com>
> 
> I forgot to add:
> Reviewed-by: Derek Foreman <der...@osg.samsung.com>

And have now landed it.

Thanks,
Derek

>> ---
>>  src/wayland-server.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/wayland-server.c b/src/wayland-server.c
>> index eb1e500..eab2ee4 100644
>> --- a/src/wayland-server.c
>> +++ b/src/wayland-server.c
>> @@ -353,7 +353,7 @@ wl_client_connection_data(int fd, uint32_t mask, void 
>> *data)
>>  }
>>  }
>>  
>> -while ((size_t) len >= sizeof p) {
>> +while (len >= 0 && (size_t) len >= sizeof p) {
>>  wl_connection_copy(connection, p, sizeof p);
>>  opcode = p[1] & 0x;
>>  size = p[1] >> 16;
>>
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 0/3] Deal with destroy signal use after free issues

[Derek Foreman]

I've pushed this series now.

Thanks,
Derek

On 2018-04-16 03:00 PM, Derek Foreman wrote:
> Now that the release is out, I'd like to dig back into this mess.
> This is a round up of some patches that were on list shortly before
> the release to deal with a problem where many existing libwayland
> users don't delete their destroy signal listeners before freeing
> them.
> 
> These leads to a bit of a mess (as Markus' test illustrates) if there
> are multiple destroy listeners.
> 
> I've included:
> My test patch to ensure the existing behaviour continues to work
> (users like weston and enlightenment can free during destroy
> listener)
> 
> The special case destroy emit path for wl_priv_signal - this is
> an attempt to "fix" the problem, by making the destroy signal
> emit operate without ever touching potentially free()d elements
> again.
> 
> Markus' test that would fail without patch 2/3, as it catches the
> free() without removal case we've all come to know any love.
> 
> Derek Foreman (2):
>   tests: Test for use after free in resource destruction signals
>changes since first appearance: none
> 
>   server: Add special case destroy signal emitter
>changes since first appearance:  stop trying to maintain a list head
> 
> Markus Ongyerth (1):
>   tests: Add free-without-remove test
>changes since first appearance: I moved it into an existing file
> 
>  src/wayland-private.h  |  3 +++
>  src/wayland-server.c   | 46 +++---
>  tests/resources-test.c | 39 +++
>  3 files changed, 85 insertions(+), 3 deletions(-)
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 0/3] Deal with destroy signal use after free issues

[Derek Foreman]

On 2018-04-16 04:29 PM, Markus Ongyerth wrote:
> Hi,
> 
> Thanks for getting to this. I was waiting for the release, but I'm currently 
> not at full capacity, so you got it before me.
> 
> The commit message of patch 1 contains a lie. The second paragraph should 
> contain "IF there was only one listener object", which the testcase in Patch 
> 3 
> shows. But I don't think that's a deal breaker.

Oops, you're absolutely right, I didn't re-write the text after seeing
your test case.  Until then I hadn't thought about that case.  (I'm
still surprised it took us until now to actually hit this.)

If none object I'll correct that while landing.  If another revision is
required I'll update the text then.

> For Patch 1/2:
> Reviewed-by: Markus Ongyerth <w...@ongy.net>
> 
> I'm fine with moving/resubmit of my code and am happy I could provide the 
> testcase that shows an issue.
> Since it's originally authored by me, I guess my R-B would be weird there :)

I didn't put my R-B on it because I made a (mostly cosmetic) change to
it, and wasn't sure if that was ok.

Thanks,
Derek

> Cheers,
> ongy
> 
> On 2018/April/16 03:00, Derek Foreman wrote:
>> Now that the release is out, I'd like to dig back into this mess.
>> This is a round up of some patches that were on list shortly before
>> the release to deal with a problem where many existing libwayland
>> users don't delete their destroy signal listeners before freeing
>> them.
>>
>> These leads to a bit of a mess (as Markus' test illustrates) if there
>> are multiple destroy listeners.
>>
>> I've included:
>> My test patch to ensure the existing behaviour continues to work
>> (users like weston and enlightenment can free during destroy
>> listener)
>>
>> The special case destroy emit path for wl_priv_signal - this is
>> an attempt to "fix" the problem, by making the destroy signal
>> emit operate without ever touching potentially free()d elements
>> again.
>>
>> Markus' test that would fail without patch 2/3, as it catches the
>> free() without removal case we've all come to know any love.
>>
>> Derek Foreman (2):
>>   tests: Test for use after free in resource destruction signals
>>changes since first appearance: none
>>
>>   server: Add special case destroy signal emitter
>>changes since first appearance:  stop trying to maintain a list head
>>
>> Markus Ongyerth (1):
>>   tests: Add free-without-remove test
>>changes since first appearance: I moved it into an existing file
>>
>>  src/wayland-private.h  |  3 +++
>>  src/wayland-server.c   | 46 +++---
>>  tests/resources-test.c | 39 +++
>>  3 files changed, 85 insertions(+), 3 deletions(-)
>>
>> -- 
>> 2.14.3
>>

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 3/3] tests: Add free-without-remove test

[Derek Foreman]

From: Markus Ongyerth <w...@ongy.net>

[Derek Foreman <der...@osg.samsung.com> moved this into resources-test]

---

I moved this behind Markus' back, so let's not go landing it if he's
not ok with that change.  I think it's a great illustration of the
problem and would like to see it land though.

 tests/resources-test.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/tests/resources-test.c b/tests/resources-test.c
index 76c9eb8..fa6ba2b 100644
--- a/tests/resources-test.c
+++ b/tests/resources-test.c
@@ -182,3 +182,27 @@ TEST(create_resource_with_same_id)
wl_display_destroy(display);
close(s[1]);
 }
+
+static void
+display_destroy_notify(struct wl_listener *l, void *data)
+{
+   l->link.prev = l->link.next = NULL;
+}
+
+TEST(free_without_remove)
+{
+   struct wl_display *display;
+   struct wl_listener a, b;
+
+   display = wl_display_create();
+   a.notify = display_destroy_notify;
+   b.notify = display_destroy_notify;
+
+   wl_display_add_destroy_listener(display, );
+   wl_display_add_destroy_listener(display, );
+
+   wl_display_destroy(display);
+
+   assert(a.link.next == a.link.prev && a.link.next == NULL);
+   assert(b.link.next == b.link.prev && b.link.next == NULL);
+}
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 2/3] server: Add special case destroy signal emitter

[Derek Foreman]

In the past much code (weston, efl/enlightenment, mutter) has
freed structures containing wl_listeners from destroy handlers
without first removing the listener from the signal.  As the
destroy notifier only fires once, this has largely gone
unnoticed until recently.

Other code does not (Qt, wlroots) - and removes itself from
the signal before free.

If somehow a destroy signal is listened to by code from both
kinds of callers, those that free will corrupt the lists for
those that don't, and Bad Things will happen.

To avoid these bad things, remove every item from the signal list
during destroy emit, and put it in a list all its own.  This way
whether the listener is removed or not has no impact on the
following emits.

Signed-off-by: Derek Foreman <der...@osg.samsung.com>
---

Changes since v1:
 In v1 I went through some ugly steps to ensure wl_priv_signal_get()
 worked.  It seems this is actually a useless requirement, and the
 code is prettier without it.

 src/wayland-private.h |  3 +++
 src/wayland-server.c  | 46 +++---
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/src/wayland-private.h b/src/wayland-private.h
index 12b9032..29516ec 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -253,6 +253,9 @@ wl_priv_signal_get(struct wl_priv_signal *signal, 
wl_notify_func_t notify);
 void
 wl_priv_signal_emit(struct wl_priv_signal *signal, void *data);
 
+void
+wl_priv_signal_final_emit(struct wl_priv_signal *signal, void *data);
+
 void
 wl_connection_close_fds_in(struct wl_connection *connection, int max);
 
diff --git a/src/wayland-server.c b/src/wayland-server.c
index eb1e500..8c3b800 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -682,7 +682,7 @@ destroy_resource(void *element, void *data, uint32_t flags)
/* Don't emit the new signal for deprecated resources, as that would
 * access memory outside the bounds of the deprecated struct */
if (!resource_is_deprecated(resource))
-   wl_priv_signal_emit(>destroy_signal, resource);
+   wl_priv_signal_final_emit(>destroy_signal, resource);
 
if (resource->destroy)
resource->destroy(resource);
@@ -841,7 +841,7 @@ wl_client_destroy(struct wl_client *client)
 {
uint32_t serial = 0;
 
-   wl_priv_signal_emit(>destroy_signal, client);
+   wl_priv_signal_final_emit(>destroy_signal, client);
 
wl_client_flush(client);
wl_map_for_each(>objects, destroy_resource, );
@@ -1089,7 +1089,7 @@ wl_display_destroy(struct wl_display *display)
struct wl_socket *s, *next;
struct wl_global *global, *gnext;
 
-   wl_priv_signal_emit(>destroy_signal, display);
+   wl_priv_signal_final_emit(>destroy_signal, display);
 
wl_list_for_each_safe(s, next, >socket_list, link) {
wl_socket_destroy(s);
@@ -2025,6 +2025,46 @@ wl_priv_signal_emit(struct wl_priv_signal *signal, void 
*data)
}
 }
 
+/** Emit the signal for the last time, calling all the installed listeners
+ *
+ * Iterate over all the listeners added to this \a signal and call
+ * their \a notify function pointer, passing on the given \a data.
+ * Removing or adding a listener from within wl_priv_signal_emit()
+ * is safe, as is freeing the structure containing the listener.
+ *
+ * A large body of external code assumes it's ok to free a destruction
+ * listener without removing that listener from the list.  Mixing code
+ * that acts like this and code that doesn't will result in list
+ * corruption.
+ *
+ * We resolve this by removing each item from the list and isolating it
+ * in another list.  We discard it completely after firing the notifier.
+ * This should allow interoperability between code that unlinks its
+ * destruction listeners and code that just frees structures they're in.
+ *
+ */
+void
+wl_priv_signal_final_emit(struct wl_priv_signal *signal, void *data)
+{
+   struct wl_listener *l;
+   struct wl_list *pos;
+
+   /* During a destructor notifier isolate every list item before
+* notifying.  This renders harmless the long standing misuse
+* of freeing listeners without removing them, but allows
+* callers that do choose to remove them to interoperate with
+* ones that don't. */
+   while (!wl_list_empty(>listener_list)) {
+   pos = signal->listener_list.next;
+   l = wl_container_of(pos, l, link);
+
+   wl_list_remove(pos);
+   wl_list_init(pos);
+
+   l->notify(l, data);
+   }
+}
+
 /** \endcond INTERNAL */
 
 /** \cond */ /* Deprecated functions below. */
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 0/3] Deal with destroy signal use after free issues

[Derek Foreman]

Now that the release is out, I'd like to dig back into this mess.
This is a round up of some patches that were on list shortly before
the release to deal with a problem where many existing libwayland
users don't delete their destroy signal listeners before freeing
them.

These leads to a bit of a mess (as Markus' test illustrates) if there
are multiple destroy listeners.

I've included:
My test patch to ensure the existing behaviour continues to work
(users like weston and enlightenment can free during destroy
listener)

The special case destroy emit path for wl_priv_signal - this is
an attempt to "fix" the problem, by making the destroy signal
emit operate without ever touching potentially free()d elements
again.

Markus' test that would fail without patch 2/3, as it catches the
free() without removal case we've all come to know any love.

Derek Foreman (2):
  tests: Test for use after free in resource destruction signals
   changes since first appearance: none

  server: Add special case destroy signal emitter
   changes since first appearance:  stop trying to maintain a list head

Markus Ongyerth (1):
  tests: Add free-without-remove test
   changes since first appearance: I moved it into an existing file

 src/wayland-private.h  |  3 +++
 src/wayland-server.c   | 46 +++---
 tests/resources-test.c | 39 +++
 3 files changed, 85 insertions(+), 3 deletions(-)

-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EXT: [PATCH weston v6 00/73] Head-based output configuration API a.k.a clone mode infrastructure

[Derek Foreman]

On 2018-04-10 08:12 AM, Pekka Paalanen wrote:
> On Sat, 24 Mar 2018 10:16:12 +
> "Ray, Ian (GE Healthcare)" <ian@ge.com> wrote:
> 
>>> On 23 Mar 2018, at 19.16, Ray, Ian (GE Healthcare) <ian@ge.com> wrote:
>>>
>>>   
>>>> On 23 Mar 2018, at 15.12, Ray, Ian (GE Healthcare) <ian@ge.com> wrote:
>>>>
>>>>   
>>>>> On 16 Feb 2018, at 16.56, Pekka Paalanen <ppaala...@gmail.com> wrote:
>>>>>
>>>>> From: Pekka Paalanen <pekka.paala...@collabora.co.uk>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> here is the v6 of the shared-CRTC clone mode series. Since v5, quite
>>>>> many patches have been extracted from this series, sent out and merged
>>>>> upstream. However, now the series is bigger than ever, because here I am
>>>>> posting the complete series, including the full DRM-backend migration
>>>>> and DRM shared-CRTC clone mode implementation, thanks to having the
>>>>> basic atomic modesetting landed upstream.
>>>>>
>>>>> The previous submission is here:
>>>>> https://lists.freedesktop.org/archives/wayland-devel/2017-December/036236.html
>>>>>
>>>>> Design discussion etc. (sequence diagrams!) can be found here:
>>>>> https://phabricator.freedesktop.org/T7727
>>>>> https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
>>>>> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
>>>>>
>>>>> The series is available as a branch at:
>>>>> https://gitlab.collabora.com/pq/weston/commits/clonemode-6
>>>>>
>>>>> Highlights since v5:
>>>>> - DRM-backend migration
>>>>> - shared-CRTC clone mode implemented in DRM backend
>>>>> - applied review comments from v5
>>>>> - don't create a weston_output just to turn it off (DRM)
>>>>> - cms-colord will print a warning when used with clone mode
>>>>> - cms-colord vs. clone mode mentioned in weston-drm.man
>>>>>
>>>>> Unfortunately the testing results are not 100%, you can find my testing
>>>>> procedure below the diffstat.
>>>>>
>>>>> The patch series is structured as follows:
>>>>>
>>>>> - Patches 1-17 introduce most of the new head-based API, and build the
>>>>> scaffolding that allows migrating the frontends and the backends one
>>>>> by one.
>>>>>   
>>>>
>>>> Patches 01-17 : Reviewed-by Ian Ray <ian@ge.com>
>>>>
>>>>   
>>>>> - Patches 18-24 migrate the frontends one by one. Patch 19 introduces
>>>>> the simple output configurator which is first used for all backends,
>>>>> including the DRM-backend.
>>>>>
>>>>> - Patches 25-30 clean up libweston after the frontend migration.  
>>>
>>> Patches 18-30 : Reviewed-by Ian Ray <ian@ge.com>
>>>
>>>   
>>>>>
>>>>> - Patches 31-38 migrate all the backends to the head-based API. At this
>>>>> point the DRM-backend migration is basically a fake, though.
>>>>>
>>>>> - Patch 39 removes weston_output::head with the last bits of the
>>>>> scaffolding.  
>>
>> Patches 31-39 : Reviewed-by Ian Ray <ian@ge.com>
>>
>> (May I say that I am really enjoying the review so far.  The commits
>> are well structured and the commit messages are highly informative.)
> 
> Thank you very much for the reviews, Ian!
> 
> I have addressed your nitpicks and added your R-bs to the first 39
> patches you went through. These can be found in the branch:
> 
> https://gitlab.collabora.com/pq/weston/commits/clonemode-7-part1
> 
> I should probably test that a bit more before pushing.
> 
> Now I'd just need an Acked-by or two from our oldtimers to land that
> batch. After that there would be 34 patches left to review in this
> series.

Well, the whole series can certainly be
Acked-by: Derek Foreman <der...@osg.samsung.com>

though I might not find time to review it in the near future.

Thanks,
Derek

> 
> Thanks,
> pq
> 
>>>>>
>>>>> - Patches 40-44 enhances libweston core to better support the
>>>>> DRM-backend's clone mode configuration and improve logging.
>>>>>
>>>>> - Patche

[ANNOUNCE] wayland 1.15.0

[Derek Foreman]

Wayland 1.15.0 is now out.

Some highlights:
Compositor writers take note - wl_subcompositor.get_subsurface is now
documented to be double buffered.  It wasn't clearly specified to be so
before (this change should be non breaking in practice and merely remove
the opportunity for a render glitch in the compositor.)

New API, wl_display_destroy_clients() has been added to help some
compositors clean up clients before destroying their display.

wayland-scanner can now generate either public or private symbols, and
the old command line option "code" will emit a warning. It also has a
new --strict option to immediately exit on DTD validation failure.

libwayland-egl is now part of libwayland, and will presumably be removed
from mesa in the not too distant future.

The WAYLAND_DISPLAY environment variable can now contain absolute paths
(where previously it was prefixed by XDG_RUNTIME_DIR) - anything that
reads WAYLAND_DISPLAY outside of libwayland will have to deal with that
change independently.

Full change history:
Armin Krezović (1):
  Do not create man page links with doxygen

Bryce Harrington (1):
  Reopen master for regular development

Christopher James Halse Rogers (1):
  eventloop: clarify post_dispatch_check()

Daniel Stone (6):
  client: Use refcount exclusively for destruction
  client: Add wl_proxy_unref helper
  client: Plug a race in proxy destruction vs. dispatch
  wayland-egl: Pass nm path to check script
  wayland-egl: Make symbol test fail on failure
  wayland-egl: Ignore underscored symbols in ABI check

Derek Foreman (28):
  protocol: Suggest get_registry not be called frequently
  connection: close_fds() should only remove fds it closed from the
buffer
  client: Simplify some logic in queue_event
  connection: Use wl_buffer_size() for all buffer size calculations
  connection: Don't declare a local variable just to takes its size
  server: Log closure before sending it
  connection: Refactor out closure allocation
  connection: Clear fds we shouldn't close to -1
  connection: Make wl_closure_destroy() close fds of undispatched
closures
  util: Pass flags to map iterators
  client: Add wl_object_is_zombie() helper function
  client: Add WL_MAP_ENTRY_ZOMBIE flag
  client: Restructure delete_id handler control flow
  client: Remove WL_ZOMBIE_OBJECT global
  client: Replace the singleton zombie with bespoke zombies
  client: Consume file descriptors destined for zombie proxies
  tests: Add a test for fd leaks on zombie objects
  tests: Check for wrong fd delivery with zombie objects
  tests: Add missing file to distribution
  connection: Clear correct args when clearing fds to -1
  connection: Fix broken log message when demarshalling short closure
  scanner: Fix broken private-code generation
  configure.ac: bump to version 1.14.91 for the alpha release
  client: Don't inappropriatly close fds for zombie objects
  walyand-client: Fix trivial build break from previous commit
  configure.ac: bump to version 1.14.92 for the beta release
  configure.ac: bump to version 1.14.93 for the RC1 release
  configure.ac: bump to version 1.15.0 for the official release

Emil Velikov (26):
  scanner: remove unused scanner.mk
  scanner: use tabs for indentation.
  build: remove wayland-version.h.in from EXTRA_DIST
  wayland-server: document WL_HIDE_DEPRECATED
  cursor: add forward declaration for struct wl_buffer
  wayland-egl: import libwayland-egl.so frontend library from Mesa
  wayland-egl: reuse the existing WL_EXPORT macro
  wayland-egl: correct wayland-egl.pc description/version
  wayland-egl: introduce wayland-egl-backend.pc
  wayland-egl: add a note about keeping the backend version in sync
  build: wire-up wayland-egl
  wayland-egl-symbols-check: pass the DSO name via the build system
  wayland-egl: move the wayland-egl{, -core}.h headers to egl/
  wayland-egl: rename wl_egl_window::private to driver_private
  build: remove white space in -uninstalled.pc.in files
  scanner: introduce "public-code" and "private-code"
  build: use public-code when using the local wayland-scanner
  scanner: make use of __has_attribute()
  tests: add code, public-code and private-code tests
  wayland-egl: use correct `nm` path when cross-compiling
  configure.ac: don't install the static libraries
  wayland-egl: set the correct path to libwayland-egl.so
  wayland-egl: fail the symbol check if lib is missing
  wayland-egl: enhance the symbol test
  wayland-egl: bump the version number to 18.1.0
  .gitignore: add wayland-egl-abi-check

Emmanuel Gil Peyrot (2):
  tests: Add one more indentation level to some macros
  tests: Mark tests used so they don’t get removed at link time

Fiedler, Mathias (1):
  server: add log message when 

[ANNOUNCE] weston 4.0.0

[Derek Foreman]

  compositor-drm: Don't repaint if no damage
  compositor-drm: Add to_drm_mode helper
  xwayland: Explicitly link with xcb-shape
  compositor-drm: Track unused connectors and CRTCs
  compositor-drm: Disable unused CRTCs/connectors
  compositor-drm: Move repaint state application to flush
  compositor-drm: Use apply_state for starting repaint
  compositor-drm: Consistent failure paths for output creation
  compositor-drm: Don't restore original CRTC mode
  compositor-drm: Add blob_id member to drm_mode
  compositor-drm: Atomic modesetting support
  compositor-drm: Don't need safe view-list traversal
  compositor-drm: Rename region variable
  compositor-drm: Remove no_addfb2 handling
  compositor-wayland: Ignore pointer enter on destroyed surface
  terminal: Fix unintended fallthrough to cursor restore

David Fort (2):
  Fix API troubles with FreeRDP 2.0 v2
  rdp compositor: add a man page and add links to that page

Derek Foreman (18):
  clients: Don't crash when compositor doesn't support drag and drop
  dnd: Abort with an error message if compositor doesn't support
drag and drop
  weston-resizor: Don't add new frame callbacks every click
  desktop-shell: refactor maximized size calculation into its own
function
  desktop-shell: Handle the fullscreen to maximized case safely
  shared: Add a function to prefix filenames with datadir
  tests: Set WESTON_DATA_DIR for tests
  shared: Update all users of DATADIR
  build: Clean up -DDATADIR in makefiles
  xwayland: Fix crash on weston shutdown
  configure.ac: bump to version 3.0.91 for the alpha release
  libweston-desktop/xdg-shell-v6: Fix crash when surface has buffer
at creation
  configure.ac: bump to version 3.0.92 for the beta release
  xwm: Fix two more icon related memory leaks
  Revert "xwm: do not include shadow in input region"
  Partially revert "xwm: Add icon support to the frame" and friends
  configure.ac: bump to version 3.0.93 for the RC1 release
  configure.ac: bump to version 4.0.0 for the official release

Dima Ryazanov (2):
  weston: Add a help string for --xwayland
  Fix an uninitialized variable

Emil Velikov (3):
  gl-renderer: remove unneeded cast
  libweston: drop return type from ::query_dmabuf_{formats, modifiers}
  gl-renderer: make use of linux_dmabuf_buffer_get_user_data()

Emilio Pozuelo Monfort (1):
  tests: add a create_test_surface function

Emmanuel Gil Peyrot (7):
  tests: Add one more indentation level to some macros
  tests: Mark tests as used so they don’t get removed at link time
  weston-info: Add support for zwp_linux_dmabuf_v1
  Unconditionally add linux-dmabuf’s protocol to BUILT_SOURCES
  xwm: Add icon support to the frame
  xwm: Fix icon surface ownership
  autoconf: Remove configure line forgotten in
bb707dc0fe331c9af112a0552b7aa6fde755dd83

Emre Ucan (18):
  dmabuf: set modifier to invalid for not supporting clients
  ivi-shell: register ivi_layout_interface
  hmi-controller: remove ivi_layout_interface global
  hmi-controller: load as weston module
  tests: load ivi-shell test plugins as weston module
  ivi-shell: don't load controller modules
  ivi-shell: remove ivi_shell_setting
  ivi-shell: change layer visibility to bool
  ivi-shell: don't schedule compositor repaint
  ivi-shell: don't expilicitly assign outputs to views
  ivi-shell: fix the layer assignment change from one screen to another
  tests: fix a race condition in ivi-shell tests
  compositor-drm: remove dead assigment in drm_fb_create_dumb
  hmi-controller: remove dead assignments in add_launchers
  input: fix use-after-free issue at pointer_cancel
  gl-renderer: set num_images after import_simple_dmabuf
  compositor: initialize ret in repaint_timer_handler
  ivi-shell: remove dead assignments in layer transition

Eric Engestrom (3):
  clients/nested: fix boolean test
  config-parser: fix `short_name` type
  option-parser: replace int/0/1 with bool/false/true

Fabien Lahoudere (1):
  calibrator: Make mouse button optional

Greg V (2):
  Use $(SED) to make sure GNU sed is used
  compositor-drm: handle null cursor_plane

Guido Günther (10):
  configure.ac: drop spurious bracket
  simple-dmabuf-drm: allow multiple backends
  simpla-dmabuf-drm: Use more weston like coding style
  simple-dmabuf-drm: use vfunc for drm_device_destroy
  .gitignore weston-simple-dmabuf-drm
  Allow simple-dmabuf-drm to pass y_inverted flag
  simple-dmabuf-drm: use opt bitmask instead of is_immediate
  simple-dmabuf-drm: use getopt_long
  simple-dmabuf-drm: Always define ALIGN
  simple-dmabuf-drm: use appropriately sized buffer (freedreno)

Ian Ray (3):
  desktop-shell: use binding_modifier for zoom
  desktop-shell: disable opacity b

Re: [PATCH] terminal: Fix unintended fallthrough to cursor restore

[Derek Foreman]

On 2018-04-03 01:38 PM, Daniel Stone wrote:
> ef57a9b788 added support for window operations such as reporting the
> title in escape mode. It implemented this by which-window-op case,
> inside the existing which-escape-code case. Whilst it would break out of
> the former window-op case, it never broke out of the latter escape-code
> case. This would lead to window ops (such as reporting title) falling
> through to restoring the saved cursor position.
> 
> This doesn't seem at all right, and also fixes a warning with GCC 8.

Wow, that's been broken a while.

Seems obviously correct to me
Reviewed-by: Derek Foreman <der...@osg.samsung.com>

And pushed.

Thanks,
Derek

> 
> Signed-off-by: Daniel Stone <dani...@collabora.com>
> ---
>  clients/terminal.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/clients/terminal.c b/clients/terminal.c
> index 16a449540..f792badcd 100644
> --- a/clients/terminal.c
> +++ b/clients/terminal.c
> @@ -1686,6 +1686,7 @@ handle_escape(struct terminal *terminal)
>   fprintf(stderr, "Unimplemented windowOp %d\n", 
> args[0]);
>   break;
>   }
> + break;
>   case 'u':/* Restore cursor location */
>   terminal->row = terminal->saved_row;
>   terminal->column = terminal->saved_column;
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 3.0.93

[Derek Foreman]

This is the RC1 for the weston 4.0 release.

We've unfortunately had to revert some XWayland changes.  The icon code
still has some cosmetic issues that we don't have time to deal with
before release, so it has been temporarily removed.  Similarly, a fix
for XWayland input region calculations has also been removed until the
next release when there's more time to review the fixes.

If all goes well we're looking at an April 9th release date.

Derek Foreman (4):
  xwm: Fix two more icon related memory leaks
  Revert "xwm: do not include shadow in input region"
  Partially revert "xwm: Add icon support to the frame" and friends
  configure.ac: bump to version 3.0.93 for the RC1 release

Emre Ucan (6):
  compositor-drm: remove dead assigment in drm_fb_create_dumb
  hmi-controller: remove dead assignments in add_launchers
  input: fix use-after-free issue at pointer_cancel
  gl-renderer: set num_images after import_simple_dmabuf
  compositor: initialize ret in repaint_timer_handler
  ivi-shell: remove dead assignments in layer transition

Pekka Paalanen (1):
  Revert "xwm: Fix memory leak"

Scott Moreau (2):
  xwm: Fix memory leak
  xwm: Fix memory leak

git tag: 3.0.93

https://wayland.freedesktop.org/releases/weston-3.0.93.tar.xz
MD5:  a06fe44302b752be856b493b18594ac5  weston-3.0.93.tar.xz
SHA1: 97bd993f79f160c6a135c949a9dfb5453ce4332d  weston-3.0.93.tar.xz
SHA256: 8d2fd050d6b0cf990223788293f58781c1c1e08929cc679711eeaab717caf01d
 weston-3.0.93.tar.xz
SHA512:
cd40291517194d3f6eb0dd3f3d8d70c0c1da577eec5a30d787ac83484306e1fef7077521cd05b3b64a91ad702a1743286c5b33ebb55896e38bfc747e4a487c5d
 weston-3.0.93.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-3.0.93.tar.xz.sig




signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.14.93

[Derek Foreman]

This is the RC1 for the wayland 1.15 release.

If all goes well, the next release will be on Monday April 9th.

This release fixes make check under platforms (such as ARM) where our
ABI check test was broken.


Daniel Stone (1):
  wayland-egl: Ignore underscored symbols in ABI check

Derek Foreman (1):
  configure.ac: bump to version 1.14.93 for the RC1 release

Emil Velikov (1):
  .gitignore: add wayland-egl-abi-check

git tag: 1.14.93

https://wayland.freedesktop.org/releases/wayland-1.14.93.tar.xz
MD5:  57dc5715bbe3bf53043ef55b29a789e3  wayland-1.14.93.tar.xz
SHA1: 159f27e6f1a4e459903afebee42a2c0c9b6bf27f  wayland-1.14.93.tar.xz
SHA256: 62f649725a5ab73b528cd3a9283670942375c2486844ec21475d8a4031299d7f
 wayland-1.14.93.tar.xz
SHA512:
6d617b2025505e599c25c8a42062e7f78fe5bcbab58a96fcbc6afb54cf4b92e44a3f5a096c8d55e58539530f98a549f1cd20615c378cc591d50abdefa56b7656
 wayland-1.14.93.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.14.93.tar.xz.sig




signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 2/2] .gitignore: add wayland-egl-abi-check

[Derek Foreman]

On 2018-03-20 06:10 AM, Emil Velikov wrote:
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> Instruct git go ignore the file, in case we've done an in-tree build.
> 
> Cc: Derek Foreman <der...@osg.samsung.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
Reviewed-by: Derek Foreman <der...@osg.samsung.com>

And pushed.

Thanks,
Derek

> ---
> I've opted for the shortest fix - add an entry instead of renaming
> files, updating build rules, etc.
> 
> If people really want to we can opt for that route.
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 8da9861..eadea12 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -43,5 +43,6 @@ Makefile
>  Makefile.in
>  exec-fd-leak-checker
>  fixed-benchmark
> +/wayland-egl-abi-check
>  /wayland-scanner
>  protocol/*.[ch]
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2 weston] Partially revert "xwm: Add icon support to the frame" and friends

[Derek Foreman]

This (partially) reverts commit bef761796c2ada6344d227142af4a0f40b9760dd.
This (partially) reverts commit 4d1cd36c9ea041688f92cd8981e43b5fe3b52409.
This (partially) reverts commit 44fc1be913ab2faad0414f50e51d58310302d065.
This (partially) reverts commit 6b58ea8c43ac81e519bd418efbf24687a5d731b8.

The new xwm icon code has proven to be leaky and incomplete, and while
we have patches under consideration to fix the rest of its known problems
they still require changes and review cycles.  Currently the known
leaks have been squashed, but it still picks wrong sized icons and
does no scaling, which can lead to very strange rendering.  At window
close time the wrong sized icon appears above the window during fade out.

This patch reverts the mostly solid bits and keeps the unfinished
bits behind in favor of a simpler revert than removing the whole
thing.

Signed-off-by: Derek Foreman <der...@osg.samsung.com>
---

Changes from v1:

Only reverts the changes in window-manager.c (and updates frame_create call
to pass NULL for icon surface.

 xwayland/window-manager.c | 88 ++-
 1 file changed, 2 insertions(+), 86 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 62087941..06370b70 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -138,8 +138,6 @@ struct weston_wm_window {
xcb_window_t frame_id;
struct frame *frame;
cairo_surface_t *cairo_surface;
-   int icon;
-   cairo_surface_t *icon_surface; /* A temporary slot, to be passed to 
frame on creation */
uint32_t surface_id;
struct weston_surface *surface;
struct weston_desktop_xwayland_surface *shsurf;
@@ -475,7 +473,6 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
{ wm->atom.net_wm_state,   TYPE_NET_WM_STATE,  NULL 
},
{ wm->atom.net_wm_window_type, XCB_ATOM_ATOM,  
F(type) },
{ wm->atom.net_wm_name,XCB_ATOM_STRING,
F(name) },
-   { wm->atom.net_wm_icon,XCB_ATOM_CARDINAL,  
F(icon) },
{ wm->atom.net_wm_pid, XCB_ATOM_CARDINAL,  
F(pid) },
{ wm->atom.motif_wm_hints, TYPE_MOTIF_WM_HINTS,NULL 
},
{ wm->atom.wm_client_machine,  XCB_ATOM_WM_CLIENT_MACHINE, 
F(machine) },
@@ -976,10 +973,8 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
buttons |= FRAME_BUTTON_MAXIMIZE;
 
window->frame = frame_create(window->wm->theme,
-window->width, window->height,
-buttons, window->name,
-window->icon_surface);
-   window->icon_surface = NULL;
+window->width, window->height,
+buttons, window->name, NULL);
frame_resize_inside(window->frame, window->width, window->height);
 
weston_wm_window_get_frame_size(window, , );
@@ -1318,70 +1313,6 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
-static void
-handle_icon_surface_destroy(void *data)
-{
-   free(data);
-}
-
-static void
-weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
-{
-   xcb_get_property_reply_t *reply;
-   xcb_get_property_cookie_t cookie;
-   uint32_t length;
-   uint32_t *data, width, height;
-   cairo_surface_t *new_surface;
-
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
-   cookie = xcb_get_property(wm->conn, 0, window->id,
- wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
- UINT32_MAX);
-   reply = xcb_get_property_reply(wm->conn, cookie, NULL);
-   length = xcb_get_property_value_length(reply);
-
-   /* This is in 32-bit words, not in bytes. */
-   if (length < 2) {
-   free(reply);
-   return;
-   }
-
-   data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
-
-   /* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height) {
-   free(reply);
-   return;
-   }
-
-   new_surface =
-   cairo_image_surface_create_for_data((unsigned char *)data,
-   CAIRO_FORMAT_ARGB32,
-   width, height, width * 4);
-
-   /* Bail out in case anything wrong happened during surface creation. */
-   if (cairo_surface_status(new_surface) != CAIRO_STA

Re: [PATCH weston] Revert "xwm: Add icon support to the frame" and friends

[Derek Foreman]

On 2018-03-29 09:10 AM, Derek Foreman wrote:
> On 2018-03-29 08:59 AM, Derek Foreman wrote:
>> This reverts commit bef761796c2ada6344d227142af4a0f40b9760dd.
>> This (partially) reverts commit 4d1cd36c9ea041688f92cd8981e43b5fe3b52409.
>>  - the frame_destroy in weston_wm_window_destroy() remains
>> This reverts commit 44fc1be913ab2faad0414f50e51d58310302d065.
>> This (partially) reverts commit e277276b850bad39ed6995be5a82f24aa6b17bf1.
>>  - only the custom icon bits are removed
>> This reverts commit 6b58ea8c43ac81e519bd418efbf24687a5d731b8.
>>
>> The new xwm icon code has proven to be leaky and incomplete, and while
>> we have patches under consideration to fix the rest of its known problems
>> they still require changes and review cycles.  Reverting this all for now
>> for the upcoming release.
>>
> 
> Perhaps I should've been more clear as to what "incomplete" means in
> this commit log.
> 
> The current code will pick the first available icon unconditionally,
> regardless as to whether this fits on the titlebar, and no scaling is done.
> 
> So, as an example, here running terminology under xwayland will result
> in picking a 128x128 icon, and drawing it as a 16 high 128 wide piece of
> the icon on the title bar.  when the window closes for some reason the
> whole icon appears during fade out.
> 
> It all looks pretty embarrassing.
> 
> That said, all the known leaks have been fixed, it's just visually
> disappointing.

Quentin has suggested on IRC that it might be better to just land the
xwayland/window-manager.c parts of this revert and keep the rest.

I'd like to see if anyone else has opinions before I resubmit half this
patch for review.

Thanks,
Derek

> Thanks,
> Derek
> 
>> Signed-off-by: Derek Foreman <der...@osg.samsung.com>
>> ---
>>  clients/window.c   |  4 +-
>>  libweston/compositor-wayland.c |  2 +-
>>  shared/cairo-util.h|  6 +--
>>  shared/frame.c | 76 +---
>>  xwayland/window-manager.c  | 88 
>> +-
>>  5 files changed, 24 insertions(+), 152 deletions(-)
>>
>> diff --git a/clients/window.c b/clients/window.c
>> index bcf2b017..82fbd572 100644
>> --- a/clients/window.c
>> +++ b/clients/window.c
>> @@ -2523,7 +2523,7 @@ window_frame_create(struct window *window, void *data)
>>  
>>  frame = xzalloc(sizeof *frame);
>>  frame->frame = frame_create(window->display->theme, 0, 0,
>> -buttons, window->title, NULL);
>> +buttons, window->title);
>>  
>>  frame->widget = window_add_widget(window, frame);
>>  frame->child = widget_add_widget(frame->widget, data);
>> @@ -5398,7 +5398,7 @@ create_menu(struct display *display,
>>  menu->user_data = user_data;
>>  menu->widget = window_add_widget(menu->window, menu);
>>  menu->frame = frame_create(window->display->theme, 0, 0,
>> -   FRAME_BUTTON_NONE, NULL, NULL);
>> +   FRAME_BUTTON_NONE, NULL);
>>  fail_on_null(menu->frame, 0, __FILE__, __LINE__);
>>  menu->entries = entries;
>>  menu->count = count;
>> diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
>> index 111c4c09..5629b7f4 100644
>> --- a/libweston/compositor-wayland.c
>> +++ b/libweston/compositor-wayland.c
>> @@ -869,7 +869,7 @@ wayland_output_set_windowed(struct wayland_output 
>> *output)
>>  return -1;
>>  }
>>  output->frame = frame_create(b->theme, 100, 100,
>> - FRAME_BUTTON_CLOSE, output->title, NULL);
>> + FRAME_BUTTON_CLOSE, output->title);
>>  if (!output->frame)
>>  return -1;
>>  
>> diff --git a/shared/cairo-util.h b/shared/cairo-util.h
>> index 6fd11f6b..9481e58c 100644
>> --- a/shared/cairo-util.h
>> +++ b/shared/cairo-util.h
>> @@ -126,7 +126,7 @@ enum {
>>  
>>  struct frame *
>>  frame_create(struct theme *t, int32_t width, int32_t height, uint32_t 
>> buttons,
>> - const char *title, cairo_surface_t *icon);
>> + const char *title);
>>  
>>  void
>>  frame_destroy(struct frame *frame);
>> @@ -135,10 +135,6 @@ frame_destroy(struct frame *frame);
>>  int
>>  frame_set_title(struct frame *frame, const char *title);
>>  
>> -/* May set FRAME_STA

Re: [PATCH weston] Revert "xwm: Add icon support to the frame" and friends

[Derek Foreman]

On 2018-03-29 08:59 AM, Derek Foreman wrote:
> This reverts commit bef761796c2ada6344d227142af4a0f40b9760dd.
> This (partially) reverts commit 4d1cd36c9ea041688f92cd8981e43b5fe3b52409.
>  - the frame_destroy in weston_wm_window_destroy() remains
> This reverts commit 44fc1be913ab2faad0414f50e51d58310302d065.
> This (partially) reverts commit e277276b850bad39ed6995be5a82f24aa6b17bf1.
>  - only the custom icon bits are removed
> This reverts commit 6b58ea8c43ac81e519bd418efbf24687a5d731b8.
> 
> The new xwm icon code has proven to be leaky and incomplete, and while
> we have patches under consideration to fix the rest of its known problems
> they still require changes and review cycles.  Reverting this all for now
> for the upcoming release.
> 

Perhaps I should've been more clear as to what "incomplete" means in
this commit log.

The current code will pick the first available icon unconditionally,
regardless as to whether this fits on the titlebar, and no scaling is done.

So, as an example, here running terminology under xwayland will result
in picking a 128x128 icon, and drawing it as a 16 high 128 wide piece of
the icon on the title bar.  when the window closes for some reason the
whole icon appears during fade out.

It all looks pretty embarrassing.

That said, all the known leaks have been fixed, it's just visually
disappointing.

Thanks,
Derek

> Signed-off-by: Derek Foreman <der...@osg.samsung.com>
> ---
>  clients/window.c   |  4 +-
>  libweston/compositor-wayland.c |  2 +-
>  shared/cairo-util.h|  6 +--
>  shared/frame.c | 76 +---
>  xwayland/window-manager.c  | 88 
> +-
>  5 files changed, 24 insertions(+), 152 deletions(-)
> 
> diff --git a/clients/window.c b/clients/window.c
> index bcf2b017..82fbd572 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -2523,7 +2523,7 @@ window_frame_create(struct window *window, void *data)
>  
>   frame = xzalloc(sizeof *frame);
>   frame->frame = frame_create(window->display->theme, 0, 0,
> - buttons, window->title, NULL);
> + buttons, window->title);
>  
>   frame->widget = window_add_widget(window, frame);
>   frame->child = widget_add_widget(frame->widget, data);
> @@ -5398,7 +5398,7 @@ create_menu(struct display *display,
>   menu->user_data = user_data;
>   menu->widget = window_add_widget(menu->window, menu);
>   menu->frame = frame_create(window->display->theme, 0, 0,
> -FRAME_BUTTON_NONE, NULL, NULL);
> +FRAME_BUTTON_NONE, NULL);
>   fail_on_null(menu->frame, 0, __FILE__, __LINE__);
>   menu->entries = entries;
>   menu->count = count;
> diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
> index 111c4c09..5629b7f4 100644
> --- a/libweston/compositor-wayland.c
> +++ b/libweston/compositor-wayland.c
> @@ -869,7 +869,7 @@ wayland_output_set_windowed(struct wayland_output *output)
>   return -1;
>   }
>   output->frame = frame_create(b->theme, 100, 100,
> -  FRAME_BUTTON_CLOSE, output->title, NULL);
> +  FRAME_BUTTON_CLOSE, output->title);
>   if (!output->frame)
>   return -1;
>  
> diff --git a/shared/cairo-util.h b/shared/cairo-util.h
> index 6fd11f6b..9481e58c 100644
> --- a/shared/cairo-util.h
> +++ b/shared/cairo-util.h
> @@ -126,7 +126,7 @@ enum {
>  
>  struct frame *
>  frame_create(struct theme *t, int32_t width, int32_t height, uint32_t 
> buttons,
> - const char *title, cairo_surface_t *icon);
> +  const char *title);
>  
>  void
>  frame_destroy(struct frame *frame);
> @@ -135,10 +135,6 @@ frame_destroy(struct frame *frame);
>  int
>  frame_set_title(struct frame *frame, const char *title);
>  
> -/* May set FRAME_STATUS_REPAINT */
> -void
> -frame_set_icon(struct frame *frame, cairo_surface_t *icon);
> -
>  /* May set FRAME_STATUS_REPAINT */
>  void
>  frame_set_flag(struct frame *frame, enum frame_flag flag);
> diff --git a/shared/frame.c b/shared/frame.c
> index e8a5cad6..83bd7922 100644
> --- a/shared/frame.c
> +++ b/shared/frame.c
> @@ -109,9 +109,9 @@ struct frame {
>  };
>  
>  static struct frame_button *
> -frame_button_create_from_surface(struct frame *frame, cairo_surface_t *icon,
> - enum frame_status status_effect,
> - enum frame_button_flags flags)
> +frame_button_

[PATCH weston] Revert "xwm: Add icon support to the frame" and friends

[Derek Foreman]

This reverts commit bef761796c2ada6344d227142af4a0f40b9760dd.
This (partially) reverts commit 4d1cd36c9ea041688f92cd8981e43b5fe3b52409.
 - the frame_destroy in weston_wm_window_destroy() remains
This reverts commit 44fc1be913ab2faad0414f50e51d58310302d065.
This (partially) reverts commit e277276b850bad39ed6995be5a82f24aa6b17bf1.
 - only the custom icon bits are removed
This reverts commit 6b58ea8c43ac81e519bd418efbf24687a5d731b8.

The new xwm icon code has proven to be leaky and incomplete, and while
we have patches under consideration to fix the rest of its known problems
they still require changes and review cycles.  Reverting this all for now
for the upcoming release.

Signed-off-by: Derek Foreman <der...@osg.samsung.com>
---
 clients/window.c   |  4 +-
 libweston/compositor-wayland.c |  2 +-
 shared/cairo-util.h|  6 +--
 shared/frame.c | 76 +---
 xwayland/window-manager.c  | 88 +-
 5 files changed, 24 insertions(+), 152 deletions(-)

diff --git a/clients/window.c b/clients/window.c
index bcf2b017..82fbd572 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -2523,7 +2523,7 @@ window_frame_create(struct window *window, void *data)
 
frame = xzalloc(sizeof *frame);
frame->frame = frame_create(window->display->theme, 0, 0,
-   buttons, window->title, NULL);
+   buttons, window->title);
 
frame->widget = window_add_widget(window, frame);
frame->child = widget_add_widget(frame->widget, data);
@@ -5398,7 +5398,7 @@ create_menu(struct display *display,
menu->user_data = user_data;
menu->widget = window_add_widget(menu->window, menu);
menu->frame = frame_create(window->display->theme, 0, 0,
-  FRAME_BUTTON_NONE, NULL, NULL);
+  FRAME_BUTTON_NONE, NULL);
fail_on_null(menu->frame, 0, __FILE__, __LINE__);
menu->entries = entries;
menu->count = count;
diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
index 111c4c09..5629b7f4 100644
--- a/libweston/compositor-wayland.c
+++ b/libweston/compositor-wayland.c
@@ -869,7 +869,7 @@ wayland_output_set_windowed(struct wayland_output *output)
return -1;
}
output->frame = frame_create(b->theme, 100, 100,
-FRAME_BUTTON_CLOSE, output->title, NULL);
+FRAME_BUTTON_CLOSE, output->title);
if (!output->frame)
return -1;
 
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 6fd11f6b..9481e58c 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -126,7 +126,7 @@ enum {
 
 struct frame *
 frame_create(struct theme *t, int32_t width, int32_t height, uint32_t buttons,
- const char *title, cairo_surface_t *icon);
+const char *title);
 
 void
 frame_destroy(struct frame *frame);
@@ -135,10 +135,6 @@ frame_destroy(struct frame *frame);
 int
 frame_set_title(struct frame *frame, const char *title);
 
-/* May set FRAME_STATUS_REPAINT */
-void
-frame_set_icon(struct frame *frame, cairo_surface_t *icon);
-
 /* May set FRAME_STATUS_REPAINT */
 void
 frame_set_flag(struct frame *frame, enum frame_flag flag);
diff --git a/shared/frame.c b/shared/frame.c
index e8a5cad6..83bd7922 100644
--- a/shared/frame.c
+++ b/shared/frame.c
@@ -109,9 +109,9 @@ struct frame {
 };
 
 static struct frame_button *
-frame_button_create_from_surface(struct frame *frame, cairo_surface_t *icon,
- enum frame_status status_effect,
- enum frame_button_flags flags)
+frame_button_create(struct frame *frame, const char *icon,
+   enum frame_status status_effect,
+   enum frame_button_flags flags)
 {
struct frame_button *button;
 
@@ -119,7 +119,12 @@ frame_button_create_from_surface(struct frame *frame, 
cairo_surface_t *icon,
if (!button)
return NULL;
 
-   button->icon = icon;
+   button->icon = cairo_image_surface_create_from_png(icon);
+   if (!button->icon) {
+   free(button);
+   return NULL;
+   }
+
button->frame = frame;
button->flags = flags;
button->status_effect = status_effect;
@@ -129,30 +134,6 @@ frame_button_create_from_surface(struct frame *frame, 
cairo_surface_t *icon,
return button;
 }
 
-static struct frame_button *
-frame_button_create(struct frame *frame, const char *icon_name,
-enum frame_status status_effect,
-enum frame_button_flags flags)
-{
-   struct frame_button *button;
-   cairo_surface_t *icon;
-
-   icon = cairo_image_surface_

Re: [PATCH v5 weston] xwm: Choose icon closest to target size

[Derek Foreman]

Since this is a little further from landing than I thought, as is the
scaling patch, I think the best move for the short term is to revert the
icon stuff entirely and move forward after the release.

Thanks,
Derek

On 2018-03-29 04:17 AM, Pekka Paalanen wrote:
> On Tue, 27 Mar 2018 12:43:36 -0500
> Derek Foreman <der...@osg.samsung.com> wrote:
> 
>> Xwayland clients can offer multiple icon sizes in no particular order.
>> Previously xwm was selecting the first one unconditionally. This patch
>> selects the icon that matches the size closest to the target size. The
>> target size is hard coded to 16 since there is only one theme and the
>> data used to create the theme is hard coded.
>>
>> Co-authored-by: Scott Moreau <ore...@gmail.com>
>>
> 
> Missing signed-off-by.
> 
> Scott, are you happy with your attribution here?
> 
> 
>> ---
>>
>> Changed in v2:
>>
>> - Fix typo setting width to height
>>
>> Changed in v3:
>>
>> - Move checks for malformed input into data handling function
>>
>> Changed in v4:
>>
>> - #define XWM_ICON_SIZE in this patch and do not #undef it
>> - Start with first icon found before choosing icon\
>> - Check for NULL data in get_icon_size_from_data()
>>
>> Changed in v5:
>> - remove allocations, process in a single pass
>> - rebase on top of memory leak fix
>>
>>  xwayland/window-manager.c | 51 
>> ---
>>  1 file changed, 44 insertions(+), 7 deletions(-)
>>
>> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>> index dad117fa..5209ac66 100644
>> --- a/xwayland/window-manager.c
>> +++ b/xwayland/window-manager.c
>> @@ -127,6 +127,8 @@ struct motif_wm_hints {
>>  #define _NET_WM_MOVERESIZE_MOVE_KEYBOARD10   /* move via keyboard */
>>  #define _NET_WM_MOVERESIZE_CANCEL   11   /* cancel operation */
>>  
>> +#define XWM_ICON_SIZE 16 /* width and height of frame icon */
>> +
>>  struct weston_output_weak_ref {
>>  struct weston_output *output;
>>  struct wl_listener destroy_listener;
>> @@ -1352,6 +1354,44 @@ weston_wm_window_schedule_repaint(struct 
>> weston_wm_window *window)
>> weston_wm_window_do_repaint, window);
>>  }
>>  
>> +static uint32_t *
>> +get_icon_size_from_data(int target_width, int target_height,
>> +uint32_t *width, uint32_t *height,
>> +uint32_t length, uint32_t *data)
> 
> This may be a static function, but it really needs doxygen doc to
> explain all the arguments and return value, particularly for 'length',
> see below.
> 
>> +{
>> +uint32_t *d = data, *ret = NULL, w, h;
>> +int a1, a2, a3;
> 
> I'd really like better names than a1, a2, a3. There are so many
> variables in this function that they need descriptive names.
> 
>> +
>> +if (!data)
>> +return NULL;
>> +
>> +/* Choose closest match by comparing icon dimension areas */
>> +a1 = target_width * target_height;
>> +
>> +*width = *height = 0;
>> +
>> +while (d - data < length / 4) {
> 
> Maybe using
>   uint32_t *end = data + length;
> would make this easier to read.
> 
> Isn't length/4 wrong, because length is already in uint32_t units by
> the caller?
> 
>> +w = *d++;
>> +h = *d++;
>> +
>> +/* Some checks against malformed input. */
>> +if (w == 0 || h == 0 || length < 2 + w * h)
> 
> Checking against 'length' is incorrect, because we need to be checking
> against the remaining length, not against the whole length, as we may
> have skipped an icon alrady. Checking against 'end' would help here too.
> 
>> +return ret;
>> +
>> +a2 = w * h;
>> +a3 = *width * *height;
>> +if (!a3 || abs(a2 - a1) < abs(a3 - a1)) {
>> +*width = w;
>> +*height = h;
>> +ret = d;
>> +}
>> +
>> +d += a2;
> 
> The computations here seem to be correct.
> 
>> +}
>> +
>> +return ret;
>> +}
>> +
>>  static void
>>  handle_icon_surface_destroy(void *data)
>>  {
>> @@ -1367,9 +1407,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
>> weston_wm_window *window)
>>  uint32_t *data, width, height;
>>  cairo_surface_t *new_surface;
>>  
>> -/*

Re: [PATCH v2] xwm: Update input region on resize

[Derek Foreman]

On 2018-03-28 12:55 AM, Ray, Ian (GE Healthcare) wrote:
> On 27/03/2018, 21.50, "wayland-devel on behalf of Derek Foreman" 
> <wayland-devel-boun...@lists.freedesktop.org on behalf of 
> der...@osg.samsung.com> wrote:
>>
>> Hey everyone,
>>
>> I've added Ian Ray to CC as the author of commit 332d1892bbb (xwm: do
>> not include shadow in input region)
>>
>> I think at this point reverting that patch for release is our most
>> sensible move.  We don't seem to have much forward progress on the
>> horrible bug it's introduced.  (Resizing an xwayland client doesn't
>> update input region)
>>
>> If there are no fixes forthcoming I'd like to revert commit 332d1892bbb
>> before RC1 (which is still scheduled for release on Monday, April 2).
> 
> Agreed.
> 
> (FWIW, my submission* was marked RFC, and as such was not as thoroughly
> tested as it should have been.)

I can see why it landed, it looks trivially correct to me too. :/

> [*] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-December/036402.html

Thanks for this - I couldn't find the thread because the commit landed
with a revised name.  I wasn't sure how to produce the bug it was
intended to fix.

I've reverted the patch for now.  Hopefully it can be revisited after
release with input regions handled on window resize (as the patch in
this thread intends to do).

Thanks,
Derek

> 
>> Thanks,
>> Derek
>>
>> On 2018-03-19 03:20 PM, Scott Moreau wrote:
>>>
>>>
>>> On Mon, Mar 19, 2018 at 1:13 PM, Derek Foreman <der...@osg.samsung.com
>>> <mailto:der...@osg.samsung.com>> wrote:
>>>
>>> On 2018-03-16 06:42 PM, Scott Moreau wrote:
>>>
>>> Hi Pekka,
>>>
>>> On Fri, Mar 16, 2018 at 9:20 AM, Pekka Paalanen
>>> <ppaala...@gmail.com <mailto:ppaala...@gmail.com>
>>> <mailto:ppaala...@gmail.com <mailto:ppaala...@gmail.com>>> wrote:
>>>
>>> On Tue, 13 Mar 2018 21:22:04 -0600
>>> Scott Moreau <ore...@gmail.com <mailto:ore...@gmail.com>
>>> <mailto:ore...@gmail.com <mailto:ore...@gmail.com>>> wrote:
>>>
>>> > Commit 332d1892 introduced a bug because the window was
>>> > shaped only when the frame was created, leaving the input
>>> > region unchanged regardless if the window was resized.
>>> > This patch updates the input region shape on resize,
>>> > fixing the problem.
>>> >
>>> > ---
>>> >
>>> > Changed in v2:
>>> >
>>> > - Bail in shape function if (window->override_redirect ||
>>> !window->frame)
>>> > - Call shape function from send_configure()
>>> >
>>> >  xwayland/window-manager.c | 53
>>> +--
>>> >  1 file changed, 33 insertions(+), 20 deletions(-)
>>>
>>> Hi,
>>>
>>> while trying to wrap my head around this, I started feeling
>>> dizzy. For
>>> real. So I have to keep this short.
>>>
>>>
>>> I think this is what happens when trying to sync two display
>>> servers.
>>>
>>>
>>> The first decision we should make is, do we want a quick
>>> patch for an
>>> immediate issue at hand, or do we want to make things better
>>> in the long
>>> run. Taking in this patch as is seems to be the former to
>>> me, and given
>>> the phase of the release cycle can be justified.
>>>
>>> The following mind flow is for a long term solution, and the
>>> comments
>>> inlined with the code below are for the quick patch.
>>>
>>>
>>> FWIW, I'd be open to landing something quick at this point.  The bug
>>> it fixes seems hugely annoying.  I resize an xterm, and I can't
>>> click in the new area.
>>>
>>> Alternately, I'm wondering if we should consider reverting the patch
>>> that introduced this bug?  I guess it wasn't tested well enough, and
>>> this behaviour seems more painful than what it was intended to fix?
>>>
>>>
>>&g

Re: [PATCH weston] xwm: Fix two more icon related memory leaks

[Derek Foreman]

On 2018-03-28 08:56 AM, Pekka Paalanen wrote:
> On Tue, 27 Mar 2018 11:09:32 -0500
> Derek Foreman <der...@osg.samsung.com> wrote:
> 
>> Hopefully sort the last leaks introduced in commit 6b58ea8c
>>
>> The window could be destroyed before it had a frame but after it had an icon
>> (I could trigger this with firefox), and the window could be assigned an icon
>> twice before it had a frame (I could trigger this with terminology).
>>
>> The latter leak was
>> Reported-by: Scott Moreau <ore...@gmail.com>
>>
>> Signed-off-by: Derek Foreman <der...@osg.samsung.com>
>> ---
>>  xwayland/window-manager.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
>> index dad117fa..7b98e140 100644
>> --- a/xwayland/window-manager.c
>> +++ b/xwayland/window-manager.c
>> @@ -1404,6 +1404,9 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
>> weston_wm_window *window)
>>  return;
>>  }
>>  
>> +if (window->icon_surface)
>> +cairo_surface_destroy(window->icon_surface);
>> +
>>  cairo_surface_set_user_data(new_surface, NULL, reply,
>>  _icon_surface_destroy);
>>  
>> @@ -1506,6 +1509,8 @@ weston_wm_window_destroy(struct weston_wm_window 
>> *window)
>>  wl_event_source_remove(window->repaint_source);
>>  if (window->cairo_surface)
>>  cairo_surface_destroy(window->cairo_surface);
>> +if (window->icon_surface)
>> +cairo_surface_destroy(window->icon_surface);
>>  
>>  if (window->frame_id) {
>>  xcb_reparent_window(wm->conn, window->id, wm->wm_window, 0, 0);
> 
> 
> Reviewed-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>

Thanks, I've pushed it now.

> 
> Thanks,
> pq
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] xwm: Update input region on resize

[Derek Foreman]

Hey everyone,

I've added Ian Ray to CC as the author of commit 332d1892bbb (xwm: do
not include shadow in input region)

I think at this point reverting that patch for release is our most
sensible move.  We don't seem to have much forward progress on the
horrible bug it's introduced.  (Resizing an xwayland client doesn't
update input region)

If there are no fixes forthcoming I'd like to revert commit 332d1892bbb
before RC1 (which is still scheduled for release on Monday, April 2).

Thanks,
Derek

On 2018-03-19 03:20 PM, Scott Moreau wrote:
> 
> 
> On Mon, Mar 19, 2018 at 1:13 PM, Derek Foreman <der...@osg.samsung.com
> <mailto:der...@osg.samsung.com>> wrote:
> 
> On 2018-03-16 06:42 PM, Scott Moreau wrote:
> 
> Hi Pekka,
> 
> On Fri, Mar 16, 2018 at 9:20 AM, Pekka Paalanen
> <ppaala...@gmail.com <mailto:ppaala...@gmail.com>
> <mailto:ppaala...@gmail.com <mailto:ppaala...@gmail.com>>> wrote:
> 
>     On Tue, 13 Mar 2018 21:22:04 -0600
>     Scott Moreau <ore...@gmail.com <mailto:ore...@gmail.com>
> <mailto:ore...@gmail.com <mailto:ore...@gmail.com>>> wrote:
> 
>     > Commit 332d1892 introduced a bug because the window was
>     > shaped only when the frame was created, leaving the input
>     > region unchanged regardless if the window was resized.
>     > This patch updates the input region shape on resize,
>     > fixing the problem.
>     >
>     > ---
>     >
>     > Changed in v2:
>     >
>     > - Bail in shape function if (window->override_redirect ||
> !window->frame)
>     > - Call shape function from send_configure()
>     >
>     >  xwayland/window-manager.c | 53
> +--
>     >  1 file changed, 33 insertions(+), 20 deletions(-)
> 
>     Hi,
> 
>     while trying to wrap my head around this, I started feeling
> dizzy. For
>     real. So I have to keep this short.
> 
> 
> I think this is what happens when trying to sync two display
> servers.
> 
> 
>     The first decision we should make is, do we want a quick
> patch for an
>     immediate issue at hand, or do we want to make things better
> in the long
>     run. Taking in this patch as is seems to be the former to
> me, and given
>     the phase of the release cycle can be justified.
> 
>     The following mind flow is for a long term solution, and the
> comments
>     inlined with the code below are for the quick patch.
> 
> 
> FWIW, I'd be open to landing something quick at this point.  The bug
> it fixes seems hugely annoying.  I resize an xterm, and I can't
> click in the new area.
> 
> Alternately, I'm wondering if we should consider reverting the patch
> that introduced this bug?  I guess it wasn't tested well enough, and
> this behaviour seems more painful than what it was intended to fix?
> 
> 
> I think a revert would be a good place to start. The patch also has
> whitespace that does not match surrounding code.
> 
> To clarify the bug, start an xwayland window and resize it to a larger
> dimension. Mouse input will only work for the size of the window before
> resize. The rest of the window does not respond to input.
> 
> Thanks,
> Scott
>  
> 
> 
> 
> 
>     Taking a step back, the aim to keep the input shape
> up-to-date whenever
>     something happens.
> 
>     If we have a frame window with decorations, then we call
>     frame_resize_inside() to adjust its size. Would it not be
> logical to
>     set the input shape in at least all those cases?
> 
> 
> Yes, maybe there can be a function that calls
> frame_resize_inside and the shape function to replace calls to
> frame_resize_inside.
> 
> 
>     Except it looks like we can have decorated O-R windows, and
> those
>     should be exempt? Oh, I'm told decorated O-R windows don't
> make sense,
>     but I see some code in weston that would only apply in such
> case...
>     if (window->override_redirect) { ... if (window->frame)
>     frame_resize_inside(...)
> 
>     All windows that go through map_request handler will get the
> frame
>     window (window->frame_id) and the frame (wi

[PATCH v5 weston] xwm: Choose icon closest to target size

[Derek Foreman]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.

Co-authored-by: Scott Moreau 

---

Changed in v2:

- Fix typo setting width to height

Changed in v3:

- Move checks for malformed input into data handling function

Changed in v4:

- #define XWM_ICON_SIZE in this patch and do not #undef it
- Start with first icon found before choosing icon\
- Check for NULL data in get_icon_size_from_data()

Changed in v5:
- remove allocations, process in a single pass
- rebase on top of memory leak fix

 xwayland/window-manager.c | 51 ---
 1 file changed, 44 insertions(+), 7 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index dad117fa..5209ac66 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -127,6 +127,8 @@ struct motif_wm_hints {
 #define _NET_WM_MOVERESIZE_MOVE_KEYBOARD10   /* move via keyboard */
 #define _NET_WM_MOVERESIZE_CANCEL   11   /* cancel operation */
 
+#define XWM_ICON_SIZE 16 /* width and height of frame icon */
+
 struct weston_output_weak_ref {
struct weston_output *output;
struct wl_listener destroy_listener;
@@ -1352,6 +1354,44 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t *height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, *ret = NULL, w, h;
+   int a1, a2, a3;
+
+   if (!data)
+   return NULL;
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   /* Some checks against malformed input. */
+   if (w == 0 || h == 0 || length < 2 + w * h)
+   return ret;
+
+   a2 = w * h;
+   a3 = *width * *height;
+   if (!a3 || abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = h;
+   ret = d;
+   }
+
+   d += a2;
+   }
+
+   return ret;
+}
+
 static void
 handle_icon_surface_destroy(void *data)
 {
@@ -1367,9 +1407,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1383,11 +1420,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
}
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
 
-   /* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height) {
+   data = get_icon_size_from_data(XWM_ICON_SIZE, XWM_ICON_SIZE,
+   , , length, data);
+
+   if (!data) {
free(reply);
return;
}
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] xwm: Fix two more icon related memory leaks

[Derek Foreman]

Hopefully sort the last leaks introduced in commit 6b58ea8c

The window could be destroyed before it had a frame but after it had an icon
(I could trigger this with firefox), and the window could be assigned an icon
twice before it had a frame (I could trigger this with terminology).

The latter leak was
Reported-by: Scott Moreau <ore...@gmail.com>

Signed-off-by: Derek Foreman <der...@osg.samsung.com>
---
 xwayland/window-manager.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index dad117fa..7b98e140 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1404,6 +1404,9 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
}
 
+   if (window->icon_surface)
+   cairo_surface_destroy(window->icon_surface);
+
cairo_surface_set_user_data(new_surface, NULL, reply,
_icon_surface_destroy);
 
@@ -1506,6 +1509,8 @@ weston_wm_window_destroy(struct weston_wm_window *window)
wl_event_source_remove(window->repaint_source);
if (window->cairo_surface)
cairo_surface_destroy(window->cairo_surface);
+   if (window->icon_surface)
+   cairo_surface_destroy(window->icon_surface);
 
if (window->frame_id) {
xcb_reparent_window(wm->conn, window->id, wm->wm_window, 0, 0);
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3] xwm: Fix memory leak

[Derek Foreman]

On 2018-03-26 08:36 AM, Pekka Paalanen wrote:
> On Fri, 23 Mar 2018 15:07:07 -0500
> Derek Foreman <der...@osg.samsung.com> wrote:
> 
>> On 2018-03-23 02:41 PM, Scott Moreau wrote:
>>> A memory leak introduced by 6b58ea8c led to me finding a bigger leak,
>>> which is xwm was calling frame_create() without calling frame_destroy().
>>> This meant that the associated icon_surface was not being destroyed,
>>> leaving the destroy handler for it broken. Here we fix this by calling
>>> frame_destroy() when the window is destroyed and free the reply in
>>> the icon_surface destroy handler.  
>>
>> Reviewed-by: Derek Foreman <der...@osg.samsung.com>
>>
>> Though, I guess this should probably be split into two, in case the icon
>> stuff needs to be pulled before the RC.
>>
>> I can do that when I land it though.

I didn't bother splitting it, and have landed it now.

Thanks,
Derek

>> Will wait on this a little longer to see if anyone else wants to review.
>>  Looks trivially correct to me, but xwm has tricked me before.
> 
> Hi,
> 
> it looks reasonable to me too, so
> Acked-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> split or unsplit.
> 
>>> ---
>>>
>>> Changed in v2:
>>>
>>> - Setup destroy handler to free reply when surface is destroyed
>>> - Call frame_destroy() for window->frame
>>>
>>> Changed in v3:
>>>
>>> - Fix whitespace
>>> - Drop unnecessary cast in handle_icon_surface_destroy()
>>>
>>>  xwayland/window-manager.c | 21 +++--
>>>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> Thanks,
> pq
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v4 2/2] xwm: Scale icon if size is not the target size

[Derek Foreman]

On 2018-03-23 02:47 PM, Scott Moreau wrote:
> This scales the icon cairo surface for the titlebar if it isn't the
> target size.
> 
> shared/cairo-util: Add surface resizing function to be used for this
> case and other potential cases.
> ---
> 
> Changed in v2:
> 
> - Rebase to [PATCH 1/1 v3] xwm: Choose icon closest to target size
> 
> Changed in v3:
> 
> - No changes
> 
> Changed in v4:
> 
> - Fixed whitespace problems
> - Renamed cairo_resize_surface() to resize_cairo_surface()
> 
>  shared/cairo-util.c   | 63 
> +++
>  shared/cairo-util.h   |  4 +++
>  xwayland/window-manager.c |  4 +++
>  3 files changed, 71 insertions(+)
> 
> diff --git a/shared/cairo-util.c b/shared/cairo-util.c
> index d71e0ed..442182b 100644
> --- a/shared/cairo-util.c
> +++ b/shared/cairo-util.c
> @@ -365,6 +365,69 @@ load_cairo_surface(const char *filename)
>  width, height, stride);
>  }
>  
> +static cairo_surface_t *
> +scale_surface(cairo_surface_t *source, cairo_filter_t filter,
> +     double width, double height)

Still have some whitespace issues here.

Otherwise, this is
Reviewed-by: Derek Foreman <der...@osg.samsung.com>

Does this + your leak fix close all known bugs in the icon code?

Thanks,
Derek

> +{
> + cairo_surface_t *dest;
> + cairo_t *cr;
> + int old_width, old_height;
> +
> + old_width = cairo_image_surface_get_width(source);
> + old_height = cairo_image_surface_get_height(source);
> +
> + dest = cairo_surface_create_similar(source,
> + CAIRO_CONTENT_COLOR_ALPHA,
> + width, height);
> + cr = cairo_create (dest);
> +
> + cairo_scale (cr, width / old_width, height / old_height);
> + cairo_set_source_surface (cr, source, 0, 0);
> +
> + cairo_pattern_set_extend (cairo_get_source(cr),
> + CAIRO_EXTEND_REFLECT);
> +
> + cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
> +
> + cairo_paint (cr);
> +
> + cairo_destroy (cr);
> +
> + cairo_surface_destroy(source);
> +
> + return dest;
> +}
> +
> +cairo_surface_t *
> +resize_cairo_surface(cairo_surface_t *source, cairo_filter_t filter,
> + int width, int height)
> +{
> + if (!filter)
> + filter = CAIRO_FILTER_BEST;
> +
> + while((cairo_image_surface_get_width(source) / 2.0f) > width)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source) / 2.0f,
> + cairo_image_surface_get_height(source));
> +
> + while((cairo_image_surface_get_height(source) / 2.0f) > height)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source),
> + cairo_image_surface_get_height(source) / 2.0f);
> +
> + while((cairo_image_surface_get_width(source) * 2.0f) < width)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source) * 2.0f,
> + cairo_image_surface_get_height(source));
> +
> + while((cairo_image_surface_get_height(source) * 2.0f) < height)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source),
> + cairo_image_surface_get_height(source) * 2.0f);
> +
> + return scale_surface(source, filter, width, height);
> +}
> +
>  void
>  theme_set_background_source(struct theme *t, cairo_t *cr, uint32_t flags)
>  {
> diff --git a/shared/cairo-util.h b/shared/cairo-util.h
> index 6fd11f6..1c58f3b 100644
> --- a/shared/cairo-util.h
> +++ b/shared/cairo-util.h
> @@ -49,6 +49,10 @@ rounded_rect(cairo_t *cr, int x0, int y0, int x1, int y1, 
> int radius);
>  cairo_surface_t *
>  load_cairo_surface(const char *filename);
>  
> +cairo_surface_t *
> +resize_cairo_surface(cairo_surface_t *source, cairo_filter_t filter,
> + int width, int height);
> +
>  struct theme {
>   cairo_surface_t *active_frame;
>   cairo_surface_t *inactive_frame;
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 5fb41bf..50c5855 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -1463,6 +1463,10 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   return;
>   }
>  
> + if (width != XWM_ICON_SIZ

Re: [PATCH v4 1/2] xwm: Choose icon closest to target size

[Derek Foreman]

On 2018-03-23 02:47 PM, Scott Moreau wrote:
> Xwayland clients can offer multiple icon sizes in no particular order.
> Previously xwm was selecting the first one unconditionally. This patch
> selects the icon that matches the size closest to the target size. The
> target size is hard coded to 16 since there is only one theme and the
> data used to create the theme is hard coded.

LGTM,
Reviewed-by: Derek Foreman <der...@osg.samsung.com>

> ---
> 
> Changed in v2:
> 
> - Fix typo setting width to height
> 
> Changed in v3:
> 
> - Move checks for malformed input into data handling function
> 
> Changed in v4:
> 
> - #define XWM_ICON_SIZE in this patch and do not #undef it
> - Start with first icon found before choosing icon\
> - Check for NULL data in get_icon_size_from_data()
> 
>  xwayland/window-manager.c | 84 
> +++
>  1 file changed, 77 insertions(+), 7 deletions(-)
> 
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index c307e19..5fb41bf 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -127,6 +127,8 @@ struct motif_wm_hints {
>  #define _NET_WM_MOVERESIZE_MOVE_KEYBOARD10   /* move via keyboard */
>  #define _NET_WM_MOVERESIZE_CANCEL   11   /* cancel operation */
>  
> +#define XWM_ICON_SIZE 16 /* width and height of frame icon */
> +
>  struct weston_output_weak_ref {
>   struct weston_output *output;
>   struct wl_listener destroy_listener;
> @@ -1352,6 +1354,77 @@ weston_wm_window_schedule_repaint(struct 
> weston_wm_window *window)
>  weston_wm_window_do_repaint, window);
>  }
>  
> +static uint32_t *
> +get_icon_size_from_data(int target_width, int target_height,
> + uint32_t *width, uint32_t *height,
> + uint32_t length, uint32_t *data)
> +{
> + uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
> + int num_sizes = 0, *sizes = NULL, a1, a2, a3;
> +
> + if (!data)
> + return NULL;
> +
> + *width = *height = 0;
> +
> + while (d - data < length / 4) {
> + w = *d++;
> + h = *d++;
> +
> + /* Some checks against malformed input. */
> + if (w == 0 || h == 0 || length < 2 + w * h)
> + goto out;
> +
> + sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
> + if (!sizes) {
> + free(img);
> + return NULL;
> + }
> +
> + img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
> + if (!img) {
> + free(sizes);
> + return NULL;
> + }
> +
> + sizes[(num_sizes * 2) + 0] = w;
> + sizes[(num_sizes * 2) + 1] = h;
> + img[num_sizes] = d;
> +
> + num_sizes++;
> + d += w * h;
> + }
> +
> + /* Begin with first icon in list */
> + if (num_sizes) {
> + *width = sizes[0];
> + *height = sizes[1];
> + ret = img[0];
> + }
> +
> + /* Choose closest match by comparing icon dimension areas */
> + a1 = target_width * target_height;
> +
> + while (num_sizes--) {
> + w = sizes[(num_sizes * 2) + 0];
> + h = sizes[(num_sizes * 2) + 1];
> +
> + a2 = w * h;
> + a3 = *width * *height;
> +
> + if (abs(a2 - a1) < abs(a3 - a1)) {
> + *width = w;
> + *height = h;
> + ret = img[num_sizes];
> + }
> + }
> +out:
> + free(sizes);
> + free(img);
> +
> + return ret;
> +}
> +
>  static void
>  weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
>  {
> @@ -1361,9 +1434,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   uint32_t *data, width, height;
>   cairo_surface_t *new_surface;
>  
> - /* TODO: icons don’t have any specified order, we should pick the
> -  * closest one to the target dimension instead of the first one. */
> -
>   cookie = xcb_get_property(wm->conn, 0, window->id,
> wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
> UINT32_MAX);
> @@ -1375,11 +1445,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   return;
>  
>   data = xcb_get_property_value(reply);
> - width = *data++;
> - height 

Re: [PATCH v3] xwm: Fix memory leak

[Derek Foreman]

On 2018-03-23 02:41 PM, Scott Moreau wrote:
> A memory leak introduced by 6b58ea8c led to me finding a bigger leak,
> which is xwm was calling frame_create() without calling frame_destroy().
> This meant that the associated icon_surface was not being destroyed,
> leaving the destroy handler for it broken. Here we fix this by calling
> frame_destroy() when the window is destroyed and free the reply in
> the icon_surface destroy handler.

Reviewed-by: Derek Foreman <der...@osg.samsung.com>

Though, I guess this should probably be split into two, in case the icon
stuff needs to be pulled before the RC.

I can do that when I land it though.

Will wait on this a little longer to see if anyone else wants to review.
 Looks trivially correct to me, but xwm has tricked me before.

Thanks,
Derek

> ---
> 
> Changed in v2:
> 
> - Setup destroy handler to free reply when surface is destroyed
> - Call frame_destroy() for window->frame
> 
> Changed in v3:
> 
> - Fix whitespace
> - Drop unnecessary cast in handle_icon_surface_destroy()
> 
>  xwayland/window-manager.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index c307e19..77df8cf 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -1353,6 +1353,12 @@ weston_wm_window_schedule_repaint(struct 
> weston_wm_window *window)
>  }
>  
>  static void
> +handle_icon_surface_destroy(void *data)
> +{
> + free(data);
> +}
> +
> +static void
>  weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
>  {
>   xcb_get_property_reply_t *reply;
> @@ -1371,16 +1377,20 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   length = xcb_get_property_value_length(reply);
>  
>   /* This is in 32-bit words, not in bytes. */
> - if (length < 2)
> + if (length < 2) {
> + free(reply);
>   return;
> + }
>  
>   data = xcb_get_property_value(reply);
>   width = *data++;
>   height = *data++;
>  
>   /* Some checks against malformed input. */
> - if (width == 0 || height == 0 || length < 2 + width * height)
> + if (width == 0 || height == 0 || length < 2 + width * height) {
> + free(reply);
>   return;
> + }
>  
>   new_surface =
>   cairo_image_surface_create_for_data((unsigned char *)data,
> @@ -1390,9 +1400,13 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   /* Bail out in case anything wrong happened during surface creation. */
>   if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
>   cairo_surface_destroy(new_surface);
> + free(reply);
>   return;
>   }
>  
> + cairo_surface_set_user_data(new_surface, NULL, reply,
> + _icon_surface_destroy);
> +
>   if (window->frame)
>   frame_set_icon(window->frame, new_surface);
>   else /* We don’t have a frame yet */
> @@ -1502,6 +1516,9 @@ weston_wm_window_destroy(struct weston_wm_window 
> *window)
>   window->frame_id = XCB_WINDOW_NONE;
>   }
>  
> + if (window->frame)
> + frame_destroy(window->frame);
> +
>   if (window->surface_id)
>   wl_list_remove(>link);
>  
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] xwm: Fix memory leak

[Derek Foreman]

On 2018-03-20 10:26 AM, Scott Moreau wrote:
> A memory leak introduced by 6b58ea8c led to me finding a bigger
> leak, which is xwm was calling frame_create() without calling
> frame_destroy(). This meant that the associated icon_surface
> was not being destroyed, leaving the destroy handler for it
> broken. Here we fix this by calling frame_destroy() when the
> window is destroyed and free the reply in the icon_surface
> destroy handler.

Ran valgrind memcheck to try to confirm this resolved a leak, found a
lot more leaks. ugh. :)

> ---
>  xwayland/window-manager.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index c307e19..9e61a67 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -1353,6 +1353,14 @@ weston_wm_window_schedule_repaint(struct 
> weston_wm_window *window)
>  }
>  
>  static void
> +handle_icon_surface_destroy(void *data)
> +{
> + xcb_get_property_reply_t *reply = (xcb_get_property_reply_t *)data;
> +
> + free(reply);

free takes a void * anyway, so just free(data); should be fine.

> +}
> +
> +static void
>  weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
>  {
>   xcb_get_property_reply_t *reply;
> @@ -1371,16 +1379,20 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   length = xcb_get_property_value_length(reply);
>  
>   /* This is in 32-bit words, not in bytes. */
> - if (length < 2)
> + if (length < 2) {
> + free(reply);
>   return;
> + }
>  
>   data = xcb_get_property_value(reply);
>   width = *data++;
>   height = *data++;
>  
>   /* Some checks against malformed input. */
> - if (width == 0 || height == 0 || length < 2 + width * height)
> + if (width == 0 || height == 0 || length < 2 + width * height) {
> + free(reply);
>   return;
> + }
>  
>   new_surface =
>   cairo_image_surface_create_for_data((unsigned char *)data,
> @@ -1390,9 +1402,13 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   /* Bail out in case anything wrong happened during surface creation. */
>   if (cairo_surface_status(new_surface) != CAIRO_STATUS_SUCCESS) {
>   cairo_surface_destroy(new_surface);
> +     free(reply);
>   return;
>   }
>  
> + cairo_surface_set_user_data(new_surface, NULL, reply,

(wrong tab size again)

Those nits resolved and this is
Reviewed-by: Derek Foreman <der...@osg.samsung.com>

Thanks,
Derek

> + 
> _icon_surface_destroy);
> +
>   if (window->frame)
>   frame_set_icon(window->frame, new_surface);
>   else /* We don’t have a frame yet */
> @@ -1502,6 +1518,9 @@ weston_wm_window_destroy(struct weston_wm_window 
> *window)
>   window->frame_id = XCB_WINDOW_NONE;
>   }
>  
> + if (window->frame)
> + frame_destroy(window->frame);
> +
>   if (window->surface_id)
>   wl_list_remove(>link);
>  
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2 v2] xwm: Scale icon if size is not the target size

[Derek Foreman]

On 2018-03-22 01:04 AM, Scott Moreau wrote:
> This scales the icon cairo surface for the titlebar if it isn't the
> target size.
> 
> shared/cairo-util: Add surface resizing function to be used for this
> case and other potential cases.
> ---
> 
> Changed in v2:
> 
> - Rebase to [PATCH 1/1 v3] xwm: Choose icon closest to target size
> 
>  shared/cairo-util.c   | 61 
> +++
>  shared/cairo-util.h   |  4 
>  xwayland/window-manager.c |  9 ++-
>  3 files changed, 73 insertions(+), 1 deletion(-)
> 
> diff --git a/shared/cairo-util.c b/shared/cairo-util.c
> index d71e0ed..b91b5bc 100644
> --- a/shared/cairo-util.c
> +++ b/shared/cairo-util.c
> @@ -142,6 +142,67 @@ blur_surface(cairo_surface_t *surface, int margin)
>   return 0;
>  }
>  
> +static cairo_surface_t *
> +scale_surface(cairo_surface_t *source, cairo_filter_t filter,
> + double width, double 
> height)
> +{
> + cairo_surface_t *dest;
> + cairo_t *cr;
> + int old_width, old_height;
> +
> + old_width = cairo_image_surface_get_width(source);
> + old_height = cairo_image_surface_get_height(source);
> +
> + dest = cairo_surface_create_similar(source, CAIRO_CONTENT_COLOR_ALPHA,
> + width, height);
> + cr = cairo_create (dest);
> +
> + cairo_scale (cr, width / old_width, height / old_height);
> + cairo_set_source_surface (cr, source, 0, 0);
> +
> + cairo_pattern_set_extend (cairo_get_source(cr), CAIRO_EXTEND_REFLECT);
> +
> + cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
> +
> + cairo_paint (cr);
> +
> + cairo_destroy (cr);
> +
> + cairo_surface_destroy(source);

This function looks like it solves the problem without leaking anything
- would love to see more review from others with cairo experience.

> +
> + return dest;
> +}
> +
> +cairo_surface_t *

I would prefer this function be named something else, so a casual reader
with no knowledge of cairo API (like me!) doesn't think it looks like a
cairo function name.

> +cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
> + int width, int height)
> +{
> + if (!filter)
> + filter = CAIRO_FILTER_BEST;
> +
> + while((cairo_image_surface_get_width(source) / 2.0f) > width)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source) / 2.0f,
> + cairo_image_surface_get_height(source));
> +
> + while((cairo_image_surface_get_height(source) / 2.0f) > height)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source),
> + cairo_image_surface_get_height(source) / 2.0f);
> +
> + while((cairo_image_surface_get_width(source) * 2.0f) < width)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source) * 2.0f,
> + cairo_image_surface_get_height(source));
> +
> + while((cairo_image_surface_get_height(source) * 2.0f) < height)
> + source = scale_surface(source, filter,
> + cairo_image_surface_get_width(source),
> + cairo_image_surface_get_height(source) * 2.0f);

This chain of operations feels complicated - is it not possible to
calculate the optimal target size and just call scale_surface once?

> +
> + return scale_surface(source, filter, width, height);
> +}
> +
>  void
>  render_shadow(cairo_t *cr, cairo_surface_t *surface,
> int x, int y, int width, int height, int margin, int top_margin)
> diff --git a/shared/cairo-util.h b/shared/cairo-util.h
> index 6fd11f6..3bd2b0c 100644
> --- a/shared/cairo-util.h
> +++ b/shared/cairo-util.h
> @@ -49,6 +49,10 @@ rounded_rect(cairo_t *cr, int x0, int y0, int x1, int y1, 
> int radius);
>  cairo_surface_t *
>  load_cairo_surface(const char *filename);
>  
> +cairo_surface_t *
> +cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
> + int width, int height);
> +
>  struct theme {
>   cairo_surface_t *active_frame;
>   cairo_surface_t *inactive_frame;
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 30c4b1c..6057490 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -1416,6 +1416,7 @@ get_icon_size_from_data(int target_width, int 
> target_height,
>   return ret;
>  }
>  
> +#define ICON_SIZE 16
>  static void
>  weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
>  {
> @@ -1437,7 +1438,8 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>  
>   data = xcb_get_property_value(reply);
>

Just occurred 

Re: [PATCH v3] xwm: Choose icon closest to target size

[Derek Foreman]

Thanks for this.  This particular feature is getting on my nerves
because it seemed like a simple thing and has result in a lot of breakage.

Would like to see it repaired or removed by late next week.

This seems to be a good step towards repair, comments inline below.

On 2018-03-22 12:47 AM, Scott Moreau wrote:
> Xwayland clients can offer multiple icon sizes in no particular order.
> Previously xwm was selecting the first one unconditionally. This patch
> selects the icon that matches the size closest to the target size. The
> target size is hard coded to 16 since there is only one theme and the
> data used to create the theme is hard coded.
> ---
> 
> Changed in v2:
> 
> - Fix typo setting width to height
> 
> Changed in v3:
> 
> - Move checks for malformed input into data handling function
> 
>  xwayland/window-manager.c | 74 
> ++-
>  1 file changed, 67 insertions(+), 7 deletions(-)
> 
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index c307e19..30c4b1c 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -1352,6 +1352,70 @@ weston_wm_window_schedule_repaint(struct 
> weston_wm_window *window)
>  weston_wm_window_do_repaint, window);
>  }
>  
> +static uint32_t *
> +get_icon_size_from_data(int target_width, int target_height,
> + uint32_t *width, uint32_t 
> *height,
> + uint32_t length, uint32_t *data)
> +{
> + uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
> + int num_sizes = 0, *sizes = NULL, a1, a2, a3;
> +
> + *width = *height = 0;
> +
> + while (d - data < length / 4) {
> + w = *d++;
> + h = *d++;
> +
> + /* Some checks against malformed input. */
> + if (w == 0 || h == 0 || length < 2 + w * h) {
> + free(sizes);
> + free(img);
> + return NULL;
> + }

I think since ret is init to NULL, and free(NULL) is a nop, all these
checks could just goto out;  and an out label could be added immediately
before free(sizes) at the end of function.

Should shrink it a bit...

> +
> + sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
> + if (!sizes) {
> + free(img);
> + return NULL;
> + }
> +
> + img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
> + if (!img) {
> + free(sizes);
> + return NULL;
> + }
> +
> + sizes[(num_sizes * 2) + 0] = w;
> + sizes[(num_sizes * 2) + 1] = h;
> + img[num_sizes] = d;
> +
> + num_sizes++;
> + d += w * h;
> + }
> +
> + /* Choose closest match by comparing icon dimension areas */
> + a1 = target_width * target_height;
> +
> + while (num_sizes--) {
> + w = sizes[(num_sizes * 2) + 0];
> + h = sizes[(num_sizes * 2) + 1];
> +
> + a2 = w * h;
> + a3 = *width * *height;
> +
> + if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {

When running terminology, which only provides a single 128x128 icon, I
run through this and exit with ret == NULL, and no icon is displayed.

Without thinking too hard, I guess the initial 0x0 is closer to 16x16
than 128x128 is. :)  I guess maybe this should accept any icon if no
icon has been picked yet (or just before this loop we could init to the
first icon...)

> + *width = w;
> + *height = h;
> + ret = img[num_sizes];
> + }
> + }
> +
> + free(sizes);
> + free(img);
> +
> + return ret;
> +}
> +
>  static void
>  weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
>  {
> @@ -1361,9 +1425,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   uint32_t *data, width, height;
>   cairo_surface_t *new_surface;
>  
> - /* TODO: icons don’t have any specified order, we should pick the
> -  * closest one to the target dimension instead of the first one. */
> -
>   cookie = xcb_get_property(wm->conn, 0, window->id,
> wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
> UINT32_MAX);
> @@ -1375,11 +1436,10 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
> weston_wm_window *window)
>   return;
>  
>   data = xcb_get_property_value(reply);
> - width = *data++;
> - height = *data++;
>  
> - /* Some checks against malformed input. */
> - if (width == 0 || height == 0 || length < 2 + width * height)
> + data = get_icon_size_from_data(16, 16, , , length, data);

In your next patch you replace the 16s with ICON_SIZE, a temporarily
#defined constant...

I wouldn't 

Re: [PATCH wayland] wayland-egl: Ignore underscored symbols in ABI check

[Derek Foreman]

On 2018-03-20 10:02 AM, Emil Velikov wrote:
> On 20 March 2018 at 14:50, Derek Foreman <der...@osg.samsung.com> wrote:
>> On 2018-03-20 07:11 AM, Daniel Stone wrote:
>>> On 20 March 2018 at 11:55, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>>>> On 20 March 2018 at 11:46, Daniel Stone <dan...@fooishbar.org> wrote:
>>>>> Sure. As on IRC though, we definitely need to add at least _ftext for
>>>>> MIPS anyway:
>>>>> https://gitlab.gnome.org/GNOME/glib/commit/ad12142943e0f20ed9583c9d6bf50f6262110c74
>>>>>
>>>>> And probably some more for ARM toolchains using other linkers:
>>>>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474k/pge1362066045758.html
>>>>>
>>>>> Doing a quick check across all the architectures on Debian shows that
>>>>> your updated list is also missing _fbss, _fdata, and _ftext. So we'd
>>>>> need to respin for those as well, but I think at this point the
>>>>> inconvenience of maintaining a list of every linker's implementation
>>>>> detail on every platform, outweighs the risk of an exported
>>>>> underscore-prefixed symbol slipping through review.
>>>>
>>>> I think you're preemptively worried about this. Plus there's no need
>>>> to add every symbol a search could find.
>>>>
>>>> Even then, ask yourself the question:
>>>> Which is better - updating an ugly looking list once in a blue moon or
>>>> having apps use internal API?
>>>>
>>>> As said above: _if_ it turns out to be labour intensive - fine remove it.
>>>> We've already spend more time researching than what the [expected]
>>>> maintenance for 1 year would be ;-)
>>>
>>> It all depends on how you view scope and probability.
>>>
>>> I don't agree my concern is preemptive: we've just shipped a beta
>>> where 'make check' fails on a few architectures, and the proposed fix
>>> (adding several symbols to the platform list) will still fail on
>>> architectures Debian ships on, until it also adds _fbss, _fdata and
>>> _ftext. I think my suggestion is reasonable: it fixes the very real
>>> problem, in a way which avoids expanding the scope of our ABI checker
>>> to include the implementation details of every linker/architecture
>>> pair that people use Wayland on. The cost of this is the probability
>>> that someone manages to add a new underscored symbol marked with
>>> WL_EXPORT into a library which is currently 105 LoC, and have no-one
>>> notice that in review. I think that's a reasonable tradeoff.
>>
>> I'm inclined to agree with Daniel here.
>>
>> Someone managing to sneak a WL_EXPORT on a symbol starting with a _ past
>> review seems reasonably unlikely.
>>
>> And after reading this thread I'm still not entirely sure we have a
>> complete list of what should be on that whitelist, and there are only a
>> limited number of systems I can test build on right now.
>>
> Sharing a few ideas that are less obvious. Having the partial list
> allows you to:
>  - see active developers/users - be that by merging their patches or
> skimming through the report

I don't imagine we'll be adding new API to that library frequently
enough to mine that data productively.

>  - have contact point for people with unusual platforms/setups

By defaulting to a broken build state for unusual platforms, do you
really think we'll attract many contact points?

>  - is fairly trivial newbie task ;-)

I don't think we should be going out of our way to generate problems for
newbies to solve.  There are plenty of worthwhile tasks for new
participants already.

I've confirmed that we once again pass make check on arm (something I
really should've done prior to the beta release.  sigh.) and have pushed
this patch.

Thanks,
Derek

> 
> -Emil
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] wayland-egl: Ignore underscored symbols in ABI check

[Derek Foreman]

On 2018-03-20 07:11 AM, Daniel Stone wrote:
> On 20 March 2018 at 11:55, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>> On 20 March 2018 at 11:46, Daniel Stone <dan...@fooishbar.org> wrote:
>>> Sure. As on IRC though, we definitely need to add at least _ftext for
>>> MIPS anyway:
>>> https://gitlab.gnome.org/GNOME/glib/commit/ad12142943e0f20ed9583c9d6bf50f6262110c74
>>>
>>> And probably some more for ARM toolchains using other linkers:
>>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474k/pge1362066045758.html
>>>
>>> Doing a quick check across all the architectures on Debian shows that
>>> your updated list is also missing _fbss, _fdata, and _ftext. So we'd
>>> need to respin for those as well, but I think at this point the
>>> inconvenience of maintaining a list of every linker's implementation
>>> detail on every platform, outweighs the risk of an exported
>>> underscore-prefixed symbol slipping through review.
>>
>> I think you're preemptively worried about this. Plus there's no need
>> to add every symbol a search could find.
>>
>> Even then, ask yourself the question:
>> Which is better - updating an ugly looking list once in a blue moon or
>> having apps use internal API?
>>
>> As said above: _if_ it turns out to be labour intensive - fine remove it.
>> We've already spend more time researching than what the [expected]
>> maintenance for 1 year would be ;-)
> 
> It all depends on how you view scope and probability.
> 
> I don't agree my concern is preemptive: we've just shipped a beta
> where 'make check' fails on a few architectures, and the proposed fix
> (adding several symbols to the platform list) will still fail on
> architectures Debian ships on, until it also adds _fbss, _fdata and
> _ftext. I think my suggestion is reasonable: it fixes the very real
> problem, in a way which avoids expanding the scope of our ABI checker
> to include the implementation details of every linker/architecture
> pair that people use Wayland on. The cost of this is the probability
> that someone manages to add a new underscored symbol marked with
> WL_EXPORT into a library which is currently 105 LoC, and have no-one
> notice that in review. I think that's a reasonable tradeoff.

I'm inclined to agree with Daniel here.

Someone managing to sneak a WL_EXPORT on a symbol starting with a _ past
review seems reasonably unlikely.

And after reading this thread I'm still not entirely sure we have a
complete list of what should be on that whitelist, and there are only a
limited number of systems I can test build on right now.

Reviewed-by: Derek Foreman <der...@osg.samsung.com>

> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] weston 3.0.92

[Derek Foreman]

This is the beta for the weston 4.0.0 release.

Chris Wilson (1):
  gl-renderer: Create a high priority context

Daniel Stone (4):
  compositor-drm: Don't need safe view-list traversal
  compositor-drm: Rename region variable
  compositor-drm: Remove no_addfb2 handling
  compositor-wayland: Ignore pointer enter on destroyed surface

Derek Foreman (2):
  libweston-desktop/xdg-shell-v6: Fix crash when surface has buffer
at creation
  configure.ac: bump to version 3.0.92 for the beta release

Dima Ryazanov (2):
  weston: Add a help string for --xwayland
  Fix an uninitialized variable

Emmanuel Gil Peyrot (1):
  autoconf: Remove configure line forgotten in
bb707dc0fe331c9af112a0552b7aa6fde755dd83

Guido Günther (9):
  simple-dmabuf-drm: allow multiple backends
  simpla-dmabuf-drm: Use more weston like coding style
  simple-dmabuf-drm: use vfunc for drm_device_destroy
  .gitignore weston-simple-dmabuf-drm
  Allow simple-dmabuf-drm to pass y_inverted flag
  simple-dmabuf-drm: use opt bitmask instead of is_immediate
  simple-dmabuf-drm: use getopt_long
  simple-dmabuf-drm: Always define ALIGN
  simple-dmabuf-drm: use appropriately sized buffer (freedreno)

Ilia Bozhinov (1):
  compositor: do not free output region twice in
weston_output_set_transform()

Jan Engelhardt (1):
  build: honour libinput header location

Marius Vlad (1):
  libweston/compositor: Place timeline recording after checking if
stamp is valid

Michael Tretter (1):
  configure.ac: fix have_dbus if dbus support is disabled

Pekka Paalanen (4):
  compositor-wayland: handle wl_keyboard.enter(NULL)
  input: never set keyboard focus without wl_resource
  clients: consolidate timer code part 1
  clients: consolidate timer code part 2

git tag: 3.0.92

https://wayland.freedesktop.org/releases/weston-3.0.92.tar.xz
MD5:  bf5fd585a96f24b5d23d4a6507cb831c  weston-3.0.92.tar.xz
SHA1: 22b9815aa40ff001702711de256ddd81e25e4088  weston-3.0.92.tar.xz
SHA256: d62234732fa40afc60fa9c06c369f2774c1712f3aaba7949b60a43602966b35a
 weston-3.0.92.tar.xz
SHA512:
e2e3e961de19df8a2da328676506bc5ea922302e89ab62f7c7b30b0327d4baab92b4069fd3d2e7dbe273ba5fc73c9736eabe5274aa4115ad945695ac73b33881
 weston-3.0.92.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-3.0.92.tar.xz.sig




signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.14.92

[Derek Foreman]

This is the beta for the wayland 1.15 release.

Daniel Stone (2):
  wayland-egl: Pass nm path to check script
  wayland-egl: Make symbol test fail on failure

Derek Foreman (3):
  client: Don't inappropriatly close fds for zombie objects
  walyand-client: Fix trivial build break from previous commit
  configure.ac: bump to version 1.14.92 for the beta release

Emil Velikov (5):
  configure.ac: don't install the static libraries
  wayland-egl: set the correct path to libwayland-egl.so
  wayland-egl: fail the symbol check if lib is missing
  wayland-egl: enhance the symbol test
  wayland-egl: bump the version number to 18.1.0

Pekka Paalanen (1):
  tests: disable coredumps on sanity-test

git tag: 1.14.92

https://wayland.freedesktop.org/releases/wayland-1.14.92.tar.xz
MD5:  6e04afc4076bf275a69cfe05847a9a58  wayland-1.14.92.tar.xz
SHA1: 17cf6eb0f532d92271c40e9ec404886f56eb54a0  wayland-1.14.92.tar.xz
SHA256: 80bda4f714d7f48638234c6e7a1eced117943eacb1c872c201c8f0e47542e7f1
 wayland-1.14.92.tar.xz
SHA512:
d0ba6838652165d65399bd11e7e5abdf13a6cf9cb2c54fe5534ac7d3056922844001b237064224c82bb7dcea2b92111c1c25e798c2d39e5637cc1615c318e618
 wayland-1.14.92.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.14.92.tar.xz.sig





signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v4 4/4] simple-dmabuf-drm: support etnaviv drm as well

[Derek Foreman]

On 2018-03-19 11:45 AM, Guido Günther wrote:

Signed-off-by: Guido Günther <a...@sigxcpu.org>
---
  Makefile.am |  1 +
  clients/simple-dmabuf-drm.c | 77 +
  configure.ac|  5 ++-
  3 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 69ca6cba..64a8006c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -629,6 +629,7 @@ nodist_weston_simple_dmabuf_drm_SOURCES =   \
  weston_simple_dmabuf_drm_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_DRM_CLIENT_CFLAGS)
  weston_simple_dmabuf_drm_LDADD = $(SIMPLE_DMABUF_DRM_CLIENT_LIBS) \
$(LIBDRM_PLATFORM_FREEDRENO_LIBS) \
+   $(LIBDRM_PLATFORM_ETNAVIV_LIBS)   \
$(LIBDRM_PLATFORM_INTEL_LIBS) \
libshared.la
  endif
diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 22891639..0bc99a59 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -39,6 +39,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 
  
@@ -49,6 +50,9 @@

  #ifdef HAVE_LIBDRM_FREEDRENO
  #include 
  #endif
+#ifdef HAVE_LIBDRM_ETNAVIV
+#include 
+#endif
  #include 
  
  #include 

@@ -108,6 +112,10 @@ struct buffer {
struct fd_device *fd_dev;
struct fd_bo *fd_bo;
  #endif /* HAVE_LIBDRM_FREEDRENO */
+#if HAVE_LIBDRM_ETNAVIV
+   struct etna_device *etna_dev;
+   struct etna_bo *etna_bo;
+#endif /* HAVE_LIBDRM_ETNAVIV */
  
  	uint32_t gem_handle;

int dmabuf_fd;
@@ -272,6 +280,65 @@ fd_device_destroy(struct buffer *buf)
fd_device_del(buf->fd_dev);
  }
  #endif /* HAVE_LIBDRM_FREEDRENO */
+#ifdef HAVE_LIBDRM_ETNAVIV
+
+static int
+etna_alloc_bo(struct buffer *buf)
+{
+   int flags = DRM_ETNA_GEM_CACHE_WC;
+   int size;
+
+   buf->stride = ALIGN(buf->width, 32) * buf->bpp / 8;
+   size =  buf->stride * buf->height;
+   buf->etna_dev = etna_device_new(buf->drm_fd);
+   buf->etna_bo = etna_bo_new(buf->etna_dev, size, flags);
+
+   if (!buf->etna_bo)
+   return 0;
+   return 1;
+}
+
+static void
+etna_free_bo(struct buffer *buf)
+{
+   etna_bo_del(buf->etna_bo);
+}
+
+static int
+etna_bo_export_to_prime(struct buffer *buf)
+{
+   buf->dmabuf_fd = etna_bo_dmabuf(buf->etna_bo);
+   if (buf->dmabuf_fd < 0)
+   return 1;
+
+   return 0;
+}
+
+static int
+etna_map_bo(struct buffer *buf)
+{
+   buf->mmap = etna_bo_map(buf->etna_bo);
+
+   if (buf->mmap != NULL)
+   return 1;
+
+   return 0;
+}
+
+static void
+etna_unmap_bo(struct buffer *buf)
+{
+   if (munmap(buf->mmap, buf->stride * buf->height) < 0)
+   fprintf(stderr, "Failed to unmap buffer: %s", strerror(errno));


Pekka had said something about cache flushing here in a previous 
comment, I think.  I think this munmap() is enough, but if it isn't I'd 
like to know what's required too.



+   buf->mmap = NULL;
+}
+
+static void
+etna_device_destroy(struct buffer *buf)
+{
+   etna_device_del(buf->etna_dev);
+}
+#endif /* HAVE_LIBDRM_ENTAVIV */
  
  static void

  fill_content(struct buffer *my_buf)
@@ -339,6 +406,16 @@ drm_device_init(struct buffer *buf)
dev->unmap_bo = fd_unmap_bo;
dev->device_destroy = fd_device_destroy;
}
+#endif
+#ifdef HAVE_LIBDRM_ETNAVIV
+   else if (!strcmp(dev->name, "etnaviv")) {
+   dev->alloc_bo = etna_alloc_bo;
+   dev->free_bo = etna_free_bo;
+   dev->export_bo_to_prime = etna_bo_export_to_prime;
+   dev->map_bo = etna_map_bo;
+   dev->unmap_bo = etna_unmap_bo;
+   dev->device_destroy = etna_device_destroy;
+   }
  #endif
else {
fprintf(stderr, "Error: drm device %s unsupported.\n",
diff --git a/configure.ac b/configure.ac
index 90ffc88d..29926388 100644
--- a/configure.ac
+++ b/configure.ac
@@ -393,11 +393,14 @@ if ! test "x$enable_simple_dmabuf_drm_client" = "xno"; 
then
PKG_CHECK_MODULES(LIBDRM_PLATFORM_INTEL, [libdrm_intel],
AC_DEFINE([HAVE_LIBDRM_INTEL], [1], [Build intel dmabuf client]) 
have_simple_dmabuf_drm_client=yes,
[true])
+  PKG_CHECK_MODULES(LIBDRM_PLATFORM_ETNAVIV, [libdrm_etnaviv],
+  AC_DEFINE([HAVE_LIBDRM_ETNAVIV], [1], [Build etnaviv dmabuf client]) 
have_simple_dmabuf_drm_client=yes,
+  [have_etnaviv=no])


why the have_etnaviv=no here when the rest are all [true]?

With that explained, this is
Reviewed-by: Derek Foreman <der...@osg.samsung.com>

But I'm about to start the release process for the beta, so I think this 
will need to wait a while to land.


  
if test "x$have_simple_dmabuf_drm_client" != "xyes" -o \

  "x$have_simple_dmabuf_libs" = "xno" && \
 

Re: [PATCH weston v4 2/4] simple-dmabuf-drm: use large enough buffer (freedreno)

[Derek Foreman]

On 2018-03-19 12:23 PM, Eric Engestrom wrote:

On Monday, 2018-03-19 17:45:19 +0100, Guido Günther wrote:

Use stride instead of width for buffer calculation.

Signed-off-by: Guido Günther 
---
  clients/simple-dmabuf-drm.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index efe3b7f5..a184d7e7 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -222,13 +222,15 @@ fd_alloc_bo(struct buffer *buf)
  {
int flags = DRM_FREEDRENO_GEM_CACHE_WCOMBINE;
int size = buf->width * buf->height * buf->bpp / 8;


You forgot to remove the initialisation here ^


And the commit log is weird, as it's been kept from a previous patch.

As both these problems seem trivial, I've fixed them while landing with 
my Reviewed-by.


Thanks,
Derek


-   buf->fd_dev = fd_device_new(buf->drm_fd);
  
+	buf->fd_dev = fd_device_new(buf->drm_fd);

+   buf->stride = ALIGN(buf->width, 32) * buf->bpp / 8;
+   size = buf->stride * buf->height;
+   buf->fd_dev = fd_device_new(buf->drm_fd);
buf->fd_bo = fd_bo_new(buf->fd_dev, size, flags);
  
  	if (!buf->fd_bo)

return 0;
-   buf->stride = ALIGN(buf->width, 32) * buf->bpp / 8;
return 1;
  }
  
--

2.16.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] xwm: Update input region on resize

[Derek Foreman]

On 2018-03-16 06:42 PM, Scott Moreau wrote:

Hi Pekka,

On Fri, Mar 16, 2018 at 9:20 AM, Pekka Paalanen > wrote:


On Tue, 13 Mar 2018 21:22:04 -0600
Scott Moreau > wrote:

> Commit 332d1892 introduced a bug because the window was
> shaped only when the frame was created, leaving the input
> region unchanged regardless if the window was resized.
> This patch updates the input region shape on resize,
> fixing the problem.
>
> ---
>
> Changed in v2:
>
> - Bail in shape function if (window->override_redirect || !window->frame)
> - Call shape function from send_configure()
>
>  xwayland/window-manager.c | 53 
+--
>  1 file changed, 33 insertions(+), 20 deletions(-)

Hi,

while trying to wrap my head around this, I started feeling dizzy. For
real. So I have to keep this short.


I think this is what happens when trying to sync two display servers.


The first decision we should make is, do we want a quick patch for an
immediate issue at hand, or do we want to make things better in the long
run. Taking in this patch as is seems to be the former to me, and given
the phase of the release cycle can be justified.

The following mind flow is for a long term solution, and the comments
inlined with the code below are for the quick patch.


FWIW, I'd be open to landing something quick at this point.  The bug it 
fixes seems hugely annoying.  I resize an xterm, and I can't click in 
the new area.


Alternately, I'm wondering if we should consider reverting the patch 
that introduced this bug?  I guess it wasn't tested well enough, and 
this behaviour seems more painful than what it was intended to fix?




Taking a step back, the aim to keep the input shape up-to-date whenever
something happens.

If we have a frame window with decorations, then we call
frame_resize_inside() to adjust its size. Would it not be logical to
set the input shape in at least all those cases?


Yes, maybe there can be a function that calls frame_resize_inside and 
the shape function to replace calls to frame_resize_inside.



Except it looks like we can have decorated O-R windows, and those
should be exempt? Oh, I'm told decorated O-R windows don't make sense,
but I see some code in weston that would only apply in such case...
if (window->override_redirect) { ... if (window->frame)
frame_resize_inside(...)

All windows that go through map_request handler will get the frame
window (window->frame_id) and the frame (window->frame) created. The
only windows that don't get this treatment are therefore windows that
are O-R at the time of mapping them. It's somewhat complicated by the
fact that XWM does not support dynamically changing O-R flag... or
maybe it makes it easier.

Now, we have configure_request and configure_notify handlers. O-R
windows will not hit configure_request handler, and the X server
processes XWM's configure commands immediately. This sounds like
configure_request handler would be a good place to update the input
shape.


Yes


configure_notify handler gets called for O-R as well, and it happens
after the fact, so updating there would be a tiny bit late. Would you
agree?

I was thinking there might be some change that comes in configure notify 
that we don't know about until the event happens.



That leaves the XWM originated resizes, which boils down to...
send_configure(), or actually weston_wm_window_configure()?

Yes


It looks like configure_request handler is open-coding all of
weston_wm_window_configure() but it also adds some bits specific to the
configure request.

Am I making sense?

Yes, and thanks for taking the time to try and help unravel this.


 > diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
 > index c307e19..cd72a59 100644
 > --- a/xwayland/window-manager.c
 > +++ b/xwayland/window-manager.c
 > @@ -659,6 +659,33 @@ weston_wm_window_get_input_rect(struct
weston_wm_window *window,
 >  }
 >
 >  static void
 > +weston_wm_window_shape(struct weston_wm_window *window)
 > +{
 > +     struct weston_wm *wm = window->wm;
 > +     xcb_rectangle_t rect;
 > +     int x, y, width, height;
 > +
 > +     if (window->override_redirect || !window->frame)
 > +             return;
 > +
 > +     weston_wm_window_get_input_rect(window, , , ,
);
 > +
 > +     rect.x = x;
 > +     rect.y = y;
 > +     rect.width = width;
 > +     rect.height = height;
 > +
 > +     /* The window frame was created with position and size
which include
 > +      * an offset for margins and shadow. Set the input region
to ignore
 > +      * shadow. */
 

Re: [PATCH weston v4 1/4] simple-dmabuf-drm: Always define ALIGN

[Derek Foreman]

On 2018-03-19 11:45 AM, Guido Günther wrote:

Other backends might want to use it.

Signed-off-by: Guido Günther <a...@sigxcpu.org>


Reviewed-by: Derek Foreman <der...@osg.samsung.com>
(and pushed)

Thanks,
Derek


---
  clients/simple-dmabuf-drm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 4f26e4a9..efe3b7f5 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -65,6 +65,7 @@ struct buffer;
  #define OPT_Y_INVERTED 1  /* contents has y axis inverted */
  #define OPT_IMMEDIATE  2  /* create wl_buffer immediately */
  
+#define ALIGN(v, a) ((v + a - 1) & ~(a - 1))
  
  struct display {

struct wl_display *display;
@@ -215,7 +216,6 @@ intel_device_destroy(struct buffer *my_buf)
  
  #endif /* HAVE_LIBDRM_INTEL */

  #ifdef HAVE_LIBDRM_FREEDRENO
-#define ALIGN(v, a) ((v + a - 1) & ~(a - 1))
  
  static int

  fd_alloc_bo(struct buffer *buf)



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] wayland-egl: Make symbol test fail on failure

[Derek Foreman]

On 2018-03-19 11:20 AM, Eric Engestrom wrote:

On Monday, 2018-03-19 16:10:57 +, Daniel Stone wrote:

Hi,

On 19 March 2018 at 16:08, Eric Engestrom  wrote:

On Monday, 2018-03-19 15:13:14 +, Daniel Stone wrote:

+if ! test -f "$LIB"; then
+ echo "Test binary \"$LIB\" does not exist"
+ exit 99
+fi
+
+if ! test -n "$NM"; then
+ echo "nm environment variable not set"
+ exit 99


99? Were you looking for the "skip this test" 77?


I did mean 99 'some kind of inexplicable internal error happened'
rather than 77 skip, but I have no strong opinion on it and am happy
to change to whatever is suggested.


I guess "don't have the tools to test this, skipping" would be fine, but
I'm not really involved in the wayland project so my opinion isn't the
one that matters the most :P


Additional review is valuable, thanks. :)


"I have no strong feelings one way or the other"


In the absence of strong feelings, I've pushed this as-is.

Along with the recent version of the "pass nm path to check script" patch.

Thanks,
Derek



Cheers,
Daniel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] libweston-desktop/xdg-shell-v6: Fix crash when surface has buffer at creation

[Derek Foreman]

On 2018-03-13 01:18 PM, Quentin Glidic wrote:

On 3/13/18 5:34 PM, Derek Foreman wrote:
When a surface has a buffer at creation time we send an error, which 
results

in a disconnection and all resources being destroyed.

Since we send that error and return before performing the 
configure_list init

weston_desktop_xdg_surface_destroy() will walk an uninitialized list and
dereference a NULL pointer.

Initializing the list earlier prevents this from happening.

Signed-off-by: Derek Foreman <der...@osg.samsung.com>


Good catch:
Reviewed-by: Quentin Glidic <sardemff7+...@sardemff7.net>


And pushed.
Thanks,
Derek


Thanks,


---
  libweston-desktop/xdg-shell-v6.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libweston-desktop/xdg-shell-v6.c 
b/libweston-desktop/xdg-shell-v6.c

index f9902ff0..8fa01a32 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -1370,6 +1370,7 @@ 
weston_desktop_xdg_shell_protocol_get_xdg_surface(struct wl_client 
*wl_client,

  surface->desktop = weston_desktop_client_get_desktop(client);
  surface->surface = wsurface;
+    wl_list_init(>configure_list);
  surface->desktop_surface =
  weston_desktop_surface_create(surface->desktop, client,
@@ -1395,8 +1396,6 @@ 
weston_desktop_xdg_shell_protocol_get_xdg_surface(struct wl_client 
*wl_client,
 "xdg_surface must not have a buffer at 
creation");

  return;
  }
-
-    wl_list_init(>configure_list);
  }
  static void






___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel