[PATCH weston] compositor: automatically set opaque region for color formats
Some color formats are naturally opaque: RGB, XRGB, YUV formats without
A channel. For these, automatically set the opaque region to whole
surface.
Note:
If a client first sends a buffer with opaque color format, and then
sends another buffer of the same size but with non-opaque color format,
the opaque region in the server is no longer what the client expects
based on protocol: it has been changed from what the client earlier
specified into whole surface. Therefore this is a protocol change.
---
This patch has been only compile-tested, because I'm not sure we can do
it like this, and temporary opaque region setup would be more complex.
Kristian, do we really want to go there?
---
src/compositor.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 2b963f5..e7c2c88 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -798,10 +798,15 @@ weston_surface_attach(struct wl_surface *surface, struct
wl_buffer *buffer)
glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
es-pitch, es-buffer-height, 0,
GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
- if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
+ if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
{
es-shader = ec-texture_shader_rgbx;
- else
+ pixman_region32_union_rect(es-opaque, es-opaque,
+ 0, 0,
+ buffer-width,
+ buffer-height);
+ } else {
es-shader = ec-texture_shader_rgba;
+ }
} else if (ec-query_buffer(ec-egl_display, buffer,
EGL_TEXTURE_FORMAT, format)) {
for (i = 0; i es-num_images; i++)
@@ -834,6 +839,18 @@ weston_surface_attach(struct wl_surface *surface, struct
wl_buffer *buffer)
break;
}
+ /* opaque color formats */
+ switch (format) {
+ case EGL_TEXTURE_RGB:
+ case EGL_TEXTURE_Y_UV_WL:
+ case EGL_TEXTURE_Y_U_V_WL:
+ case EGL_TEXTURE_Y_XUXV_WL:
+ pixman_region32_union_rect(es-opaque, es-opaque,
+ 0, 0,
+ buffer-width,
+ buffer-height);
+ }
+
ensure_textures(es, num_planes);
for (i = 0; i num_planes; i++) {
attribs[0] = EGL_WAYLAND_PLANE_WL;
--
1.7.8.6
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XWayland on i915GM
On 09/04/2012 11:04 PM, Knut Petersen wrote: I don't think the hardware is the problem. You're compiling Xwayland without debugging symbols so it's a bit tricky to tell what's going on, but my guess is that you're facing the same issues other guys had here on the ml; try to check if you're using the correct version of libxtrans: Sorry, it´s not that easy. I built _everything_ that belongs to Xorg / Wayland/ Weston from the git repositories with -g3 -O0 -H. So it´s definitely not an old libxtrans, and I greped the log to ensure that not a single old Xorg component was used. try to attach gdb on X then: http://lists.freedesktop.org/archives/wayland-devel/2012-August/005161.html Tiago ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XWayland on i915GM
try to attach gdb on X then: Did that already. #0 0xb5b35521 in xcb_cursor_images_load_cursor (wm=0x83b7030, images=0x0) at window-manager.c:182 #1 0xb5b355d6 in xcb_cursor_library_load_cursor (wm=0x83b7030, file=0xb5b3ea94 top_side) at window-manager.c:207 #2 0xb5b371ab in weston_wm_create_cursors (wm=0x83b7030) at window-manager.c:988 #3 0xb5b381a3 in weston_wm_create (wxs=0x83b8bf0) at window-manager.c:1469 #4 0xb5b3a41a in bind_xserver (client=0x838a248, data=0x83b8bf0, version=1, id=11) at launcher.c:165 #5 0xb74c4318 in display_bind (client=0x838a248, resource=0x83ad9b0, name=12, interface=0x83ae71c xserver, version=1, id=11) at wayland-server.c:923 #6 0xb74bb522 in ffi_call_SYSV () at ../../../libffi/src/x86/sysv.S:64 #7 0xb74bb2be in ffi_call (cif=0x83ae6a0, fn=0xb74c4272 display_bind, rvalue=0xbffb8b8c, avalue=0x83ae6b8) at ../../../libffi/src/x86/ffi.c:324 #8 0xb74c8aa5 in wl_closure_invoke (closure=0x83ae648, target=0x83ad9b0, func=0xb74c4272 display_bind, data=0x838a248) at connection.c:855 #9 0xb74c2fb1 in wl_client_connection_data (fd=25, mask=1, data=0x838a248) at wayland-server.c:284 #10 0xb74c671d in wl_event_source_fd_dispatch (source=0x84908f8, ep=0xbffb8c40) at event-loop.c:79 #11 0xb74c7065 in wl_event_loop_dispatch (loop=0x80654e0, timeout=-1) at event-loop.c:410 #12 0xb74c4896 in wl_display_run (display=0x80654b0) at wayland-server.c:1103 #13 0x08056679 in main (argc=1, argv=0xbffb9044) at compositor.c:4131 With that the problem is easy to identify: An undetected fail of XcursorLibraryLoadImages() in xcb_cursor_images_load_cursor(). The returned null-pointer is assigned to images, later it causes the segmentation violation in xcb_cursor_images_load_cursor(). Immediate workaround: Make sure that a proper xcursor theme is installed as default: export XCURSOR_PATH=$PREFIX/share/icons ln -s path_to_cursor_theme $XCURSOR_PATH/default $PREFIX/bin/weston --xserver Todo: The build documentation really should be updated to document the xcursor dependency. In the code the pointer returned by XcursorLibraryLoadImages() must be checked before it is used, but I think the best idea would be to abort at weston startup if the required cursor images are not provided by the system. cu, Knut ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[call for testing] clients: add cliptest program
Cliptest is for controlled testing of the calculate_edges() function in
compositor.c. The function is copied verbatim into cliptest.c.
Signed-off-by: Pekka Paalanen ppaala...@gmail.com
---
clients/Makefile.am |5 +
clients/cliptest.c | 819 +++
2 files changed, 824 insertions(+), 0 deletions(-)
create mode 100644 clients/cliptest.c
Hi all,
this patch contains a new polygon clipping algorithm for the rectangle-rectangle
intersection computation, a.k.a calculate_edges() function. Right now, it is
only in the cliptest program for testing.
I would like to ask people to try to break the algorithm.
Apply this patch, and run cliptest in a Wayland compositor. You will see a blue
rectangle, which is the clipping area, and a red rectangle which represents
a surface. The red dot indicates the orientation of the surface.
The algorithm computes the intersection of these two rectangles. In the
image, the algorithm produces the green line with vertex indices. The
green line should be exactly the boundary of the intersection (purple). See:
http://people.collabora.com/~pq/geometry-test-8.png
If you can produce an image, where the green line is wrong, like it was in
http://people.collabora.com/~pq/geometry-test-5.png
please, take a screenshot and send it to me.
You can control the rectangles by:
* clip box position: mouse left drag, keys: w a s d
* clip box size: mouse right drag, keys: i j k l
* surface orientation: mouse wheel, keys: n m
* surface transform disable key: r
Also, if you try this, and cannot break it, let me know you tried, still.
Thanks,
pq
diff --git a/clients/Makefile.am b/clients/Makefile.am
index 1b7fa10..a72 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -48,6 +48,7 @@ terminal = weston-terminal
clients_programs = \
flower \
image \
+ cliptest\
dnd \
smoke \
resizor \
@@ -88,6 +89,10 @@ weston_terminal_LDADD = $(toolkit_libs) -lutil
image_SOURCES = image.c
image_LDADD = $(toolkit_libs)
+cliptest_SOURCES = cliptest.c
+cliptest_CPPFLAGS = $(AM_CPPFLAGS) $(PIXMAN_CFLAGS)
+cliptest_LDADD = $(toolkit_libs) $(PIXMAN_LIBS)
+
dnd_SOURCES = dnd.c
dnd_LDADD = $(toolkit_libs)
diff --git a/clients/cliptest.c b/clients/cliptest.c
new file mode 100644
index 000..9531728
--- /dev/null
+++ b/clients/cliptest.c
@@ -0,0 +1,819 @@
+/*
+ * Copyright © 2012 Collabora, Ltd.
+ * Copyright © 2012 Rob Clark
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided as
+ * is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+/* cliptest: for debugging calculate_edges() function, which is copied
+ * from compositor.c.
+ * controls:
+ * clip box position: mouse left drag, keys: w a s d
+ * clip box size: mouse right drag, keys: i j k l
+ * surface orientation: mouse wheel, keys: n m
+ * surface transform disable key: r
+ */
+
+#include stdint.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include fcntl.h
+#include libgen.h
+#include unistd.h
+#include math.h
+#include time.h
+#include pixman.h
+#include cairo.h
+#include assert.h
+
+#include linux/input.h
+#include wayland-client.h
+
+#include window.h
+
+typedef float GLfloat;
+
+struct geometry {
+ pixman_box32_t clip;
+
+ pixman_box32_t surf;
+ float s; /* sin phi */
+ float c; /* cos phi */
+ float phi;
+};
+
+struct weston_surface {
+ struct {
+ int enabled;
+ } transform;
+
+ struct geometry *geometry;
+};
+
+static void
+weston_surface_to_global_float(struct weston_surface *surface,
+ GLfloat sx, GLfloat sy, GLfloat *x, GLfloat
Re: [PATCH] Wayland X server uses xwayand.conf instead of xorg.conf
Are you saying that if I make $PREFIX/etc/X11/xorg.conf.d/foo and put my config in there, xwayland will read it? And it will then ignore the xorg.conf? I still do not see this solving the real problem however. The normal Xorg will follow the exact same rules, so if xwayland is compiled without $PREFIX then it is impossible to use this to make xwayland and normal Xorg see different config files. Even with $PREFIX this does not allow xwayland to see no config file, as the missing file will make it still fall back to searching everywhere and it will find the xorg.conf file that I do not want it to see. So I still feel that my solution of changing the conf file name is the only thing that will work. We can put it in xorg.conf.d if that makes some kind of sense (though I completely do not understand the purpose of this). Pekka Paalanen wrote: On Tue, 04 Sep 2012 12:00:09 -0700 Bill Spitzak spit...@gmail.com wrote: However I then realized that changing the search path would not fix any xwayland because a real installation would not have a $PREFIX anyway, so there had to be a different method to give wayland a different .conf file. So at that point I switched to using a different name for the .conf file. I don't know if there are other conflicting files in xorg.conf.d. If so they may need renaming for the wayland version too. The whole point of xorg.conf.d is that files can have any names, and they all will be read in in alphabetical order. Maybe they need a .conf suffix or not, don't know. If you are changing names, you would have to change the name of the directory. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: automatically set opaque region for color formats
Doesn't the compositor have access to what type the surfaces are? It can then know the surface is opaque and ignore the opaque region there. Then if the client changes back to a non-opaque surface the opaque region is unchanged and starts being used again. I would expect this to be slightly more efficient because the compositor will also know that the opaque region is exactly equal to the surface area. Pekka Paalanen wrote: Some color formats are naturally opaque: RGB, XRGB, YUV formats without A channel. For these, automatically set the opaque region to whole surface. Note: If a client first sends a buffer with opaque color format, and then sends another buffer of the same size but with non-opaque color format, the opaque region in the server is no longer what the client expects based on protocol: it has been changed from what the client earlier specified into whole surface. Therefore this is a protocol change. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: automatically set opaque region for color formats
On 5 September 2012 20:49, Bill Spitzak spit...@gmail.com wrote: Doesn't the compositor have access to what type the surfaces are? It can then know the surface is opaque and ignore the opaque region there. Then if the client changes back to a non-opaque surface the opaque region is unchanged and starts being used again. I would expect this to be slightly more efficient because the compositor will also know that the opaque region is exactly equal to the surface area. ... yeah, that's literally exactly what this patch does. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
bare bones opengl weston client sample
Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Right under your nose: http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c Kristian On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge bubba...@gmail.com wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: automatically set opaque region for color formats
Daniel Stone wrote: On 5 September 2012 20:49, Bill Spitzak spit...@gmail.com wrote: Doesn't the compositor have access to what type the surfaces are? It can then know the surface is opaque and ignore the opaque region there. Then if the client changes back to a non-opaque surface the opaque region is unchanged and starts being used again. I would expect this to be slightly more efficient because the compositor will also know that the opaque region is exactly equal to the surface area. ... yeah, that's literally exactly what this patch does. If so then I don't understand this (quoted from original message): Note: If a client first sends a buffer with opaque color format, and then sends another buffer of the same size but with non-opaque color format, the opaque region in the server is no longer what the client expects based on protocol: it has been changed from what the client earlier specified into whole surface. Therefore this is a protocol change. This implies that it actually changes the opaque area, instead of the compositor just using the surface area *instead* of the opaque area, which I think makes a lot more sense. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Thanks, I tried that route. it is a gles2 not gles or opengl example; and that will not work with the fixed function pipeline functions like glPushMatrix et.al. I went with the gears example since it binds the OPENGL API but it uses the window/toytoolkit/libshared stuff with cairo and I don't have enough insight to what is needed and what isnt. Is it as simple as replacing line 131: ret = eglBindAPI(EGL_OPENGL_ES_API); with EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? Thank you. I'll try in the morning. On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg k...@bitplanet.net wrote: Right under your nose: http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c Kristian On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge bubba...@gmail.com wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
On Wed, Sep 5, 2012 at 8:11 PM, jegde jedge bubba...@gmail.com wrote: Thanks, I tried that route. it is a gles2 not gles or opengl example; and that will not work with the fixed function pipeline functions like glPushMatrix et.al. Sure, it's a gles2 example, but it shows you how to get a minimal egl/gles2 client working under wayland. I figured you'd want to replace the gles2 code with your own code anyway, and yes, it is just a matter of using EGL_OPENGL_API, removing the context attributes and linking to libGL. Kristian I went with the gears example since it binds the OPENGL API but it uses the window/toytoolkit/libshared stuff with cairo and I don't have enough insight to what is needed and what isnt. Is it as simple as replacing line 131: ret = eglBindAPI(EGL_OPENGL_ES_API); with EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? Thank you. I'll try in the morning. On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg k...@bitplanet.net wrote: Right under your nose: http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c Kristian On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge bubba...@gmail.com wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH] compositor: fix overflow issue when calculate msecs of vblank
-Original Message-
From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
Sent: Thursday, September 06, 2012 10:31 AM
To: Wang, Quanxian
Cc: wayland-devel@lists.freedesktop.org; Guo, Chaohong; Bradford, Robert
Subject: Re: [PATCH] compositor: fix overflow issue when calculate msecs of
vblank
On Wed, Sep 5, 2012 at 9:28 PM, Wang, Quanxian quanxian.w...@intel.com
wrote:
-Original Message-
From: Kristian Høgsberg [mailto:hoegsb...@gmail.com]
Sent: Thursday, September 06, 2012 3:28 AM
To: Wang, Quanxian
Cc: wayland-devel@lists.freedesktop.org; Guo, Chaohong; Bradford,
Robert
Subject: Re: [PATCH] compositor: fix overflow issue when calculate
msecs of vblank
On Wed, Sep 05, 2012 at 03:35:32AM +, Wang, Quanxian wrote:
From Quanxian Wang
quanxian.w...@intel.commailto:quanxian.w...@intel.com
commit f7b156cef1ed8081df6f25cc0e66c8d7fbf414fc
Author: Wang Quanxian quanxian.w...@intel.com
Date: Wed Sep 5 11:30:38 2012 +0800
Change int to long to avoid the overflow when calculation
vblank msecs
secs and nsecs are from vblank event, the number of secs is
very
big(134xxx),
when turns secs to msecs(multiple 1000), it will exceed uint32
max value.
Signed-Off-By Quanxian Wang quanxian.w...@intel.com
No, the overflow is itentional. The timestamp is just a milisecond
value with an unspecified epoch, only differences between timestamps
are useful. It may overflow and that's expected. If you use
uint32_t math, you can subtract timestamps before and after an
overflow and still get the number of miliseconds elapsed.
[Wang, Quanxian] I agree your point partly. My different point is for
example,
take 100 as the limit, you have 101 and 99 number, the diff is 2. To 101,
after
conversion, the number is 01 and to 99 is 99. The diff turns to be 98 and
compared with previous 2 it turns to bigger. In the limit, it is the safe,
cross the
border is not safe.
No unsigned integer math in C is defined so that this actually works.
Assume four bit integers (that is, our range is 0-15). Suppose you have
timestamps 14 and 17. The difference is 17 - 14 = 3. But with 4 bit unsigned
integers, the values are truncated to 14 and 1. However,
1 - 14 still gives the right result.
[Wang, Quanxian] yes. It is minus. I see. Thanks
Kristian
Kristian
diff --git a/src/compositor-drm.c b/src/compositor-drm.c index
df81aba..8b6285c 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -447,7 +447,7 @@ vblank_handler(int fd, unsigned int frame,
unsigned
int sec, unsigned int usec,
struct drm_sprite *s = (struct drm_sprite *)data;
struct drm_compositor *c = s-compositor;
struct drm_output *output = s-output;
- uint32_t msecs;
+ uint64_t msecs = 0;
output-vblank_pending = 0;
@@ -480,7 +480,7 @@ page_flip_handler(int fd, unsigned int frame,
unsigned int sec, unsigned int usec, void *data) {
struct drm_output *output = (struct drm_output *) data;
- uint32_t msecs;
+ uint64_t msecs=0;
output-page_flip_pending = 0;
@@ -496,7 +496,7 @@ page_flip_handler(int fd, unsigned int frame,
output-next = NULL;
if (!output-vblank_pending) {
- msecs = sec * 1000 + usec / 1000;
+ msecs = (uint64_t)sec * 1000 + (uint64_t)usec /
+ 1000;
weston_output_finish_frame(output-base, msecs);
}
}
diff --git a/src/compositor.c b/src/compositor.c index
f4263ac..37c52bc 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1026,7 +1026,7 @@ weston_output_damage(struct weston_output
*output)
static void
fade_frame(struct weston_animation *animation,
- struct weston_output *output, uint32_t msecs)
+ struct weston_output *output, uint64_t msecs)
{
struct weston_compositor *compositor =
container_of(animation, @@ -1129,7 +1129,7 @@
surface_accumulate_damage(struct weston_surface *surface, }
static void
-weston_output_repaint(struct weston_output *output, uint32_t
msecs)
+weston_output_repaint(struct weston_output *output, uint64_t
+msecs)
{
struct weston_compositor *ec = output-compositor;
struct weston_surface *es;
@@ -1222,7 +1222,7 @@ weston_compositor_read_input(int fd,
uint32_t
mask, void *data) }
WL_EXPORT void
-weston_output_finish_frame(struct weston_output *output, uint32_t
msecs)
+weston_output_finish_frame(struct weston_output *output, uint64_t
+msecs)
{
struct weston_compositor *compositor = output-compositor;
struct wl_event_loop *loop = diff --git a/src/compositor.h
b/src/compositor.h index
7a8058e..f49da84 100644
--- a/src/compositor.h
+++
