date:20121025

Re: Newest weston does not compile gears demo

2012-10-25 Thread Pekka Paalanen

On Wed, 24 Oct 2012 11:18:38 -0700
Bill Spitzak spit...@gmail.com wrote:

 For a little while the OpenGL gears demo was being compiled by weston. 
 But not any more. How do I make it compile? Just make gears does not work.

The intended behavior is that demos requiring full GL (gears and
weston-screensaver) are not built, if you configure
using --with-cairo-glesv2. This switch claims, that your Cairo is built
for GLESv2 instead of full GL, and therefore full GL apps cannot be
supported.

I'm not aware of bugs in the build files currently, but that's not
impossible, either.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] server: fix new id printing in closure debug on x86

2012-10-25 Thread Arnaud Vrac

---
 src/connection.c |4 +---
 src/wayland-server.c |4 ++--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/connection.c b/src/connection.c
index 141875e..ed2666b 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -1015,10 +1015,8 @@ wl_closure_print(struct wl_closure *closure, struct 
wl_object *target, int send)
(closure-message-types[i - 2]) ?
 closure-message-types[i - 2]-name :
  [unknown]);
-   if (send  value-new_id != 0)
+   if (value-new_id != 0)
fprintf(stderr, %u, value-new_id);
-   else if (!send  value-object != NULL)
-   fprintf(stderr, %u, value-object-id);
else
fprintf(stderr, nil);
break;
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 38ceb56..de67081 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -288,11 +288,11 @@ wl_client_connection_data(int fd, uint32_t mask, void 
*data)
break;
}
 
+   deref_new_objects(closure);
+
if (wl_debug)
wl_closure_print(closure, object, false);
 
-   deref_new_objects(closure);
-
wl_closure_invoke(closure, object,
  object-implementation[opcode], client);
 
-- 
1.7.10.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Software rendering with Mesa and Wayland 1.0

2012-10-25 Thread nerdopolis

Hi.

I am trying to get the fallback software rendering working for Weston

It seems now I am getting this output when I export, EGL_LOG_LEVEL=debug

libEGL debug: Native platform type: wayland (autodetected)
libEGL debug: EGL search path is /opt/lib/i386-linux-gnu/egl
libEGL debug: added /opt/lib/i386-linux-gnu/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: added egl_glx to module array
libEGL debug: dlopen(/opt/lib/i386-linux-gnu/egl/egl_gallium.so)
libEGL info: use wayland for display 0x9b084f8
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in 
eglInitialize(failed to initialize screen)

libEGL info: use wayland for display 0x9b084f8
libEGL info: use software fallback
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in 
eglInitialize(failed to initialize screen)

libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize

failed to initialize display
failed to create display: No such file or directory



I used to use an older commit, in order to get qtbase to build, as it used to 
fail with the the opengles 2 test failed' or something of that nature, so I 
tried to use that older commit, and attempt to separate and apply the 3 Wayland 
1.0 patches against it. The patches applied, mesa built, however I got the same 
EGL errors as above. 

Now if I can also recall, by using master, I don't think qtbase was failing 
with opengles 2 test failed anymore.

I think that something about the new Wayland patches in Mesa are preventing it 
from allowing software fallback with weston.

Thanks.___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Use a library symbol version map

2012-10-25 Thread Jan Engelhardt

This helps package managers recognize when a new version of libxkbcommon
(with same SONAME) is required due to new symbols.

Signed-off-by: Jan Engelhardt jeng...@inai.de
---
 Makefile.am  |4 +++-
 libxkbcommon.map |   66 ++
 2 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 libxkbcommon.map

diff --git a/Makefile.am b/Makefile.am
index c08bca1..a50422b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,7 +35,9 @@ xkbcommoninclude_HEADERS = \
xkbcommon/xkbcommon-names.h
 
 lib_LTLIBRARIES = libxkbcommon.la
-libxkbcommon_la_LDFLAGS = -no-undefined
+libxkbcommon_la_LDFLAGS = \
+   -Wl,--version-script=${srcdir}/libxkbcommon.map \
+   -no-undefined
 libxkbcommon_la_SOURCES = \
