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 , rvalue=0xbffb8b8c, avalue=0x83ae6b8) at ../../../libffi/src/x86/ffi.c:324 #8 0xb74c8aa5 in wl_closure_invoke (closure=0x83ae648, target=0x83ad9b0, func=0xb74c4272 , 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 --- 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#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 *y) +{ + struct geometry *g = surface->geometry; + + /* pure rotation around origin by sine and cosine */ + *x = g->c
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" mailto:quanxian.w...@intel.com>> > > commit f7b156cef1ed8081df6f25cc0e66c8d7fbf414fc > Author: Wang Quanxian > 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 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. 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 > +++ b/src/compositor.h > @@ -109,7 +109,7 @@ struct weston_spring { > double current; > double target; > double previous; > - uint32_t timestamp; > + uint64_t timestamp; > }; > > enum { > @@ -164,7 +164,7 @@ struct weston_output { > struct weston_output_zoom zoom; > int dirty; > struct wl_signal frame_signal; > - uint32_t frame_time; > + uint64_t frame_time; > int disable_planes; > > char *make, *model; > @@ -493,7 +493,7 @@ void > weston_spring_init(struct weston_spring *spring, >double k, double current, double target); > void > -weston_spring_update(struct weston_spring *spring, uint32_t msec); > +weston_spring_update(struct weston_spring *spring, uint64_t msec); > int > weston_spring_done(struct weston_spring *spring); > > @@ -543,7 +543,7 @@ void > weston_plane_release(struct weston_plane *plane); > > void > -weston_output_finish_frame(struct weston_output *output, uint32_t msecs); > +weston_output_finish_frame(struct weston_output *output, uint64_t msecs); > void > weston_output_schedule_repaint(struct weston_output *output); > void > diff --git a/src/util.c b/src/util.c > index 4ff451a..34b140e 100644 > --- a/src/util.c > +++ b/src/util.c > @@ -42,7 +42,7 @@ weston_spring_init(struct weston_spring *spring, > } > > WL_EXPORT void > -weston_spring_update(struct weston_spring *spring, uint32_t msec) > +weston_spring_update(struct weston_spring *spring, uint64_t msec) > { > double force, v, current, step; > > >
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 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 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 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 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 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 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 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 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 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 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" > > mailto:quanxian.w...@intel.com>> > > > > commit f7b156cef1ed8081df6f25cc0e66c8d7fbf414fc > > Author: Wang Quanxian > > 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 > > 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. > > 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 > > +++ b/src/compositor.h > > @@ -109,7 +109,7 @@ struct weston_spring { > > double current; > > double target; > > double previous; > > - uint32_t timestamp; > > + uint64_t timestamp; > > }; > > > > enum { > > @@ -164,7 +164,7 @@ struct weston_output { > > struct weston_output_zoom zoom; > > int dirty; > > struct wl_signal frame_signal; > > - uint32_t frame_time; > > + uint64_t frame_time; > > int disable_planes; > > > > char *make, *model; > > @@ -493,7 +493,7 @@ void > > weston_spring_init(struct weston_spring *spring, > >double k, double current, double target); void > > -weston_spring_update(struct weston_spring *spring, uint32_t msec); > > +weston_spring_update(struc
Re: [PATCH] compositor: fix overflow issue when calculate msecs of vblank
On Wed, Sep 5, 2012 at 9:28 PM, Wang, Quanxian 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" >> > mailto:quanxian.w...@intel.com>> >> > >> > commit f7b156cef1ed8081df6f25cc0e66c8d7fbf414fc >> > Author: Wang Quanxian >> > 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 >> >> 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. 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 >> > +++ b/src/compositor.h >> > @@ -109,7 +109,7 @@ struct weston_spring { >> > double current; >> > double target; >> > double previous; >> > - uint32_t timestamp; >> > + uint64_t timestamp; >> > }; >> > >> > enum { >> > @@ -164,7 +164,7 @@ struct weston_ou
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 > 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" > >> > mailto:quanxian.w...@intel.com>> > >> > > >> > commit f7b156cef1ed8081df6f25cc0e66c8d7fbf414fc > >> > Author: Wang Quanxian > >> > 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 > >> > >> 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 > >> >
Re: [PATCH] Wayland X server uses xwayand.conf instead of xorg.conf
On Wed, 05 Sep 2012 12:44:27 -0700 Bill Spitzak wrote: > 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? You need to read 'man 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. What I said was not a suggested solution but pointing out a flaw in your plan. I never mentioned $prefix. > 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). You are missing my point. I still say: > Pekka Paalanen wrote: > > > > 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. Please, carefully read 'man xorg.conf' on how xorg.conf.d works. I assume you will want to have xwayland.conf.d replacing xorg.conf.d, just like you suggest xwayland.conf replaces xorg.conf. It is starting to sound like we should just always pass -configdir and -config as arguments to X, and have the directory passed with -configdir set in weston's ./configure, instead of changing xorg-server. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel