Re: [PATCH wayland 1/2] Change WL_ZOMBIE_OBJECT from 0x2 to an actual pointer
On Wed, 5 Jun 2013 16:39:50 -0500
Jason Ekstrand ja...@jlekstrand.net wrote:
In order to use the second-lowest bit of each pointer in wl_map for the
WL_MAP_ENTRY_LEGACY flag, every pointer has to be a multiple of 4. This
was a good assumption, except with WL_ZOMBIE_OBJECT. This commit creates
an actual static variable to which WL_ZOMBIE_OBJECT now points. Since
things are only every compared to WL_ZOMBIE_OBJECT with == or !=, the
only thing that matters is that it is unique.
Signed-off-by: Jason Ekstrand ja...@jlekstrand.net
---
src/wayland-private.h | 5 +++--
src/wayland-util.c| 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/wayland-private.h b/src/wayland-private.h
index a648538..6f7a347 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -34,13 +34,14 @@
const __typeof__( ((type *)0)-member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type,member) );})
-#define WL_ZOMBIE_OBJECT ((void *) 2)
-
#define WL_MAP_SERVER_SIDE 0
#define WL_MAP_CLIENT_SIDE 1
#define WL_SERVER_ID_START 0xff00
#define WL_CLOSURE_MAX_ARGS 20
+extern struct wl_object global_zombie_object;
+#define WL_ZOMBIE_OBJECT ((void*)global_zombie_object)
+
/* Flags for wl_map_insert_new and wl_map_insert_at. Flags can be queried
with
* wl_map_lookup_flags. The current implementation has room for 1 bit worth
of
* flags. If more flags are ever added, the implementation of wl_map will
have
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 162b352..7a0b268 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -29,6 +29,8 @@
#include wayland-util.h
#include wayland-private.h
+struct wl_object global_zombie_object;
+
WL_EXPORT void
wl_list_init(struct wl_list *list)
{
So, global_zombie_object gets compiled into wayland-util.o, which makes
it private/hidden in both libwayland-server.so and
libwayland-client.so. Is there any danger of these getting mixed up,
when a program links to both?
The identity of the zombie depends on which library's util functions
actually get called, right? Looking at wayland-util.h, there are no
public entry points that would both be shared and access a wl_map. Only
functions unique to either libwayland-server or libwayland-client will
access a wl_map, so I assume they would be linked to the wayland-util.o
symbols in that specific library. Default visibility = hidden should
guarantee that.
Am I right that there is no danger here?
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/2] terminal: Handle dual-width fonts
In CJK locale, there are some dual-width fonts. When start weston terminal in CJK locale, the glyph will occupy many empty space. I changed to use the average ASCII glyph width instead of the maximum glyph width, like vte project. Peng Wu (2): As some CJK fonts are dual-width, use the average width of ASCII glyphs instead of the max_x_advance of the font, just like the vte project. Some CJK glyphs are wide, which occupy two columns. If the glyph is wide, then use two columns instead of one. clients/Makefile.am | 2 +- clients/terminal.c | 69 ++--- 2 files changed, 56 insertions(+), 15 deletions(-) -- 1.8.1.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] As some CJK fonts are dual-width, use the average width of ASCII glyphs instead of the max_x_advance of the font, just like the vte project.
---
clients/terminal.c | 55 --
1 file changed, 41 insertions(+), 14 deletions(-)
diff --git a/clients/terminal.c b/clients/terminal.c
index 2985726..0d4f726 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -54,6 +54,16 @@ terminal_destroy(struct terminal *terminal);
static int
terminal_run(struct terminal *terminal, const char *path);
+#define TERMINAL_DRAW_SINGLE_WIDE_CHARACTERS\
+ !\#$%'()*+,-./ \
+0123456789\
+:;=?@ \
+ABCDEFGHIJKLMNOPQRSTUVWXYZ\
+[\\]^_` \
+abcdefghijklmnopqrstuvwxyz\
+{|}~ \
+
+
#define MOD_SHIFT 0x01
#define MOD_ALT0x02
#define MOD_CTRL 0x04
@@ -407,6 +417,7 @@ struct terminal {
struct color_scheme *color_scheme;
struct terminal_color color_table[256];
cairo_font_extents_t extents;
+ double average_width;
cairo_scaled_font_t *font_normal, *font_bold;
uint32_t hide_cursor_serial;
@@ -760,12 +771,12 @@ resize_handler(struct widget *widget,
int32_t columns, rows, m;
m = 2 * terminal-margin;
- columns = (width - m) / (int32_t) terminal-extents.max_x_advance;
+ columns = (width - m) / (int32_t) terminal-average_width;
rows = (height - m) / (int32_t) terminal-extents.height;
if (!window_is_fullscreen(terminal-window)
!window_is_maximized(terminal-window)) {
- width = columns * terminal-extents.max_x_advance + m;
+ width = columns * terminal-average_width + m;
height = rows * terminal-extents.height + m;
widget_set_size(terminal-widget, width, height);
}
@@ -783,7 +794,7 @@ terminal_resize(struct terminal *terminal, int columns, int
rows)
return;
m = 2 * terminal-margin;
- width = columns * terminal-extents.max_x_advance + m;
+ width = columns * terminal-average_width + m;
height = rows * terminal-extents.height + m;
frame_set_child_size(terminal-widget, width, height);
@@ -930,6 +941,7 @@ redraw_handler(struct widget *widget, void *data)
double d;
struct glyph_run run;
cairo_font_extents_t extents;
+ double average_width;
surface = window_get_surface(terminal-window);
widget_get_allocation(terminal-widget, allocation);
@@ -946,7 +958,8 @@ redraw_handler(struct widget *widget, void *data)
cairo_set_scaled_font(cr, terminal-font_normal);
extents = terminal-extents;
- side_margin = (allocation.width - terminal-width *
extents.max_x_advance) / 2;
+ average_width = terminal-average_width;
+ side_margin = (allocation.width - terminal-width * average_width) / 2;
top_margin = (allocation.height - terminal-height * extents.height) /
2;
cairo_set_line_width(cr, 1.0);
@@ -962,11 +975,11 @@ redraw_handler(struct widget *widget, void *data)
continue;
terminal_set_color(terminal, cr, attr.attr.bg);
- cairo_move_to(cr, col * extents.max_x_advance,
+ cairo_move_to(cr, col * average_width,
row * extents.height);
- cairo_rel_line_to(cr, extents.max_x_advance, 0);
+ cairo_rel_line_to(cr, average_width, 0);
cairo_rel_line_to(cr, 0, extents.height);
- cairo_rel_line_to(cr, -extents.max_x_advance, 0);
+ cairo_rel_line_to(cr, -average_width, 0);
cairo_close_path(cr);
cairo_fill(cr);
}
@@ -984,12 +997,12 @@ redraw_handler(struct widget *widget, void *data)
glyph_run_flush(run, attr);
- text_x = col * extents.max_x_advance;
+ text_x = col * average_width;
text_y = extents.ascent + row * extents.height;
if (attr.attr.a ATTRMASK_UNDERLINE) {
terminal_set_color(terminal, cr, attr.attr.fg);
cairo_move_to(cr, text_x, (double)text_y + 1.5);
- cairo_line_to(cr, text_x +
extents.max_x_advance, (double) text_y + 1.5);
+ cairo_line_to(cr, text_x + average_width,
(double) text_y + 1.5);
cairo_stroke(cr);
}
@@ -1005,11 +1018,11 @@ redraw_handler(struct widget *widget, void *data)
d = 0.5;
cairo_set_line_width(cr, 1);
- cairo_move_to(cr, terminal-column * extents.max_x_advance + d,
+ cairo_move_to(cr,
[PATCH 2/2] Some CJK glyphs are wide, which occupy two columns. If the glyph is wide, then use two columns instead of one.
---
clients/Makefile.am | 2 +-
clients/terminal.c | 18 --
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/clients/Makefile.am b/clients/Makefile.am
index cad0d40..d37d66a 100644
--- a/clients/Makefile.am
+++ b/clients/Makefile.am
@@ -104,7 +104,7 @@ weston_screenshooter_SOURCES = \
weston_screenshooter_LDADD = libtoytoolkit.la
weston_terminal_SOURCES = terminal.c
-weston_terminal_LDADD = libtoytoolkit.la -lutil
+weston_terminal_LDADD = libtoytoolkit.la -lutil $(PANGO_LIBS)
image_SOURCES = image.c
image_LDADD = libtoytoolkit.la
diff --git a/clients/terminal.c b/clients/terminal.c
index 0d4f726..4495530 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -33,6 +33,7 @@
#include ctype.h
#include cairo.h
#include sys/epoll.h
+#include glib.h
#include wayland-client.h
@@ -942,6 +943,9 @@ redraw_handler(struct widget *widget, void *data)
struct glyph_run run;
cairo_font_extents_t extents;
double average_width;
+ gunichar unichar;
+ gboolean iswide;
+ int extracol;
surface = window_get_surface(terminal-window);
widget_get_allocation(terminal-widget, allocation);
@@ -991,22 +995,32 @@ redraw_handler(struct widget *widget, void *data)
glyph_run_init(run, terminal, cr);
for (row = 0; row terminal-height; row++) {
p_row = terminal_get_row(terminal, row);
+ extracol = 0;
for (col = 0; col terminal-width; col++) {
/* get the attributes for this character cell */
terminal_decode_attr(terminal, row, col, attr);
glyph_run_flush(run, attr);
- text_x = col * average_width;
+ /* check dual width unicode character */
+ unichar = g_utf8_get_char((const char*)
p_row[col].byte);
+ iswide = g_unichar_iswide(unichar);
+
+ text_x = (col + extracol) * average_width;
text_y = extents.ascent + row * extents.height;
if (attr.attr.a ATTRMASK_UNDERLINE) {
terminal_set_color(terminal, cr, attr.attr.fg);
cairo_move_to(cr, text_x, (double)text_y + 1.5);
- cairo_line_to(cr, text_x + average_width,
(double) text_y + 1.5);
+ if (iswide)
+ cairo_line_to(cr, text_x +
average_width * 2, (double) text_y + 1.5);
+ else
+ cairo_line_to(cr, text_x +
average_width, (double) text_y + 1.5);
cairo_stroke(cr);
}
glyph_run_add(run, text_x, text_y, p_row[col]);
+ if (iswide)
+ extracol++;
}
}
--
1.8.1.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 1/2] Change WL_ZOMBIE_OBJECT from 0x2 to an actual pointer
On Jun 6, 2013 1:37 AM, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 5 Jun 2013 16:39:50 -0500
Jason Ekstrand ja...@jlekstrand.net wrote:
In order to use the second-lowest bit of each pointer in wl_map for the
WL_MAP_ENTRY_LEGACY flag, every pointer has to be a multiple of 4. This
was a good assumption, except with WL_ZOMBIE_OBJECT. This commit
creates
an actual static variable to which WL_ZOMBIE_OBJECT now points. Since
things are only every compared to WL_ZOMBIE_OBJECT with == or !=,
the
only thing that matters is that it is unique.
Signed-off-by: Jason Ekstrand ja...@jlekstrand.net
---
src/wayland-private.h | 5 +++--
src/wayland-util.c| 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/wayland-private.h b/src/wayland-private.h
index a648538..6f7a347 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -34,13 +34,14 @@
const __typeof__( ((type *)0)-member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type,member) );})
-#define WL_ZOMBIE_OBJECT ((void *) 2)
-
#define WL_MAP_SERVER_SIDE 0
#define WL_MAP_CLIENT_SIDE 1
#define WL_SERVER_ID_START 0xff00
#define WL_CLOSURE_MAX_ARGS 20
+extern struct wl_object global_zombie_object;
+#define WL_ZOMBIE_OBJECT ((void*)global_zombie_object)
+
/* Flags for wl_map_insert_new and wl_map_insert_at. Flags can be
queried with
* wl_map_lookup_flags. The current implementation has room for 1 bit
worth of
* flags. If more flags are ever added, the implementation of wl_map
will have
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 162b352..7a0b268 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -29,6 +29,8 @@
#include wayland-util.h
#include wayland-private.h
+struct wl_object global_zombie_object;
+
WL_EXPORT void
wl_list_init(struct wl_list *list)
{
So, global_zombie_object gets compiled into wayland-util.o, which makes
it private/hidden in both libwayland-server.so and
libwayland-client.so. Is there any danger of these getting mixed up,
when a program links to both?
The identity of the zombie depends on which library's util functions
actually get called, right? Looking at wayland-util.h, there are no
public entry points that would both be shared and access a wl_map. Only
functions unique to either libwayland-server or libwayland-client will
access a wl_map, so I assume they would be linked to the wayland-util.o
symbols in that specific library. Default visibility = hidden should
guarantee that.
Am I right that there is no danger here?
Even better, server side should never use zombie objects at all. However,
it is used in connection.c, so I had to put it in wayland-util. This is
one of those places where the shared code between client and server isn't
quite as generic/universal as one would like.
Thanks for reviewing,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] text: Fix misleading error message
Ping?
On 05/10/2013 05:50 PM, Eduardo Lima (Etrunko) wrote:
From: Eduardo Lima (Etrunko) eduardo.l...@linux.intel.com
This should be input_method and not desktop_shell
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
---
src/text-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/text-backend.c b/src/text-backend.c
index 92efd9f..d7ce31c 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -762,7 +762,7 @@ bind_input_method(struct wl_client *client,
if (text_backend-input_method.client != client) {
wl_resource_post_error(resource,
WL_DISPLAY_ERROR_INVALID_OBJECT,
-permission to bind desktop_shell
denied);
+permission to bind input_method
denied);
wl_resource_destroy(resource);
return;
}
--
Eduardo de Barros Lima (Etrunko)
Software Engineer, Open Source Technology Center
Intel Corporation
São Paulo, Brazil
eduardo.l...@linux.intel.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Problem compiling Qt5 on Wayland
Hi, I'm trying to deploy this solution : http://wayland.freedesktop.org/qt5.html But when I try to run qmake in order to compile QtWayland I got the following error : Project ERROR: QtWayland requires Wayland 1.0.3 or higher I built wayland and weston using the latest version so it should be ok... I tried to look on the Internet to find a solution but I didn't find one. Does anyone know how to resolve this, because I don't undestand how and where is qmake verifying the version of wayland ? Thanks in advance, Aurelien ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Problem compiling Qt5 on Wayland
You're probably missing the environment variables to point it to the version of wayland you built, which are at the top of http://wayland.freedesktop.org/building.html under Setting up the environment. On 06/06, Aurélien Roy wrote: Hi, I'm trying to deploy this solution : [1]http://wayland.freedesktop.org/qt5.html But when I try to run qmake in order to compile QtWayland I got the following error : Project ERROR: QtWayland requires Wayland 1.0.3 or higher I built wayland and weston using the latest version so it should be ok... I tried to look on the Internet to find a solution but I didn't find one. Does anyone know how to resolve this, because I don't undestand how and where is qmake verifying the version of wayland ? Thanks in advance, Aurelien References Visible links 1. http://wayland.freedesktop.org/qt5.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- ...Man had always assumed that he was more intelligent than dolphins because he had achieved so much - the wheel, New York, wars and so on - whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man - for precisely the same reasons. - the Hitchhiker's Guide To The Galaxy http://www.ChaosReigns.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Tue, May 28, 2013 at 1:10 PM, Rafael Antognolli antogno...@gmail.com wrote: On Thu, May 16, 2013 at 2:12 PM, Bill Spitzak spit...@gmail.com wrote: Pekka Paalanen wrote: For example the floating shared toolbox with 2 main windows. It should only disappear when *both* main windows are minimized. You very conventiently removed my next sentence, where I already took this into account. - pq Sorry, obviously I did not read very carefully: Actually, if you think about a multi-window application, minimize needs to work the same way, so that application can hide all relevant windows (but maybe not *all* windows). I think also it is important to note that the compositor cannot even hide the window the minimize is for. This is because that hide should be in sync with the hiding of other windows, so the client should do all of them. OK, so since what Khristian proposed was this: https://github.com/antognolli/wayland/commit/a94eb97fdf49c6e06b0b4e94f4b8c840602442db Can I start from it? It seems to me that it allows to cover the most important part mentioned here, which is the fact that weston will only send the minimize events and clients should have control over this. Looks fine, putting some code behind all this talk would be very welcome. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] compositor-drm: Cache the DPMS property on drm_output
On Wed, Jun 05, 2013 at 12:03:37AM -0400, Kristian Høgsberg wrote:
On Tue, Jun 04, 2013 at 04:24:04PM +0300, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
This avoids one drmModeGetConnector() call every time the DPMS mode is
set. That call can take hundreds of milliseconds due to DDC.
This looks good. As I replied to David, I think this is a net
improvement, I don't see that it regresses our current vt switching
handling. I've committed this and 2/2, but if there's something I'm
missing, let's do a follow up patch.
Just as an aside, if you hand-roll GetConnector you could grab the
kernel's latest output state and mode list without forcing a slow detect
cycle by setting output-num_modes == 0. The kernel uses that to only do
the detect stuff once instead for both ioctl calls ...
-Daniel
Kristian
---
src/compositor-drm.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 4222e57..27d4d02 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -145,6 +145,7 @@ struct drm_output {
uint32_t connector_id;
drmModeCrtcPtr original_crtc;
struct drm_edid edid;
+ drmModePropertyPtr dpms_prop;
int vblank_pending;
int page_flip_pending;
@@ -1054,6 +1055,8 @@ drm_output_destroy(struct weston_output *output_base)
if (output-backlight)
backlight_destroy(output-backlight);
+ drmModeFreeProperty(output-dpms_prop);
+
/* Turn off hardware cursor */
drmModeSetCursor(c-drm.fd, output-crtc_id, 0, 0, 0);
@@ -1365,23 +1368,12 @@ drm_set_dpms(struct weston_output *output_base,
enum dpms_enum level)
struct drm_output *output = (struct drm_output *) output_base;
struct weston_compositor *ec = output_base-compositor;
struct drm_compositor *c = (struct drm_compositor *) ec;
- drmModeConnectorPtr connector;
- drmModePropertyPtr prop;
- connector = drmModeGetConnector(c-drm.fd, output-connector_id);
- if (!connector)
+ if (!output-dpms_prop)
return;
- prop = drm_get_prop(c-drm.fd, connector, DPMS);
- if (!prop) {
- drmModeFreeConnector(connector);
- return;
- }
-
- drmModeConnectorSetProperty(c-drm.fd, connector-connector_id,
- prop-prop_id, level);
- drmModeFreeProperty(prop);
- drmModeFreeConnector(connector);
+ drmModeConnectorSetProperty(c-drm.fd, output-connector_id,
+ output-dpms_prop-prop_id, level);
}
static const char *connector_type_names[] = {
@@ -1813,6 +1805,7 @@ create_output_for_connector(struct drm_compositor *ec,
ec-connector_allocator |= (1 output-connector_id);
output-original_crtc = drmModeGetCrtc(ec-drm.fd, output-crtc_id);
+ output-dpms_prop = drm_get_prop(ec-drm.fd, connector, DPMS);
/* Get the current mode on the crtc that's currently driving
* this connector. */
--
1.7.9.5
___
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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.
v4:
Incorporated krh and anderco's comments. Now adding newly allocated
buffer's dimensions to texture_damage
v3:
* Removed unnecessary parentheses
* Added check for switching from EGL image to SHM buffer
* Moved shader assignment out of IF condition
v2:
Fixed the wrong comparison
v1:
Depending on specific DRI driver implementation, glTexImage2D() with data
set to NULL may or may not re-allocate the texture buffer each time it is
called. Unintended consequences happen if later glTexSubImage2D() is called
to only update a sub-region of the texture buffer.
I've explored moving glTexImage2D() from gl_renderer_attach() and simply
mark the texture dirty, but the current implemention seems cleaner because
I won't have to worry about calling ensure_textures() and re-assigning
gs-shader unnecessarily.
---
src/gl-renderer.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index d783a0b..63c9c32 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1204,15 +1204,30 @@ gl_renderer_attach(struct weston_surface *es, struct
wl_buffer *buffer)
}
if (wl_buffer_is_shm(buffer)) {
- gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
- gs-height = wl_shm_buffer_get_height(buffer);
- gs-target = GL_TEXTURE_2D;
+ /* Only allocate a texture if it doesn't match existing one.
+* If gs-num_images is not 0, then a switch from DRM allocated
+* buffer to a SHM buffer is happening, and we need to allocate
+* a new texture buffer.
+*/
+ if (wl_shm_buffer_get_stride(buffer) / 4 != gs-pitch ||
+ wl_shm_buffer_get_height(buffer) != gs-height ||
+ gs-num_images 0) {
+ gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
+ gs-height = wl_shm_buffer_get_height(buffer);
+ gs-target = GL_TEXTURE_2D;
+
+ ensure_textures(gs, 1);
+ glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
+ glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
+gs-pitch, buffer-height, 0,
+GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
+ pixman_region32_union_rect(gs-texture_damage,
+ gs-texture_damage,
+ 0, 0,
+ gs-pitch / es-buffer_scale,
+ gs-height /
es-buffer_scale);
+ }
- ensure_textures(gs, 1);
- glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
- glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
-gs-pitch, buffer-height, 0,
-GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
gs-shader = gr-texture_shader_rgbx;
else
--
1.7.7.6
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] gl-renderer: Always release previous EGL images on attach
On Wed, 5 Jun 2013 12:21:05 +0300
Ander Conselvan de Oliveira conselv...@gmail.com wrote:
From: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
When attaching a new buffer, the EGL images created for the previous
one would be released if this new buffer was an EGL or NULL buffer,
but not if is was an SHM buffer. This wouldn't cause the resources to
be leaked becaused they are free()'d when the surface is destroyed,
but they would linger around for longer than necessary.
Note that this change the behaviour when attaching an unknow buffer
type. Before the EGL images would still be around, but now that would
cause them to be destroyed.
---
src/gl-renderer.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index d783a0b..13c0fa9 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1192,12 +1192,13 @@ gl_renderer_attach(struct weston_surface *es,
struct wl_buffer *buffer)
weston_buffer_reference(gs-buffer_ref, buffer);
+ for (i = 0; i gs-num_images; i++) {
+ gr-destroy_image(gr-egl_display, gs-images[i]);
+ gs-images[i] = NULL;
+ }
+ gs-num_images = 0;
+
I just got around to looking at this, now I wonder if I need to modify
my patch or you need to modify this one. :)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.
On Wed, Jun 05, 2013 at 11:47:40AM +0300, Ander Conselvan de Oliveira wrote:
On 06/04/2013 08:06 AM, Kristian Høgsberg wrote:
On Tue, May 28, 2013 at 05:28:49PM -0700, Sinclair Yeh wrote:
v3:
* Removed unnecessary parentheses
* Added check for switching from EGL image to SHM buffer
* Moved shader assignment out of IF condition
v2:
Fixed the wrong comparison
v1:
Depending on specific DRI driver implementation, glTexImage2D() with data
set to NULL may or may not re-allocate the texture buffer each time it is
called. Unintended consequences happen if later glTexSubImage2D() is called
to only update a sub-region of the texture buffer.
I've explored moving glTexImage2D() from gl_renderer_attach() and simply
mark the texture dirty, but the current implemention seems cleaner because
I won't have to worry about calling ensure_textures() and re-assigning
gs-shader unnecessarily.
---
src/gl-renderer.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index be74eba..aa8f581 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -68,6 +68,7 @@ struct gl_surface_state {
struct weston_buffer_reference buffer_ref;
int pitch; /* in pixels */
+ int height;
};
struct gl_renderer {
@@ -1213,18 +1214,31 @@ gl_renderer_attach(struct weston_surface *es,
struct wl_buffer *buffer)
}
if (wl_buffer_is_shm(buffer)) {
- gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
- gs-target = GL_TEXTURE_2D;
+ /* Only allocate a texture if it doesn't match existing one.
+* If gs-num_images is not 0, then a switch from DRM allocated
+* buffer to a SHM buffer is happening, and we need to allocate
+* a new texture buffer.
+*/
+ if (wl_shm_buffer_get_stride(buffer) / 4 != gs-pitch ||
+ buffer-height != gs-height ||
+ gs-num_images 0) {
+ gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
+ gs-height = buffer-height;
+ gs-target = GL_TEXTURE_2D;
+
+ ensure_textures(gs, 1);
+ glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
+ glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
+gs-pitch, buffer-height, 0,
+GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
Looking better now, but we still need to make sure we do a full upload
before we repaint. If a client is clever about it's resizing and only
posts a partial damage request after attaching the new buffer, we end
up reallocating the texture storage but not uploading the full
contents.
However, weird behavior #1: This shouldn't happen with any of the
clients I have (they all post full damage on resize), yet, I still see
flicker when resizing.
Weird behavior #2: The fix should be something like this:
+pixman_region32_union_rect(gs-texture_damage,
+ gs-texture_damage,
+ 0, 0,
+ es-geometry.width,
+ es-geometry.height);
after the glTexImage2D call, to make sure we upload all of the
texture. Instead of always uploading the contents (which would upload
twice: immediately and then when we flush damage), we add the new
surface rectangle to texture_damage. However, when I add that, the
window contents just sometimes completely disappears...
That happens when reducing the size. The new buffer dimensions are
not propagated to the surface until the call to surface-configure()
that comes after the attach call. In that case, you add a rectangle
to texture_damage that is bigger than the texture itself. When
Weston tries to upload this rectangle with glTexSubImage2D(), the
check for the rectangle being inside of the texture fails and
nothing is uploaded.
I guess it would make sense to just make texture damage equal to the
size of the texture. But there's a problem that texture_damage is in
surface coordinates, so we either convert the buffer dimensions to
that at this point, or change it to be in actual buffer coordinates.
Cheers,
Ander
Yup, you're right, thanks for looking into this. Sinclair updated the
patch to add the texture damage from the buffer size, by dividing down
by the surface scale. I think it might make more sense just keeping
the texture_damage region in buffer coordinates, but for now, it's all
working here.
This is what's holding up the patch - I don't have a lot of time to
look into it right now, but it is something I want to get in this week
so any help is apprecaited.
Kristian
+ }
- ensure_textures(gs, 1);
- glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
-
Re: [PATCH] gl-renderer: Always release previous EGL images on attach
On Wed, Jun 05, 2013 at 12:21:05PM +0300, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
When attaching a new buffer, the EGL images created for the previous one
would be released if this new buffer was an EGL or NULL buffer, but not
if is was an SHM buffer. This wouldn't cause the resources to be leaked
becaused they are free()'d when the surface is destroyed, but they
would linger around for longer than necessary.
Note that this change the behaviour when attaching an unknow buffer
type. Before the EGL images would still be around, but now that would
cause them to be destroyed.
---
src/gl-renderer.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index d783a0b..13c0fa9 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1192,12 +1192,13 @@ gl_renderer_attach(struct weston_surface *es, struct
wl_buffer *buffer)
weston_buffer_reference(gs-buffer_ref, buffer);
+ for (i = 0; i gs-num_images; i++) {
+ gr-destroy_image(gr-egl_display, gs-images[i]);
+ gs-images[i] = NULL;
+ }
+ gs-num_images = 0;
+
We look at gs-num_images below in the shm case to determine if the
previous buffer was a drm buffer. Freeing the buffers here means that
num_images is always NULL and that we fail to damage the entire
texture.
Kristian
if (!buffer) {
- for (i = 0; i gs-num_images; i++) {
- gr-destroy_image(gr-egl_display, gs-images[i]);
- gs-images[i] = NULL;
- }
- gs-num_images = 0;
glDeleteTextures(gs-num_textures, gs-textures);
gs-num_textures = 0;
return;
@@ -1219,9 +1220,6 @@ gl_renderer_attach(struct weston_surface *es, struct
wl_buffer *buffer)
gs-shader = gr-texture_shader_rgba;
} else if (gr-query_buffer(gr-egl_display, buffer,
EGL_TEXTURE_FORMAT, format)) {
- for (i = 0; i gs-num_images; i++)
- gr-destroy_image(gr-egl_display, gs-images[i]);
- gs-num_images = 0;
gs-target = GL_TEXTURE_2D;
switch (format) {
case EGL_TEXTURE_RGB:
--
1.7.9.5
___
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] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.
On Thu, Jun 06, 2013 at 04:41:30PM -0700, Sinclair Yeh wrote:
v4:
Incorporated krh and anderco's comments. Now adding newly allocated
buffer's dimensions to texture_damage
v3:
* Removed unnecessary parentheses
* Added check for switching from EGL image to SHM buffer
* Moved shader assignment out of IF condition
v2:
Fixed the wrong comparison
v1:
Depending on specific DRI driver implementation, glTexImage2D() with data
set to NULL may or may not re-allocate the texture buffer each time it is
called. Unintended consequences happen if later glTexSubImage2D() is called
to only update a sub-region of the texture buffer.
I've explored moving glTexImage2D() from gl_renderer_attach() and simply
mark the texture dirty, but the current implemention seems cleaner because
I won't have to worry about calling ensure_textures() and re-assigning
gs-shader unnecessarily.
Thanks, I think we got it now. The #1 issue I saw is still there, but
I've realized I only see it with gnome-terminal. I think it's an
issue in how it resizes and restricts its size to a integer number of
character cells - either way, I don't see it with other gtk+ apps or
the weston sample apps. Thanks for keeping this going - patch
committed and pushed.
Kristian
---
src/gl-renderer.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index d783a0b..63c9c32 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1204,15 +1204,30 @@ gl_renderer_attach(struct weston_surface *es, struct
wl_buffer *buffer)
}
if (wl_buffer_is_shm(buffer)) {
- gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
- gs-height = wl_shm_buffer_get_height(buffer);
- gs-target = GL_TEXTURE_2D;
+ /* Only allocate a texture if it doesn't match existing one.
+ * If gs-num_images is not 0, then a switch from DRM allocated
+ * buffer to a SHM buffer is happening, and we need to allocate
+ * a new texture buffer.
+ */
+ if (wl_shm_buffer_get_stride(buffer) / 4 != gs-pitch ||
+ wl_shm_buffer_get_height(buffer) != gs-height ||
+ gs-num_images 0) {
+ gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
+ gs-height = wl_shm_buffer_get_height(buffer);
+ gs-target = GL_TEXTURE_2D;
+
+ ensure_textures(gs, 1);
+ glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
+ glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
+ gs-pitch, buffer-height, 0,
+ GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
+ pixman_region32_union_rect(gs-texture_damage,
+gs-texture_damage,
+0, 0,
+gs-pitch / es-buffer_scale,
+gs-height /
es-buffer_scale);
+ }
- ensure_textures(gs, 1);
- glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
- glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
- gs-pitch, buffer-height, 0,
- GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
gs-shader = gr-texture_shader_rgbx;
else
--
1.7.7.6
___
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: [RFC weston] Change weston_surface.resource to a wl_resource pointer.
On Thu, Jun 06, 2013 at 10:34:41PM -0500, Jason Ekstrand wrote: This is the first in what will be a series of weston patches to convert instances of wl_resource to pointers so we can make wl_resource opaque. This patch handles weston_surface and should be the most invasive of the entire series. I am sending this one out ahead of the rest for review. Specifically, my machine is not set up to build XWayland so I have no ability to test it fully. Could someone please test with XWayland and let me know if this causes problems? Because a surface may be created from XWayland, the resource may not always exist. Therefore, a destroy signal was added to weston_surface and everything used to listen to surface-resource.destroy_signal now listens to surface-destroy_signal. Very nice, I like how the weston_surface-resource pointer now becomes an indicator of whether or not there's a protocol object for the surface, and life-cycle management for non-protocol surface is clearer. I think we should introduce ref-counts for weston_surface at this point. The idea is that the wl_resource (if it exists) has a ref-count to weston_surface. For most protocol surfaces, that's the only ref-count there'll be and the resource destructor unrefs the weston_surface, which then triggers the destroy as it does now. But I want to be able to add a resource destroy listener, that takes a ref on the weston_surface and this delays destruction. The surface goes away as a protocol object (and from the clients point of view) but we can still run a destroy animation, which then drops the last ref when it's done. I compiled and tested it and the xwayland part works fine, but I had to add wl_resource_get_id() (which I committed and pushed) and I fixed these compile errors: diff --git a/src/tablet-shell.c b/src/tablet-shell.c index d42ff16..3ef756c 100644 --- a/src/tablet-shell.c +++ b/src/tablet-shell.c @@ -186,7 +186,7 @@ tablet_shell_set_lockscreen(struct wl_client *client, shell-lockscreen_surface = es; shell-lockscreen_surface-configure = tablet_shell_surface_configure; shell-lockscreen_listener.notify = handle_lockscreen_surface_destroy; - wl_signal_add(es-destroy_signal, shell-lockscreen_listener); + wl_signal_add(es-destroy_signal, shell-lockscreen_listener); } static void @@ -217,7 +217,7 @@ tablet_shell_set_switcher(struct wl_client *client, weston_surface_set_position(shell-switcher_surface, 0, 0); shell-switcher_listener.notify = handle_switcher_surface_destroy; - wl_signal_add(es-destroy_signal, shell-switcher_listener); + wl_signal_add(es-destroy_signal, shell-switcher_listener); } static void diff --git a/src/text-backend.c b/src/text-backend.c index 3d36527..da0d275 100644 --- a/src/text-backend.c +++ b/src/text-backend.c @@ -197,7 +197,7 @@ text_input_activate(struct wl_client *client, wl_signal_emit(ec-update_input_panel_signal, text_input-cursor_rectangle); } - wl_text_input_send_enter(text_input-resource, text_input-surface-resource); + wl_text_input_send_enter(text_input-resource, text_input-surface-resource); } static void but other than those and with the ref-count and a real commit message, I think this is ready to go. Kristian --- src/animation.c | 2 +- src/compositor.c | 65 ++- src/compositor.h | 3 +- src/data-device.c | 9 +++--- src/input.c | 24 src/shell.c | 13 - src/tablet-shell.c| 7 ++--- src/xwayland/window-manager.c | 12 src/zoom.c| 5 +++- 9 files changed, 72 insertions(+), 68 deletions(-) diff --git a/src/animation.c b/src/animation.c index b9d0f8a..10ab583 100644 --- a/src/animation.c +++ b/src/animation.c @@ -188,7 +188,7 @@ weston_surface_animation_run(struct weston_surface *surface, weston_surface_animation_frame(animation-animation, NULL, 0); animation-listener.notify = handle_animation_surface_destroy; - wl_signal_add(surface-resource.destroy_signal, animation-listener); + wl_signal_add(surface-destroy_signal, animation-listener); wl_list_insert(surface-output-animation_list, animation-animation.link); diff --git a/src/compositor.c b/src/compositor.c index 099600d..42011f5 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -276,13 +276,13 @@ weston_surface_create(struct weston_compositor *compositor) if (surface == NULL) return NULL; - wl_signal_init(surface-resource.destroy_signal); + wl_signal_init(surface-destroy_signal); + + surface-resource = NULL; wl_list_init(surface-link); wl_list_init(surface-layer_link); - surface-resource.client = NULL; - surface-compositor = compositor;
Re: [PATCH] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.
On Fri, Jun 07, 2013 at 12:25:20AM -0400, Kristian Høgsberg wrote:
On Wed, Jun 05, 2013 at 11:47:40AM +0300, Ander Conselvan de Oliveira wrote:
On 06/04/2013 08:06 AM, Kristian Høgsberg wrote:
On Tue, May 28, 2013 at 05:28:49PM -0700, Sinclair Yeh wrote:
v3:
* Removed unnecessary parentheses
* Added check for switching from EGL image to SHM buffer
* Moved shader assignment out of IF condition
v2:
Fixed the wrong comparison
v1:
Depending on specific DRI driver implementation, glTexImage2D() with data
set to NULL may or may not re-allocate the texture buffer each time it is
called. Unintended consequences happen if later glTexSubImage2D() is
called
to only update a sub-region of the texture buffer.
I've explored moving glTexImage2D() from gl_renderer_attach() and simply
mark the texture dirty, but the current implemention seems cleaner because
I won't have to worry about calling ensure_textures() and re-assigning
gs-shader unnecessarily.
---
src/gl-renderer.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index be74eba..aa8f581 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -68,6 +68,7 @@ struct gl_surface_state {
struct weston_buffer_reference buffer_ref;
int pitch; /* in pixels */
+ int height;
};
struct gl_renderer {
@@ -1213,18 +1214,31 @@ gl_renderer_attach(struct weston_surface *es,
struct wl_buffer *buffer)
}
if (wl_buffer_is_shm(buffer)) {
- gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
- gs-target = GL_TEXTURE_2D;
+ /* Only allocate a texture if it doesn't match existing one.
+ * If gs-num_images is not 0, then a switch from DRM
allocated
+ * buffer to a SHM buffer is happening, and we need to
allocate
+ * a new texture buffer.
+ */
+ if (wl_shm_buffer_get_stride(buffer) / 4 != gs-pitch ||
+ buffer-height != gs-height ||
+ gs-num_images 0) {
+ gs-pitch = wl_shm_buffer_get_stride(buffer) / 4;
+ gs-height = buffer-height;
+ gs-target = GL_TEXTURE_2D;
+
+ ensure_textures(gs, 1);
+ glBindTexture(GL_TEXTURE_2D, gs-textures[0]);
+ glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
+ gs-pitch, buffer-height, 0,
+ GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
Looking better now, but we still need to make sure we do a full upload
before we repaint. If a client is clever about it's resizing and only
posts a partial damage request after attaching the new buffer, we end
up reallocating the texture storage but not uploading the full
contents.
However, weird behavior #1: This shouldn't happen with any of the
clients I have (they all post full damage on resize), yet, I still see
flicker when resizing.
Weird behavior #2: The fix should be something like this:
+ pixman_region32_union_rect(gs-texture_damage,
+ gs-texture_damage,
+ 0, 0,
+ es-geometry.width,
+ es-geometry.height);
after the glTexImage2D call, to make sure we upload all of the
texture. Instead of always uploading the contents (which would upload
twice: immediately and then when we flush damage), we add the new
surface rectangle to texture_damage. However, when I add that, the
window contents just sometimes completely disappears...
That happens when reducing the size. The new buffer dimensions are
not propagated to the surface until the call to surface-configure()
that comes after the attach call. In that case, you add a rectangle
to texture_damage that is bigger than the texture itself. When
Weston tries to upload this rectangle with glTexSubImage2D(), the
check for the rectangle being inside of the texture fails and
nothing is uploaded.
I guess it would make sense to just make texture damage equal to the
size of the texture. But there's a problem that texture_damage is in
surface coordinates, so we either convert the buffer dimensions to
that at this point, or change it to be in actual buffer coordinates.
Cheers,
Ander
Yup, you're right, thanks for looking into this. Sinclair updated the
patch to add the texture damage from the buffer size, by dividing down
by the surface scale. I think it might make more sense just keeping
the texture_damage region in buffer coordinates, but for now, it's all
working here.
Looking at this again, I think the current approach is fine. I was
hoping to store the texture_damage in
Re: [PATCH 1/1] evdev: Fix a high CPU utilization bug
On Thu, Jun 06, 2013 at 05:17:37PM +, Singh, Satyeshwar wrote: The problem was that if we ever switched to another tty while running Weston, then we would essentially not handle any remaining events and Weston would enter an infinite loop where it's trying to process an event but it can't because the processing function evdev_device_data exits before it can read anything from the queue. With this fix, we read whatever is in the queue, but not process it any further. That's odd, that shouldn't happen. We close all evdev devices when we vt switch away. I couldn't reproduce it here either... is there a certain sequence that triggers it? Kristian --- src/evdev.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 9289b1c..70d3c52 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -372,8 +372,6 @@ evdev_device_data(int fd, uint32_t mask, void *data) int len; ec = device-seat-compositor; - if (!ec-focus) - return 1; /* If the compositor is repainting, this function is called only once * per frame and we have to process all the events available on the @@ -391,7 +389,8 @@ evdev_device_data(int fd, uint32_t mask, void *data) return 1; } - evdev_process_events(device, ev, len / sizeof ev[0]); + if (ec-focus) + evdev_process_events(device, ev, len / sizeof ev[0]); } while (len 0); -- 1.7.11.4 ___ 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
[PATCH] text: Fix misleading error message
From: Eduardo Lima (Etrunko) eduardo.l...@linux.intel.com
This should be input_method and not desktop_shell
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
---
src/text-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/text-backend.c b/src/text-backend.c
index 92efd9f..d7ce31c 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -762,7 +762,7 @@ bind_input_method(struct wl_client *client,
if (text_backend-input_method.client != client) {
wl_resource_post_error(resource,
WL_DISPLAY_ERROR_INVALID_OBJECT,
- permission to bind desktop_shell
denied);
+ permission to bind input_method
denied);
wl_resource_destroy(resource);
return;
}
--
1.8.1.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] text: Fix misleading error message
On Thu, Jun 06, 2013 at 10:59:06AM -0300, Eduardo Lima (Etrunko) wrote:
Ping?
This never made it to the list, it got stuck in moderation. Normally
you just subscribe to the list and re-send it, but I found it in the
moderation queue and let it through.
Kristian
On 05/10/2013 05:50 PM, Eduardo Lima (Etrunko) wrote:
From: Eduardo Lima (Etrunko) eduardo.l...@linux.intel.com
This should be input_method and not desktop_shell
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
---
src/text-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/text-backend.c b/src/text-backend.c
index 92efd9f..d7ce31c 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -762,7 +762,7 @@ bind_input_method(struct wl_client *client,
if (text_backend-input_method.client != client) {
wl_resource_post_error(resource,
WL_DISPLAY_ERROR_INVALID_OBJECT,
- permission to bind desktop_shell
denied);
+ permission to bind input_method
denied);
wl_resource_destroy(resource);
return;
}
--
Eduardo de Barros Lima (Etrunko)
Software Engineer, Open Source Technology Center
Intel Corporation
São Paulo, Brazil
eduardo.l...@linux.intel.com
___
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] text: Fix misleading error message
On Fri, May 10, 2013 at 05:50:36PM -0300, Eduardo Lima (Etrunko) wrote:
From: Eduardo Lima (Etrunko) eduardo.l...@linux.intel.com
This should be input_method and not desktop_shell
Thanks, patch applied.
Kristian
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
---
src/text-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/text-backend.c b/src/text-backend.c
index 92efd9f..d7ce31c 100644
--- a/src/text-backend.c
+++ b/src/text-backend.c
@@ -762,7 +762,7 @@ bind_input_method(struct wl_client *client,
if (text_backend-input_method.client != client) {
wl_resource_post_error(resource,
WL_DISPLAY_ERROR_INVALID_OBJECT,
-permission to bind desktop_shell
denied);
+permission to bind input_method
denied);
wl_resource_destroy(resource);
return;
}
--
1.8.1.4
___
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