src/xkbcomp/action.c \
src/xkbcomp/action.h \
diff --git a/libxkbcommon.map b/libxkbcommon.map
new file mode 100644
index 000..822d985
--- /dev/null
+++ b/libxkbcommon.map
@@ -0,0 +1,66 @@
+XKBCOMMON_0.2.0 {
+global:
+   xkb_keysym_get_name;
+   xkb_keysym_from_name;
+   xkb_keysym_to_utf8;
+   xkb_keysym_to_utf32;
+   xkb_context_new;
+   xkb_context_ref;
+   xkb_context_unref;
+   xkb_context_set_user_data;
+   xkb_context_get_user_data;
+   xkb_context_include_path_append;
+   xkb_context_include_path_append_default;
+   xkb_context_include_path_reset_defaults;
+   xkb_context_include_path_clear;
+   xkb_context_num_include_paths;
+   xkb_context_include_path_get;
+   xkb_context_set_log_level;
+   xkb_context_get_log_level;
+   xkb_context_set_log_verbosity;
+   xkb_context_get_log_verbosity;
+   xkb_context_set_log_fn;
+   xkb_keymap_new_from_names;
+   xkb_keymap_new_from_file;
+   xkb_keymap_new_from_string;
+   xkb_keymap_ref;
+   xkb_keymap_unref;
+   xkb_keymap_get_as_string;
+   xkb_keymap_num_mods;
+   xkb_keymap_mod_get_name;
+   xkb_keymap_mod_get_index;
+   xkb_keymap_num_layouts;
+   xkb_keymap_layout_get_name;
+   xkb_keymap_layout_get_index;
+   xkb_keymap_num_layouts_for_key;
+   xkb_keymap_num_levels_for_key;
+   xkb_keymap_key_get_syms_by_level;
+   xkb_keymap_num_leds;
+   xkb_keymap_led_get_name;
+   xkb_keymap_led_get_index;
+   xkb_keymap_key_repeats;
+   xkb_state_new;
+   xkb_state_ref;
+   xkb_state_unref;
+   xkb_state_get_keymap;
+   xkb_state_update_key;
+   xkb_state_key_get_syms;
+   xkb_state_key_get_one_sym;
+   xkb_state_key_get_layout;
+   xkb_state_key_get_level;
+   xkb_state_update_mask;
+   xkb_state_serialize_mods;
+   xkb_state_serialize_layout;
+   xkb_state_mod_name_is_active;
+   xkb_state_mod_names_are_active;
+   xkb_state_mod_index_is_active;
+   xkb_state_mod_indices_are_active;
+   xkb_state_mod_index_is_consumed;
+   xkb_state_mod_mask_remove_consumed;
+   xkb_state_layout_name_is_active;
+   xkb_state_layout_index_is_active;
+   xkb_state_led_name_is_active;
+   xkb_state_led_index_is_active;
+local:
+   *;
+};
-- 
1.7.10.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Software rendering with Mesa and Wayland 1.0

2012-10-25 Thread Sannu K

On Thu, Oct 25, 2012 at 5:57 PM, nerdopolis
bluescreen_aven...@verizon.net wrote:
 Hi.



 I am trying to get the fallback software rendering working for Weston



 It seems now I am getting this output when I export, EGL_LOG_LEVEL=debug



 libEGL debug: Native platform type: wayland (autodetected)

 libEGL debug: EGL search path is /opt/lib/i386-linux-gnu/egl

 libEGL debug: added /opt/lib/i386-linux-gnu/egl/egl_gallium.so to module
 array

 libEGL debug: added egl_dri2 to module array

 libEGL debug: added egl_glx to module array

 libEGL debug: dlopen(/opt/lib/i386-linux-gnu/egl/egl_gallium.so)

 libEGL info: use wayland for display 0x9b084f8

 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in
 eglInitialize(failed to initialize screen)



 libEGL info: use wayland for display 0x9b084f8

 libEGL info: use software fallback

 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in
 eglInitialize(failed to initialize screen)



 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize



 failed to initialize display

 failed to create display: No such file or directory







 I used to use an older commit, in order to get qtbase to build, as it used
 to fail with the the opengles 2 test failed' or something of that nature,
 so I tried to use that older commit, and attempt to separate and apply the 3
 Wayland 1.0 patches against it. The patches applied, mesa built, however I
 got the same EGL errors as above.



 Now if I can also recall, by using master, I don't think qtbase was failing
 with opengles 2 test failed anymore.



 I think that something about the new Wayland patches in Mesa are preventing
 it from allowing software fallback with weston.



 Thanks.


 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel



