Otherwise we may detect wobble despite having a series of valid y movements,
e.g. the following sequence was detected as wobble:
x: 1 y: 0
x: 0 y: 1
x: 0 y: 2
x: 0 y: 2
x: 0 y: 1
x: -1 y: 0
x: 1 y: 0
Avoid this by resetting the history when w
On Mon, 23 Apr 2018 14:29:14 +0100
Emmanuele Bassi wrote:
> From: Emmanuele Bassi
>
> This is an RFC/work-in-progress patch series for adding a Meson build to
> Wayland.
>
> It's not ready for merge, as it has a couple of issues:
Awesome!
> - the Doxygen-generated man pages are installed un
From: Emmanuele Bassi
The tests that run exec-fd-leak-checker expect the binary to be located
in the current directory. This is not always the case; for instance, the
binaries could be built under `tests`, but be invoked under the
top-level build directory.
We can use an environment variable to
From: Emmanuele Bassi
Meson is a next generation build system, simpler than Autotools and,
more importantly, faster and more portable. While the latter
consideration is of lesser importance for Wayland, being easier to
understand and faster are pretty much key reasons to switch.
This is mostly a
From: Emmanuele Bassi
Currently broken, as it does not install the generated man pages under
the system's man directory, but under datadir.
---
doc/doxygen/.gitignore | 1 +
doc/doxygen/gen-doxygen.py | 90 +
doc/doxygen/meson.build | 112
From: Emmanuele Bassi
This is an RFC/work-in-progress patch series for adding a Meson build to
Wayland.
It's not ready for merge, as it has a couple of issues:
- the Doxygen-generated man pages are installed under $datadir/man,
instead of $mandir, because of Doxygen peculiarities, like forc
From: Emmanuele Bassi
There are ancillary man pages not built by Doxygen that we need to
generate an install.
---
doc/man/meson.build | 64 +
doc/meson.build | 1 +
2 files changed, 65 insertions(+)
create mode 100644 doc/man/meson.build
diff --
On Mon, 23 Apr 2018 07:08:57 -0400
nerdopolis wrote:
> On Tuesday, January 23, 2018 10:15:42 PM EDT nerdopolis wrote:
> > These patches make Weston handle multiple seats. Fixes from the last
> > attempt include updating fbdev_set_screen_info , updating some fuzz,
> > and making the selection of
On Tuesday, January 23, 2018 10:15:42 PM EDT nerdopolis wrote:
> These patches make Weston handle multiple seats. Fixes from the last
> attempt include updating fbdev_set_screen_info , updating some fuzz,
> and making the selection of the framebuffer device similar to
> compositor-drm.c by favori
On Tue, 10 Apr 2018 12:37:15 +0300
Pekka Paalanen wrote:
> On Mon, 9 Apr 2018 12:12:49 +1000
> Peter Hutterer wrote:
>
> > On Fri, Mar 23, 2018 at 02:00:56PM +0200, Pekka Paalanen wrote:
> > > From: Pekka Paalanen
> > >
> > > notify_touch_cal() is an extended form of notify_touch(), adding
On Mon, 9 Apr 2018 12:12:49 +1000
Peter Hutterer wrote:
> On Fri, Mar 23, 2018 at 02:00:56PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > notify_touch_cal() is an extended form of notify_touch(), adding
> > normalized touch coordinates which are necessary for calibrating a
> >
From: Pekka Paalanen
Pixman-renderer uses a single internal shadow buffer. It is enough to
composite the current damage into shadow, but the copy to hw buffer
needs to include the previous damage because of double-buffering in
DRM-backend.
This patch lets pixman-renderer do exactly that without
From: Pekka Paalanen
Allow global control of the pixman shadow buffers. The compositor can
choose whether all output use or do not use a shadoe buffer with the
pixman renderer.
The option is added to the end of struct weston_drm_backend_config to
avoid bumping WESTON_DRM_BACKEND_CONFIG_VERSION.
From: Pekka Paalanen
Add a flag to pixman-renderer for initializing the output with a shadow
framebuffer. All backends were getting the shadow implcitly, so all
backends are modified to ask for the shadow explicitly.
Using a shadow buffer is usually beneficial, because read-modify-write
cycles (
From: Pekka Paalanen
Allows to control the Pixman-renderer shadow framebuffer usage from
weston.ini. It defaults to enabled, and whether it is a good idea to
disable or not depends on the platform and the workload.
Signed-off-by: Pekka Paalanen
Signed-off-by: Fabien Lahoudere
---
compositor/m
Optimizes pixman renderer by:
- optimizing compositing damage in DRM/pixman
Reduce Weston's CPU usage by avoiding unnecessary compositing when updating
the shadow buffer in pixman-renderer, under the DRM backend. The test was a
proprietary graphical X11 application in demo mode. The effect
Optimizes pixman renderer by:
- optimizing compositing damage in DRM/pixman
Reduce Weston's CPU usage by avoiding unnecessary compositing when updating
the shadow buffer in pixman-renderer, under the DRM backend. The test was a
proprietary graphical X11 application in demo mode. The effect
From: Pekka Paalanen
Add a flag to pixman-renderer for initializing the output with a shadow
framebuffer. All backends were getting the shadow implcitly, so all
backends are modified to ask for the shadow explicitly.
Using a shadow buffer is usually beneficial, because read-modify-write
cycles (
From: Pekka Paalanen
Allows to control the Pixman-renderer shadow framebuffer usage from
weston.ini. It defaults to enabled, and whether it is a good idea to
disable or not depends on the platform and the workload.
Signed-off-by: Pekka Paalanen
Signed-off-by: Fabien Lahoudere
---
compositor/m
From: Pekka Paalanen
Pixman-renderer uses a single internal shadow buffer. It is enough to
composite the current damage into shadow, but the copy to hw buffer
needs to include the previous damage because of double-buffering in
DRM-backend.
This patch lets pixman-renderer do exactly that without
From: Pekka Paalanen
Allow global control of the pixman shadow buffers. The compositor can
choose whether all output use or do not use a shadoe buffer with the
pixman renderer.
The option is added to the end of struct weston_drm_backend_config to
avoid bumping WESTON_DRM_BACKEND_CONFIG_VERSION.
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
This revision adds an additional description field.
.../xdg-output/xdg-output-unstable-v1.xml | 46 ++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
b/uns
On Mon, 23 Apr 2018 03:42:31 -0400
Simon Ser wrote:
> Hi all,
>
> While writing a protocol, I've been trying to reference symbols from another
> protocol. While it seems to work fine for interfaces, it fails for enums:
>
> error: could not find enumeration wl_output.transform
>
> Is this b
Hi all,
While writing a protocol, I've been trying to reference symbols from another
protocol. While it seems to work fine for interfaces, it fails for enums:
error: could not find enumeration wl_output.transform
Is this by design? It seems odd to me that interfaces work but enums don't.
Th
24 matches
Mail list logo
