Re: [RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged
Hi, >From IRC conversations with krh a long time ago, this is indeed intentional and the cursor surface should "lose its role" in modern parlance. The original intention was to prevent glitching of the cursor surface. e.g. If the left side of the surface has a resize left cursor, you leave, and hover over the right, you don't want to see the resize left cursor for a split second before the resize right cursor appears. The original implementation of Weston respected this and would only change the cursor on set_cursor calls and would not even remember a per-client cursor surface. This behavior has probably been lost in numerous reactors by now. On Tue, Jul 24, 2018, 2:52 PM Daniel Stone wrote: > Hey, > > On Tue, 24 Jul 2018 at 22:45, Derek Foreman > wrote: > > On 2018-07-22 05:55 AM, Daniel Stone wrote: > > > 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. > > To be fair, this has changed a fair bit with atomic, so I'm not > surprised it's different in master. But I am a bit disappointed it's > not perfect yet. ;) > > 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: [RFC libinput] dox: switch to sphinx for the user-visible documentation
On Tue, Jul 24, 2018 at 03:42:50PM +1000, Peter Hutterer wrote: > Sending this out as patch even though what really matters is the > output. Which is... here, tadaaa! > > https://people.freedesktop.org/~whot/libinput-rtd/ fwiw, I've played around with it a bit and updated the URL above. It now has a proper hierarchy, more doxygen tags are being parsed. There are still a few parsing issues that need to be fixed manually. And the doc needs a general do-over to split it better into user docs vs developer docs. And of course doxygen itself needs to be separated, generated, and link to the sphinx docs. But otherwise this looks quite nice IMO. Cheers, Peter ___ 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
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
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: DRM page-flip with damage for weston
> > The damage region received during output repaint is in Weston's global > co-ordinate space. To shift to CRTC co-ordinates, you need to > translate the damage region by (-output->x, -output->y). When we are > using the renderer, there is no scaling, so CRTC co-ordinates and > framebuffer co-ordinates are guaranteed to be equal. This only > accounts for the primary plane; damage to views on other planes is > considered separately. > > Also, if you are not already working from git master, I recommend you > do so, as the DRM backend has changed hugely since 4.0.0. Thanks Daniel for help and it the change suggested by you are working with my drm code. Another question regarding Weston, does each output in Weston create separate scan-out framebuffer always ? Thanks, Deepak > > Cheers, > Daniel ___ 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
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