I guess there is some problem with mesa 9.0 and wayland 1.0. Is it
related to that? I am not a wayland developer and I am not much aware
of technical things in wayland so this may not be correct. Just a
guess.

Regards,
Sannu K
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Use a library symbol version map

2012-10-25 Thread Ran Benita

On Thu, Oct 25, 2012 at 04:02:49PM +0200, Jan Engelhardt wrote:
 This helps package managers recognize when a new version of libxkbcommon
 (with same SONAME) is required due to new symbols.

This seems like a good thing to me. But you left out the symbols in
src/compat.c, which provides some ABI backwards compatibility. But since
xkbcommon-compat.h does the rewriting to the new symbols, and the new
release broke API and ABI anyway, I say we should just drop this file.
So if Daniel agrees, we should just remove src/compat.c, before merging
this patch.

And we should also really set --version-info... But that's a different
story.

[One comment below]

 Signed-off-by: Jan Engelhardt jeng...@inai.de
 ---
  Makefile.am  |4 +++-
  libxkbcommon.map |   66 
 ++
  2 files changed, 69 insertions(+), 1 deletion(-)
  create mode 100644 libxkbcommon.map
 
 diff --git a/Makefile.am b/Makefile.am
 index c08bca1..a50422b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -35,7 +35,9 @@ xkbcommoninclude_HEADERS = \
   xkbcommon/xkbcommon-names.h
  
  lib_LTLIBRARIES = libxkbcommon.la
 -libxkbcommon_la_LDFLAGS = -no-undefined
 +libxkbcommon_la_LDFLAGS = \
 + -Wl,--version-script=${srcdir}/libxkbcommon.map \
 + -no-undefined

Would you mind adding -Wl,--no-undefined-version here, also? It checks
the case where you remove a symbol from the code, but not from the
version map (which of course shouldn't happen, but still).

If there's also a way to make it warn about new symbols which are
XKB_EXPORT'ed but are not mentioned in the map, that would be helpful
as well.

Thanks,
Ran

  libxkbcommon_la_SOURCES = \
   src/xkbcomp/action.c \
   src/xkbcomp/action.h \
 diff --git a/libxkbcommon.map b/libxkbcommon.map
 new file mode 100644
 index 000..822d985
 --- /dev/null
 +++ b/libxkbcommon.map
 @@ -0,0 +1,66 @@
 +XKBCOMMON_0.2.0 {
 +global:
 + xkb_keysym_get_name;
 + xkb_keysym_from_name;
 + xkb_keysym_to_utf8;
 + xkb_keysym_to_utf32;
 + xkb_context_new;
 + xkb_context_ref;
 + xkb_context_unref;
 + xkb_context_set_user_data;
 + xkb_context_get_user_data;
 + xkb_context_include_path_append;
 + xkb_context_include_path_append_default;
 + xkb_context_include_path_reset_defaults;
 + xkb_context_include_path_clear;
 + xkb_context_num_include_paths;
 + xkb_context_include_path_get;
 + xkb_context_set_log_level;
 + xkb_context_get_log_level;
 + xkb_context_set_log_verbosity;
 + xkb_context_get_log_verbosity;
 + xkb_context_set_log_fn;
 + xkb_keymap_new_from_names;
 + xkb_keymap_new_from_file;
 + xkb_keymap_new_from_string;
 + xkb_keymap_ref;
 + xkb_keymap_unref;
 + xkb_keymap_get_as_string;
 + xkb_keymap_num_mods;
 + xkb_keymap_mod_get_name;
 + xkb_keymap_mod_get_index;
 + xkb_keymap_num_layouts;
 + xkb_keymap_layout_get_name;
 + xkb_keymap_layout_get_index;
 + xkb_keymap_num_layouts_for_key;
 + xkb_keymap_num_levels_for_key;
 + xkb_keymap_key_get_syms_by_level;
 + xkb_keymap_num_leds;
 + xkb_keymap_led_get_name;
 + xkb_keymap_led_get_index;
 + xkb_keymap_key_repeats;
 + xkb_state_new;
 + xkb_state_ref;
 + xkb_state_unref;
 + xkb_state_get_keymap;
 + xkb_state_update_key;
 + xkb_state_key_get_syms;
 + xkb_state_key_get_one_sym;
 + xkb_state_key_get_layout;
 + xkb_state_key_get_level;
 + xkb_state_update_mask;
 + xkb_state_serialize_mods;
 + xkb_state_serialize_layout;
 + xkb_state_mod_name_is_active;
 + xkb_state_mod_names_are_active;
 + xkb_state_mod_index_is_active;
 + xkb_state_mod_indices_are_active;
 + xkb_state_mod_index_is_consumed;
 + xkb_state_mod_mask_remove_consumed;
 + xkb_state_layout_name_is_active;
 + xkb_state_layout_index_is_active;
 + xkb_state_led_name_is_active;
 + xkb_state_led_index_is_active;
 +local:
 + *;
 +};
 -- 
 1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 6/6] Add informal notes file

