Re: XWayland on i915GM

[Tiago Vignatti]

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

[Knut Petersen]

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

[Pekka Paalanen]

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

[Kristian Høgsberg]

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

[Bill Spitzak]

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

[Bill Spitzak]

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

[Daniel Stone]

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

[jegde jedge]

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

[Kristian Høgsberg]

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

[Bill Spitzak]

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

[jegde jedge]

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

[Kristian Høgsberg]

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

[Wang, Quanxian]

> -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

[Kristian Høgsberg]

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

[Wang, Quanxian]

> -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

[Pekka Paalanen]

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