2012-10-25 Thread Kristian Høgsberg

On Wed, Oct 24, 2012 at 09:43:10AM +0300, Pekka Paalanen wrote:
 By request on the wayland-devel mailing list, we could start collecting
 useful writings here.
 
 However, this is not meant to be a substitute to proper documentation,
 though I understand it may very well become one. Better than nothing, I
 guess, and hopefully helps in writing real documentation.

I suppose we can do this, but it becomes hard to manage pretty fast.
Ideally we'd work this into the documentation instead.  Over time a
lot of small snippets like this becomes hard to search or make sense of.

This and the previous 5 patches committed.

Kristian

 Feel free to add stuff.
 
 Signed-off-by: Pekka Paalanen ppaala...@gmail.com
 ---
  notes.txt |   77 
 +
  1 files changed, 77 insertions(+), 0 deletions(-)
  create mode 100644 notes.txt
 
 diff --git a/notes.txt b/notes.txt
 new file mode 100644
 index 000..e49052b
 --- /dev/null
 +++ b/notes.txt
 @@ -0,0 +1,77 @@
 +This file is a collection of informal notes, with references to where
 +they were originally written. Each note should have a source and date
 +mentioned. Let's keep these in date order, newest first.
 +
 +
 +
 +---
 +2012-10-23; Pekka Paalanen ppaala...@gmail.com
 +http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html
 +
 +For anyone wanting to port or write their own window manager to Wayland:
 +
 +Most likely you have a desktop window manager. A quick way to get
 +started, is to fork Weston's desktop-shell plugin and start hacking it.
 +Qt could be another good choice, but I am not familiar with it.
 +
 +You also need to understand some concepts. I'm repeating things I wrote
 +to the wayland-devel list earlier, a little rephrased.
 +
 +We need to distinguish three different things here (towards Wayland
 +clients):
 +
 +- compositors (servers)
 + All Wayland compositors are indistinguishable by definition,
 + since they are Wayland compositors. They only differ in the
 + global interfaces they advertise, and for general purpose
 + compositors, we should aim to support the same minimum set of
 + globals everywhere. For instance, all desktop compositors
 + should implement wl_shell. In X, this component corresponds to
 + the X server with a built-in compositing manager.
 +
 +- shells
 + This is a new concept compared to an X stack. A shell defines
 + how a user and applications interact. The most familiar is a
 + desktop (environment). If KDE, Gnome, and XFCE are desktop
 + environments, they all fall under the *same* shell: the desktop
 + shell. You can have applications in windows, several visible at
 + the same time, you have keyboards and mice, etc.
 +
 + An example of something that is not a desktop shell
 + could be a TV user interface. TV is profoundly different:
 + usually no mouse, no keyboard, but you have a remote control
 + with some buttons. Freely floating windows probably do not make
 + sense. You may have picture-in-picture, but usually not several
 + applications showing at once. Most importantly, trying to run
 + desktop applications here does not work due to the
 + incompatible application and user interface paradigms.
 +
 + On protocol level, a shell is the public shell interface(s),
 + currently for desktop it is the wl_shell.
 +
 +- window managers
 + The X Window Managers correspond to different wl_shell
 + implementations, not different shells, since they pratically
 + all deal with a desktop environment. You also want all desktop
 + applications to work with all window managers, so you need to
 + implement wl_shell anyway.
 +
 +I understand there could be special purpose X Window Managers, that
 +would better correspond to their own shells. These window managers
 +might not implement e.g. EWMH by the spec.
 +
 +When you implement your own window manager, you want to keep the public
 +desktop shell interface (wl_shell). You can offer new public
 +interfaces, too, but keep in mind, that someone needs to make
 +applications use them.
 +
 +In Weston, a shell implementation has two parts: a weston plugin, and a
 +special client. For desktop shell (wl_shell) these are src/shell.c and
 +clients/desktop-shell.c. The is also a private protocol extension that
 +these two can explicitly communicate with.
 +
 +The plugin does window management, and the client does most of user
 +interaction: draw backgrounds, panels, buttons, lock screen dialog,
 +basically everything that is on screen.
 +
 +---
 -- 
 1.7.8.6
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2] gles2-renderer: Provide an API for backends to use.

2012-10-25 Thread John Kåre Alsaker

This provides an new API for gles2-renderer. It allows to move most EGL 
initialization code and EGL surface creation into gles2-renderer, which makes 
compositor backends less dependent on gles2-renderer. As a side effect 
weston_output gets a per-renderer state which gles2-renderer uses to store the 
EGL surface.

---
 src/compositor-android.c |  72 +++--
 src/compositor-drm.c |  87 ++---
 src/compositor-wayland.c |  58 +++---
 src/compositor-x11.c |  71 +++--
 src/compositor.h |  23 +-
 src/gles2-renderer.c | 197 ++-
 6 files changed, 265 insertions(+), 243 deletions(-)

diff --git a/src/compositor-android.c b/src/compositor-android.c
index 3c0273a..bf14910 100644
--- a/src/compositor-android.c
+++ b/src/compositor-android.c
@@ -145,6 +145,8 @@ android_output_destroy(struct weston_output *base)
wl_list_remove(output-base.link);
weston_output_destroy(output-base);
 
+   gles2_renderer_output_unbind(base);
+
android_framebuffer_destroy(output-fb);
 
free(output);
@@ -319,6 +321,8 @@ android_seat_create(struct android_compositor *compositor)
 static int
 android_egl_choose_config(struct android_compositor *compositor,
  struct android_framebuffer *fb,
+ EGLDisplay egl_display,
+ EGLConfig *egl_config,
  const EGLint *attribs)
 {
EGLBoolean ret;
@@ -332,9 +336,9 @@ android_egl_choose_config(struct android_compositor 
*compositor,
 * surfaceflinger/DisplayHardware/DisplayHardware.cpp
 */
 
-   compositor-base.egl_config = NULL;
+   *egl_config = NULL;
 
-   ret = eglGetConfigs(compositor-base.egl_display, NULL, 0, count);
+   ret = eglGetConfigs(egl_display, NULL, 0, count);
if (ret == EGL_FALSE || count  1)
return -1;
 
@@ -342,27 +346,27 @@ android_egl_choose_config(struct android_compositor 
*compositor,
if (!configs)
return -1;
 
-   ret = eglChooseConfig(compositor-base.egl_display, attribs, configs,
+   ret = eglChooseConfig(egl_display, attribs, configs,
  count, matched);
if (ret == EGL_FALSE || matched  1)
goto out;
 
for (i = 0; i  matched; ++i) {
EGLint id;
-   ret = eglGetConfigAttrib(compositor-base.egl_display,
+   ret = eglGetConfigAttrib(egl_display,
 configs[i], EGL_NATIVE_VISUAL_ID,
 id);
if (ret == EGL_FALSE)
continue;
if (id  0  fb-format == id) {
-   compositor-base.egl_config = configs[i];
+   *egl_config = configs[i];
break;
}
}
 
 out:
free(configs);
-   if (!compositor-base.egl_config)
+   if (!*egl_config)
return -1;
 
return 0;
@@ -372,7 +376,8 @@ static int
 android_init_egl(struct android_compositor *compositor,
 struct android_output *output)
 {
-   EGLint eglmajor, eglminor;
+   EGLDisplay egl_display;
+   EGLConfig egl_config;
int ret;
 
static const EGLint config_attrs[] = {
@@ -385,66 +390,41 @@ android_init_egl(struct android_compositor *compositor,
EGL_NONE
};
 
-   compositor-base.egl_display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
-   if (compositor-base.egl_display == EGL_NO_DISPLAY) {
-   weston_log(Failed to create EGL display.\n);
-   print_egl_error_state();
-   return -1;
-   }
+   egl_display = gles2_renderer_init_without_config(compositor-base, 
EGL_DEFAULT_DISPLAY);
 
-   ret = eglInitialize(compositor-base.egl_display, eglmajor, eglminor);
-   if (!ret) {
-   weston_log(Failed to initialise EGL.\n);
+   if (egl_display == EGL_NO_DISPLAY) {
+   weston_log(Failed to create EGL display.\n);
print_egl_error_state();
return -1;
}
 
-   ret = android_egl_choose_config(compositor, output-fb, config_attrs);
+   ret = android_egl_choose_config(compositor, output-fb, egl_display, 
egl_config, config_attrs);
if (ret  0) {
weston_log(Failed to find an EGL config.\n);
print_egl_error_state();
return -1;
}
 
-   output-base.egl_surface =
-   eglCreateWindowSurface(compositor-base.egl_display,
-  compositor-base.egl_config,
-  output-fb-native_window,
-  NULL);
-   if (output-base.egl_surface == EGL_NO_SURFACE) {
-   weston_log(Failed to create FB EGLSurface.\n);
-

Re: [PATCH weston 6/6] Add informal notes file

2012-10-25 Thread Nick Kisialiou

Kristian,

What do you have in mind as a real documentation? Are you thinking of a
100+ pages user manual? If so, I can envision the following problems with
this route:

(1) Your developers' time is a precious resource. Someone in your team will
have to stop development work to write it.
(2) The longer the documentation, the fewer people will actually have time
to read it.
(3) Wayland protocol is still evolving, so the big documentation will
quickly become outdated.

I don't mean to tell anyone what to do and how to do it. I'm just thinking
of more useful alternatives:

Would it actually be better to host a wiki on
http://www.freedesktop.org/wiki/ and populate it with short articles like
the one posted by Pekka? When an article becomes outdated it can simply be
deleted. And as new additions are made (tablet shell, android,
multi-threading, debugging strategies etc) developers can simply add a
small article to describe the intended protocol or client usage while it is
still fresh in their memory. It seems like it will be easier on developers
and signal-to-noise ratio of such articles is much higher than lengthy user
guides.

There are of course downsides to the wiki: information may be spread
around. But then again, it is easier to assemble a full user guide out
of these articles than it is to write it all from scratch.

Nick




On Thu, Oct 25, 2012 at 12:02 PM, Kristian Høgsberg hoegsb...@gmail.comwrote:

 On Wed, Oct 24, 2012 at 09:43:10AM +0300, Pekka Paalanen wrote:
  By request on the wayland-devel mailing list, we could start collecting
  useful writings here.
 
  However, this is not meant to be a substitute to proper documentation,
  though I understand it may very well become one. Better than nothing, I
  guess, and hopefully helps in writing real documentation.

 I suppose we can do this, but it becomes hard to manage pretty fast.
 Ideally we'd work this into the documentation instead.  Over time a
 lot of small snippets like this becomes hard to search or make sense of.

 This and the previous 5 patches committed.

 Kristian

  Feel free to add stuff.
 
  Signed-off-by: Pekka Paalanen ppaala...@gmail.com
  ---
   notes.txt |   77
 +
   1 files changed, 77 insertions(+), 0 deletions(-)
   create mode 100644 notes.txt
 
  diff --git a/notes.txt b/notes.txt
  new file mode 100644
  index 000..e49052b
  --- /dev/null
  +++ b/notes.txt
  @@ -0,0 +1,77 @@
  +This file is a collection of informal notes, with references to where
  +they were originally written. Each note should have a source and date
  +mentioned. Let's keep these in date order, newest first.
  +
  +
  +
  +---
  +2012-10-23; Pekka Paalanen ppaala...@gmail.com
  +
 http://lists.freedesktop.org/archives/wayland-devel/2012-October/005969.html
  +
  +For anyone wanting to port or write their own window manager to Wayland:
  +
  +Most likely you have a desktop window manager. A quick way to get
  +started, is to fork Weston's desktop-shell plugin and start hacking it.
  +Qt could be another good choice, but I am not familiar with it.
  +
  +You also need to understand some concepts. I'm repeating things I wrote
  +to the wayland-devel list earlier, a little rephrased.
  +
  +We need to distinguish three different things here (towards Wayland
  +clients):
  +
  +- compositors (servers)
  + All Wayland compositors are indistinguishable by definition,
  + since they are Wayland compositors. They only differ in the
  + global interfaces they advertise, and for general purpose
  + compositors, we should aim to support the same minimum set of
  + globals everywhere. For instance, all desktop compositors
  + should implement wl_shell. In X, this component corresponds to
  + the X server with a built-in compositing manager.
  +
  +- shells
  + This is a new concept compared to an X stack. A shell defines
  + how a user and applications interact. The most familiar is a
  + desktop (environment). If KDE, Gnome, and XFCE are desktop
  + environments, they all fall under the *same* shell: the desktop
  + shell. You can have applications in windows, several visible at
  + the same time, you have keyboards and mice, etc.
  +
  + An example of something that is not a desktop shell
  + could be a TV user interface. TV is profoundly different:
  + usually no mouse, no keyboard, but you have a remote control
  + with some buttons. Freely floating windows probably do not make
  + sense. You may have picture-in-picture, but usually not several
  + applications showing at once. Most importantly, trying to run
  + desktop applications here does not work due to the
  + incompatible application and user interface paradigms.
  +
  + On protocol level, a shell is the public shell interface(s),
  + currently for desktop it is the wl_shell.
  +

[PATCH] dnd: Use %zd in the format string for size_t types

2012-10-25 Thread Damien Lespiau

From: Damien Lespiau damien.lesp...@intel.com

len i size_t, so is the result of the sizeof operator.
---
 clients/dnd.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/clients/dnd.c b/clients/dnd.c
index 4c070ff..bbfde09 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -517,7 +517,7 @@ dnd_receive_func(void *data, size_t len, int32_t x, int32_t 
y, void *user_data)
if (len == 0) {
return;
} else if (len != sizeof *message) {
-   fprintf(stderr, odd message length %ld, expected %ld\n,
+   fprintf(stderr, odd message length %zd, expected %zd\n,
len, sizeof *message);
return;
}
-- 
1.7.7.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

GTK+ master hasn't been updated for xkbcommon-0.2.0

2012-10-25 Thread darxus

bluetech opened a bug with an attached patch:
https://bugzilla.gnome.org/show_bug.cgi?id=686904

-- 
The most elementary and valuable statement in science, the beginning
of wisdom is: 'I do not know'. - Data, ST:TNG 2x2 Where Silence Has Lease
http://www.ChaosReigns.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Software rendering with Mesa and Wayland 1.0

2012-10-25 Thread nerdopolis

On Thursday, October 25, 2012 08:27:15 AM nerdopolis wrote:

Hi.

I am trying to get the fallback software rendering working for Weston

It seems now I am getting this output when I export, EGL_LOG_LEVEL=debug

libEGL debug: Native platform type: wayland (autodetected)
libEGL debug: EGL search path is /opt/lib/i386-linux-gnu/egl
libEGL debug: added /opt/lib/i386-linux-gnu/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: added egl_glx to module array
libEGL debug: dlopen(/opt/lib/i386-linux-gnu/egl/egl_gallium.so)
libEGL info: use wayland for display 0x9b084f8
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in 
eglInitialize(failed to initialize screen)

libEGL info: use wayland for display 0x9b084f8
libEGL info: use software fallback
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in 
eglInitialize(failed to initialize screen)

libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize

failed to initialize display
failed to create display: No such file or directory



I used to use an older commit, in order to get qtbase to build, as it used to 
fail with the the opengles 2 test failed' or something of that nature, so I 
tried to use that older commit, and attempt to separate and apply the 3 Wayland 
1.0 patches against it. The patches applied, mesa built, however I got the same 
EGL errors as above. 

Now if I can also recall, by using master, I don't think qtbase was failing 
with opengles 2 test failed anymore.

I think that something about the new Wayland patches in Mesa are preventing it 
from allowing software fallback with weston.

Thanks.


More information for debugging :
This is the gdb output of simple-egl http://hastebin.com/xusawaxoxu.md with a 
break at wayland_shm_display_init_screen
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Newest weston does not compile gears demo

[PATCH] server: fix new id printing in closure debug on x86

Software rendering with Mesa and Wayland 1.0

[PATCH] Use a library symbol version map

Re: Software rendering with Mesa and Wayland 1.0

Re: [PATCH] Use a library symbol version map

Re: [PATCH weston 6/6] Add informal notes file

[PATCH v2] gles2-renderer: Provide an API for backends to use.

Re: [PATCH weston 6/6] Add informal notes file

[PATCH] dnd: Use %zd in the format string for size_t types

GTK+ master hasn't been updated for xkbcommon-0.2.0

Re: Software rendering with Mesa and Wayland 1.0

12 matches

Site Navigation

Mail list logo

Footer information