Re: absolute positioning and other "missing features" of Wayland

Thanks everyone! This was quite a bit of interesting feedback. Let me add Alexandros to this thread, too, in case he has any input - if the existing hacks seem to be sufficient, or if it makes sense to create a new protocol. (Alexandros: I'm by no means an expert here, but saw your work on Wine,

absolute positioning and other "missing features" of Wayland

Hi everyone, I realize this has always been a controversial topic; I apologize for bringing it up yet again, but I'm wondering if there could be some compromise here. I've been following the development of the Wayland driver for Wine [1] - and it's one of the examples where "applications shouldn'

Re: After display protocol error communication between wayland protocol and client is broken.

Hello, Yes, that's expected. From the documentation : "The error event is sent out when a fatal (non-recoverable) error has occurred" It indicates a bug in the code, so there's no point in handling the error.

Re: [PATCH] Don't look for weston.ini in the current working directory

Done! I somehow missed the move to Gitlab. On Thu, Nov 15, 2018 at 12:14 AM Pekka Paalanen wrote: > On Wed, 14 Nov 2018 23:02:12 -0800 > Dima Ryazanov wrote: > > > It's a bit surprising that Weston looks different when launched from the > root > > of the git repo v

[PATCH] Don't look for weston.ini in the current working directory

dules with arbitrary code. Basically, it's the same problem as including "." in $PATH. Signed-off-by: Dima Ryazanov --- man/weston.ini.man | 1 - man/weston.man | 4 +--- shared/config-parser.c | 8 ++-- 3 files changed, 3 insertions(+), 10 deletions(-) diff --g

[PATCH 2/3] Delete an unused variable

Signed-off-by: Dima Ryazanov --- clients/window.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/clients/window.c b/clients/window.c index 1ab33545..470ac090 100644 --- a/clients/window.c +++ b/clients/window.c @@ -278,7 +278,6 @@ struct window { struct zwp_relative_pointer_v1

[PATCH 3/3] A better fix for a crash when unlocking or unconfining a pointer

This is a rewrite of the fix in: https://lists.freedesktop.org/archives/wayland-devel/2018-May/038140.html It addresses Pekka's concerns about window getting destroyed before the unlock/unconfine event is triggered. Signed-off-by: Dima Ryazanov --- clients/window.c

[PATCH 1/3] Revert "Fix a crash when unlocking or unconfining a pointer"

This reverts commit e0dc5d47cb5f29deec495efd958fcd5f6f833389. Signed-off-by: Dima Ryazanov --- clients/window.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/clients/window.c b/clients/window.c index 12939cb7..1ab33545 100644 --- a/clients

Re: [PATCH weston] Fix a crash when unlocking or unconfining a pointer

On Tue, May 29, 2018 at 3:30 AM Pekka Paalanen wrote: > On Thu, 10 May 2018 00:53:38 -0700 > Dima Ryazanov wrote: > > > In GNOME (but not in Weston), if a window loses focus, the client first > receives > > the focus event, then the unlock/unconfine event. Thi

[PATCH weston] Fix a crash when unlocking or unconfining a pointer

(core dumped) To fix this, get the input from the window instead of the other way around. Signed-off-by: Dima Ryazanov --- clients/window.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/clients/window.c b/clients/window.c index bcf2b017..dee4455f

[PATCH weston] Fix an uninitialized variable

"has_discrete" gets set to true in if/else if, but gets left unset otherwise. So let's initialize it to false. (This was caught by valgrind.) Signed-off-by: Dima Ryazanov --- libweston/compositor-wayland.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libweston/composi

[PATCH weston] Add a missing error check to weston_wm_handle_icon

This fixes a crash when launching Duke Nukem Forever. (Sorry, I wish I had a less ridiculous test case...) Signed-off-by: Dima Ryazanov --- xwayland/window-manager.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c index c307e199

[PATCH weston] Add a help string for --xwayland

Signed-off-by: Dima Ryazanov --- compositor/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/compositor/main.c b/compositor/main.c index 18810f28..1e827884 100644 --- a/compositor/main.c +++ b/compositor/main.c @@ -469,6 +469,7 @@ usage(int error_code) " --shell=M

Re: Subscribed or not?

Looks like you're in. Welcome! On Tue, Nov 21, 2017 at 11:08 PM, Jari Vuomajoki wrote: > Hello! > > I have now subscribed two times for the list, without getting any > confirmation... > > So am I in or not? > > Best Wishes, > Jari Vuomajoki > > ___ > w

Re: [PATCH libinput] tools: replace the tap time measuring tool with a python one

Oh nice, much simpler. I have a few nitpick comments, but it looks good, and works for me. Reviewed-By: Dima Ryazanov Tested-By: Dima Ryazanov On Thu, Nov 16, 2017 at 1:11 PM, Peter Hutterer wrote: > A lot easier to process data in python than in C. > > Signed-off-by: Peter

Re: Running multiple Wayland window managers in different ttys

What do you see if you run weston on tty3 (rather than sway), without setting WAYLAND_SOCKET or --socket? On Sat, Oct 21, 2017 at 12:02 AM, Dima Ryazanov wrote: > 1. Actually, Weston *should* set the right wayland socket automatically. > They're not mapped to ttys - but Weston tries

Re: Running multiple Wayland window managers in different ttys

1. Actually, Weston *should* set the right wayland socket automatically. They're not mapped to ttys - but Weston tries them until it finds an available one (at least, in my case). I see the following in the log: [23:52:27.077] libwayland: unable to lock lockfile /run/user/1000/wayland-0.lock, mayb

Re: [PATCH v2 3/6] launcher-logind: only get a VT on seat0, as only seat0 supports VTs

On Tue, Oct 3, 2017 at 7:28 PM, nerdopolis wrote: > As only seat0 supports TTYs, this changes the logind launcher where > it detects a TTY, only if the seat is seat0. This has only been > tested for logind > --- > libweston/launcher-logind.c | 22 -- > libweston/launcher-util

Re: [PATCH libinput] evdev: replace null sentinel with ARRAY_SIZE

On May 10, 2017 7:14 AM, "Eric Engestrom" wrote: Signed-off-by: Eric Engestrom --- src/evdev.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index a2be6fc..7895644 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -50,6 +50,8 @@ #d

Re: [PATCH 0/2] xdg-shell: Proposal to be more generic for decorations

Overall, I like the idea - it seems to solve the issues with raise/lower, etc. I wonder, though, if removing the explicit move/resize/etc. requests makes it too restrictive. Suppose that, for whatever reason, the client wants to trigger a move or a resize using the right or middle button. Maybe it

Re: [PATCH weston 2/6] libweston: Use the monotonic clock in weston_compositor_get_time

On Tue, Dec 6, 2016 at 3:32 AM, Daniel Stone wrote: > Hi, > > On 5 December 2016 at 03:36, Dima Ryazanov wrote: > > (This is kind of a workaround, but perhaps the right thing to do > anyways.) > > > > The menu implementation in window.c needs to know the time of

Re: [PATCH weston] xdg-shell: Add NULL checks for resources that may have gone away.

, 3 Dec 2016 21:21:44 -0800 > Dima Ryazanov wrote: > > > This should fix some (fairly rare) crashes where the client goes away at > exactly > > the wrong moment, e.g.: > > - Weston sends a message to the client > > - Message causes the client to crash for whatever rea

[PATCH weston 5/6] Display the window menu using the desktop shell

sult (only "Close" for now). This patch is hacky and not quite finished - but I'd like to get some feedback first, to make sure this is the correct approach. Signed-off-by: Dima Ryazanov --- clients/desktop-shell.c | 45 ++

[PATCH weston 6/6] window: Start using xdg-shell's show_window_menu API

We lose the "Fullscreen" menu item, but oh well. Signed-off-by: Dima Ryazanov --- clients/window.c | 40 +++- 1 file changed, 7 insertions(+), 33 deletions(-) diff --git a/clients/window.c b/clients/window.c index d4eeca6..4c494b5 100644 ---

[PATCH weston 3/6] window: Require the serial in window_show_menu

The serial that triggered the menu may not always be the latest serial - as will be the case for the desktop-shell. Let's just require clients to pass it explicitly. They already do it when starting a grab, moving a window, etc. Signed-off-by: Dima Ryazanov --- clients/editor.c

[PATCH weston 1/6] libweston: Pass the serial along with the other data in the show_window_menu API

We'll need it later to actually display a popup menu. Signed-off-by: Dima Ryazanov --- libweston-desktop/internal.h | 2 +- libweston-desktop/libweston-desktop.c | 4 ++-- libweston-desktop/libweston-desktop.h | 4 ++-- libweston-desktop/xdg-shell-v5.c | 3 ++- libweston-de

[PATCH weston 4/6] window: Call the menu callback even if the menu was dismissed

Desktop shell will need to know when to clean up menu-related resources. Other clients might find it useful, too. Signed-off-by: Dima Ryazanov --- clients/window.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/clients/window.c b/clients/window.c index f49ce72..12884f4 100644 --- a

[PATCH weston 2/6] libweston: Use the monotonic clock in weston_compositor_get_time

Switching weston_compositor_get_time to use the monotonic clock works around this issue - though things would break in compositor-wayland if its parent uses something else. Signed-off-by: Dima Ryazanov --- libweston/compositor.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a

[PATCH weston 0/6] Implement xdg-shell's show_window_menu API

he menu is displayed at an offset - When Gnome apps display the menu, it looks like the grab stays around even after the menu is dismissed; you have to click again before you can do anything else. Dima Ryazanov (6): libweston: Pass the serial along with the other data in the show_window_

[PATCH weston] xdg-shell: Add NULL checks for resources that may have gone away.

en it happen once, while stepping through Weston's code in gdb, but seems like the right thing to fix.) Signed-off-by: Dima Ryazanov --- libweston-desktop/xdg-shell-v6.c | 141 --- 1 file changed, 101 insertions(+), 40 deletions(-) diff --git a/libweston-d

[PATCH weston] window: Check for NULL surface in keyboard_handle_enter

This can happen if you right-click in weston-terminal a few times very quickly. The pointer_handle_enter callback already checks for NULL, so let's do that in keyboard_handle_enter, too. Signed-off-by: Dima Ryazanov --- clients/window.c | 5 + 1 file changed, 5 insertions(+) diff --

Re: [PATCH weston 2/2] compositor-wayland: Destroy cursor images earlier

s the crash for me. Reviewed-by: Dima Ryazanov --- > libweston/compositor-wayland.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libweston/compositor-wayland.c b/libweston/compositor- > wayland.c > index d9cbde5..aa69c68 100644 > --- a/libweston

Re: [PATCH weston 1/2] Don't prepend protocol/ to include paths

On Thu, Nov 24, 2016 at 7:32 AM, Daniel Stone wrote: > No need to add protocol/, as it's already handled by an explicit > compiler include path. > > Signed-off-by: Daniel Stone > Reviewed-by: Dima Ryazanov > --- > libweston-desktop/xdg-shell-v5.c | 2 +- > lib

Re: [PATCH weston v2] compositor-wayland: Fix a use after free

Oh, good catch; just reviewed it. Thanks! On Mon, Nov 28, 2016 at 10:20 AM, Daniel Stone wrote: > Hi Dima, > > On 24 November 2016 at 13:13, Dima Ryazanov wrote: > > When a window is being closed, the frame_done callback often runs after > > the output is a

Re: [PATCH weston] compositor-wayland: Set frame callback for Pixman

Yep, fixes the crash, thanks! Reviewed-by: Dima Ryazanov On Mon, Nov 28, 2016 at 8:06 AM, Daniel Stone wrote: > Fixing 89c2f637b9, also set the output's frame_cb for the Pixman > renderer, not just GL. Fixes a segfault when using compositor-wayland > with --use-pixman. >

[PATCH weston v2] compositor-wayland: Fix a use after free

output in frame_done: it's passed in a wayland_output, not a weston_output.) Signed-off-by: Dima Ryazanov --- libweston/compositor-wayland.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayl

Re: [PATCH weston] compositor-wayland: Fix a use after free

> On 24 November 2016 at 06:07, Dima Ryazanov wrote: > > When a window is being closed, the frame_done callback often runs after > > the output is already destroyed, i.e: > > > > wayland_output_start_repaint_loop > > input_handle_button > > wayland_outp

Re: [PATCH weston] gl-renderer: Fix an invalid write when closing a Weston window

client a while ago: https://lists.freedesktop.org/archives/wayland-devel/2013-April/008718.html On Thu, Nov 24, 2016 at 3:51 AM, Daniel Stone wrote: > Hi Dima, > > On 24 November 2016 at 02:41, Dima Ryazanov wrote: > > Call eglMakeCurrent before destroying the native EGL window, simila

[PATCH weston] compositor-wayland: Fix a use after free

stop creating new frame_done callbacks. Signed-off-by: Dima Ryazanov --- libweston/compositor-wayland.c | 59 +++--- 1 file changed, 50 insertions(+), 9 deletions(-) diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c index d9cbde5

Re: [PATCH weston] gl-renderer: Fix an invalid write when closing a Weston window

To repro, run "valgrind weston --output-count=2", and close one of the windows. (When you close the last window, there are even more errors, so this particular one isn't as noticeable.) On Wed, Nov 23, 2016 at 6:41 PM, Dima Ryazanov wrote: > Call eglMakeCurrent before destroy

[PATCH weston] gl-renderer: Fix an invalid write when closing a Weston window

Call eglMakeCurrent before destroying the native EGL window, similar to what other sample clients are already doing. Signed-off-by: Dima Ryazanov --- libweston/gl-renderer.c | 4 1 file changed, 4 insertions(+) diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c index d08bfd0

[PATCH weston] Get rid of the window_create_menu function

It's currently unused, and there's actually no way to use it correctly. The caller cannot free the menu that was created: - the function only returns the window, not the menu - there's no public API to destroy a menu object Signed-off-by: Dima Ryazanov --- client

Re: Implementing show_window_menu in Weston

Got it, thanks Jonas! On Wed, Nov 9, 2016 at 8:56 PM, Jonas Ådahl wrote: > On Wed, Nov 09, 2016 at 03:21:30PM -0800, Dima Ryazanov wrote: > > Hi, > > > > I'd like to take a shot at implementing window menus (from xdg-shell) in > > Weston - but I don't

Implementing show_window_menu in Weston

Hi, I'd like to take a shot at implementing window menus (from xdg-shell) in Weston - but I don't have a good understanding of how the compositor, shell, etc. interact, so wanted to ask about it first. Looks like the entry point for it would be the "show_window_menu" member of "shell_desktop_api"

[PATCH weston] Ignore the OSC code for desktop notifications

In Fedora, bash is configured to display a desktop notification when a command finishes (and the terminal is not focused). weston-terminal complains about it; let's silence it. Signed-off-by: Dima Ryazanov --- clients/terminal.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/cl

Re: [PATCH libinput] evdev: actually ignore joysticks

On Tue, Nov 1, 2016 at 6:19 PM, Peter Hutterer wrote: > A joystick has ID_INPUT_JOYSTICK *and* ID_INPUT set, so we need to check > for > both. > > https://bugs.freedesktop.org/show_bug.cgi?id=98009 > > Signed-off-by: Peter Hutterer > --- > src/evdev.c | 2 +- > test/device.c | 34 +++

Re: [PATCH] weston-launch: Protect KDGKBMODE K_OFF ioctl by KERNEL_VERSION check

The kernel version used to build Weston isn't necessarily the same as the version that will be used to run it. Weston should already work fine on older versions: the second ioctl will return an error - but it's ok as long as the first one succeeds. Also, a compile-time check would prevent Weston b

Re: [PATCH wayland v2 4/4] array-test: Include wayland-util.h and simplify init test

I think I actually know the point of the test. It tries to verify that size, alloc, and data were initialized to 0, rather than left uninitialized - but the difficulty is that uninitialized memory is often already filled with 0s. So the test repeats the process a whole bunch of times, hoping to ev

Re: [PATCH wayland] Revert "client: require WAYLAND_DISPLAY to be set"

All of these arguments makes sense, so I guess I agree with reverting this change. I didn't know about the goal of reducing the number of environment variables. Also, the fact that wayland displays are per user makes it different from the X11 displays. Sorry for all the trouble! On Tue, Aug 18, 20

Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

Oh, you're right, I didn't realize that's what that code was doing. Thanks! On Fri, Aug 14, 2015 at 12:20 AM, Pekka Paalanen wrote: > On Wed, 12 Aug 2015 19:34:31 -0700 > Dima Ryazanov wrote: > > > Although defaulting to wayland-0 seems convenient, it has

Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

So, it seems like pretty much everyone agrees with this change. Could we actually get it in for the 1.9 release? On Thu, Aug 13, 2015 at 4:47 AM, Ryo Munakata wrote: > On Wed, 12 Aug 2015 19:34:31 -0700 > Dima Ryazanov wrote: > > Hi Dima. > > Reviewed-by: Ryo Mu

[PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

egardless of whether there's a wayland compositor running at the same time. Everything else should work as before. The compositor already sets the WAYLAND_DISPLAY when starting the session, so the lack of the default value should not make a difference to the user. Signed-off-by: Dima Ryazanov

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

Sounds good, will do! On Wed, Aug 12, 2015 at 4:41 AM, Pekka Paalanen wrote: > On Mon, 25 May 2015 01:12:15 -0700 > Dima Ryazanov wrote: > > > Although defaulting to wayland-0 seems convenient, it has an undesirable > > side effect: clients may unintentionally connect to

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

Bringing this up again. What do you guys think? Does it make sense to push this change? On Wed, May 27, 2015 at 1:50 AM, Dima Ryazanov wrote: > (Oops, sent too soon by accident.) > > Yep, DISPLAY always needs to be set - and I figured, there's a reason it > is that way, so that

[PATCH wayland-web] Fix a broken link

Signed-off-by: Dima Ryazanov --- releases.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases.html b/releases.html index 2454a55..f19f725 100644 --- a/releases.html +++ b/releases.html @@ -22,7 +22,7 @@ wayland-1.8.0.tar.xz - - http://lists.freedesktop.org

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

s, but it feels like a workaround. It only gets more complicated if the app supports more backends - framebuffer, etc. On Wed, May 27, 2015 at 1:45 AM, Dima Ryazanov wrote: > Yep, DISPLAY always needs to be set - and I figured, there's a reason > > On Tue, May 26, 2015 at 2:59 AM, Pek

Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

Yep, DISPLAY always needs to be set - and I figured, there's a reason On Tue, May 26, 2015 at 2:59 AM, Pekka Paalanen wrote: > On Tue, 26 May 2015 10:40:15 +0100 > Daniel Stone wrote: > > > Hi, > > > > On 26 May 2015 at 10:26, Giulio Camuffo wrote: > > > 2015-05-26 12:21 GMT+03:00 Pekka Paalan

[PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

egardless of whether there's a wayland compositor running at the same time. Everything else should work as before. The compositor already sets the WAYLAND_DISPLAY when starting the session, so the lack of the default value should not make a difference to the user. Signed-off-by: Di

Re: [PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

> Expecting anything atomic from X11 in the first place is a wrong > assumption. > > On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa > wrote: > > Hi, > > > > On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov wrote: > >> > >> Add the output to the lis

[PATCH weston] compositor-wayland: Code cleanup

Don't do multi-assignments. Signed-off-by: Dima Ryazanov --- src/compositor-wayland.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c index aaf205b..935701a 100644 --- a/src/compositor-wayland.c +++ b/src/compo

Re: [PATCH weston] compositor-wayland: Handle window close events more gracefully

On Tue, May 19, 2015 at 11:35 PM, Pekka Paalanen wrote: > On Tue, 19 May 2015 16:41:19 -0700 > Bryce Harrington wrote: > > > On Mon, May 18, 2015 at 11:14:16PM -0700, Dima Ryazanov wrote: > > > When a compositor window is closed, remove the output instead of just > ex

Re: [PATCH weston] compositor-wayland: Handle window close events more gracefully

; On Mon, May 18, 2015 at 11:14:16PM -0700, Dima Ryazanov wrote: > > > >> When a compositor window is closed, remove the output instead of > just exiting. > > > >> > > > >> (The "if (!input->output)" checks are kind of ugly - but I couldn

[PATCH weston] compositor-wayland: Handle window close events more gracefully

When a compositor window is closed, remove the output instead of just exiting. (The "if (!input->output)" checks are kind of ugly - but I couldn't find a better way to handle the output going away.) Signed-off-by: Dima Ryazanov --- src/compositor-wayland.c | 22

Re: [PATCH xwayland] xwayland: do not add output into output_list multiple times

I just made that change in my set of patches, and I think it fixes the problem. On Thu, May 14, 2015 at 9:43 AM, Dima Ryazanov wrote: > Actually, why not just move "xorg_list_append(&xwl_output->link, > &xwl_screen->output_list);" to xwl_output_create? > > I

[PATCH v2 3/3] xwayland: Destroy xwl_output when wl_output gets removed

This makes Xwayland correctly handle a monitor getting unplugged. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-output.c | 1 + hw/xwayland/xwayland.c| 10 +- hw/xwayland/xwayland.h| 1 + 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/hw

[PATCH v2 2/3] xwayland: Remove a useless out-of-memory check

snprintf does not allocate memory, so we can never get an out-of-memory error. (Also, the error handler would free xwl_output after it was already registered as an event listener.) Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-output.c | 6 +- 1 file changed, 1 insertion(+), 5

[PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

Add the output to the list when it's created rather than when its properties change (as pointed out by Marek Chalupa). Remove the output from the list when it's destroyed. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-output.c | 5 +++-- 1 file changed, 3 insertions(+), 2

Re: [PATCH xwayland] xwayland: do not add output into output_list multiple times

Actually, why not just move "xorg_list_append(&xwl_output->link, &xwl_screen->output_list);" to xwl_output_create? I can't tell if there's a reason it's in xwl_output_done, or if it's just an oversight. On Thu, May 14, 2015 at 9:37 AM, Dima Ryazanov

Re: [PATCH xwayland] xwayland: do not add output into output_list multiple times

Oh wow, I was playing around with outputs, and never realized output_handle_done was being called after any geometry change, not just after the output was created. On Thu, May 14, 2015 at 2:58 AM, Marek Chalupa wrote: > output.done event can be sent even on some property change, not only > when

Re: [PATCH 3/4] xwayland: Keep a list of wayland globals

On Thu, May 14, 2015 at 12:57 AM, Marek Chalupa wrote: > On Tue, May 12, 2015 at 7:21 PM, Dima Ryazanov wrote: > >> The logic is pretty much copied from weston's clients/window.c. >> >> Signed-off-by: Dima Ryazanov >> --- >> hw/xwayland/xwaylan

[PATCH 2/4] xwayland: Remove a useless out-of-memory check

snprintf does not allocate memory, so we can never get an out-of-memory error. (Also, the error handler would free xwl_output after it was already registered as an event listener.) Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-output.c | 6 +- 1 file changed, 1 insertion(+), 5

[PATCH 3/4] xwayland: Keep a list of wayland globals

The logic is pretty much copied from weston's clients/window.c. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland.c | 25 - hw/xwayland/xwayland.h | 8 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland.c b/hw/xwa

[PATCH 4/4] xwayland: Destroy xwl_output when wl_output gets removed

This makes Xwayland correctly handle a monitor getting unplugged. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-output.c | 1 + hw/xwayland/xwayland.c| 16 hw/xwayland/xwayland.h| 1 + 3 files changed, 18 insertions(+) diff --git a/hw/xwayland

[PATCH 1/4] xwayland: Remove the output from the list after destroying it

Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-output.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c index 155cbc1..1d75d0b 100644 --- a/hw/xwayland/xwayland-output.c +++ b/hw/xwayland/xwayland-output.c @@ -190,6 +190,7

Re: [PATCH weston v2] gl-renderer: If an XRGB format is requested but unavailable, try ARGB

Just Fine(tm) - and probably better than just exiting. > > Signed-off-by: Derek Foreman > --- > > Dima Ryazanov called me out for fallback_format() not working on all > endians, > and I've reworked the loop to be a single loop instead of two, similar to > Daniel&

[PATCH weston] xwm: Fix the window decoration hints.

s like it's supposed to invert the values of the rest of the flags. Signed-off-by: Dima Ryazanov --- xwayland/window-manager.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c index cab7e20..7

[PATCH] xwayland: Implement smooth scrolling

We don't even need to simulate button clicks; it's done automatically. This also fixes scrolling in Qt5 apps. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-input.c | 53 +--- hw/xwayland/xwayland.h | 4 2 files changed, 16

[PATCH weston 2/2] desktop-shell: Remove the panel popup

It doesn't work anymore, and it never did anything useful. Signed-off-by: Dima Ryazanov --- clients/desktop-shell.c | 33 - 1 file changed, 33 deletions(-) diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c index ac2928f..e2f9f80 100644 --- a/cl

[PATCH weston 1/2] desktop-shell: Require a popup parent to be a shell surface

Currently, the shell crashes if the parent is not a shell surface. Instead, send an error to the client. Signed-off-by: Dima Ryazanov --- desktop-shell/shell.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index

Re: [PATCH weston] desktop-shell: Fix a crash when right-clicking the panel

Sure, I'll remove it then. (I was going to remove it originally - but figured, it was useful for testing since it exposed this bug.) On Wed, Apr 8, 2015 at 7:00 AM, Pekka Paalanen wrote: > On Mon, 6 Apr 2015 13:27:23 -0700 > Dima Ryazanov wrote: > > > Yeah, the logic i

Re: [PATCH weston] desktop-shell: Fix a crash when right-clicking the panel

er and Jonas in case they haven't noticed this yet... > > On 06/04/15 01:52 AM, Dima Ryazanov wrote: > > It looks like the error-checking code assumes the popup's parent is > > a shell surface - but that's not always the case. > > > > Signed-off-by: Dima Rya

[PATCH weston] desktop-shell: Fix a crash when right-clicking the panel

It looks like the error-checking code assumes the popup's parent is a shell surface - but that's not always the case. Signed-off-by: Dima Ryazanov --- desktop-shell/shell.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/desktop-shell/shell.c b/desktop-she

[PATCH weston v2] Fix "Back", "Forward", and other special mouse buttons in the X11 compositor.

They're off by 4 because of the scroll buttons. Signed-off-by: Dima Ryazanov --- src/compositor-x11.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/compositor-x11.c b/src/compositor-x11.c index 5863446..2792251 100644 --- a/src/compositor-x11.c +++

Re: [PATCH weston] Fix "Back", "Forward", and other special mouse buttons in the X11 compositor.

I actually feel the same way - but kept the old style just in case. I'll update it. On Tue, Feb 3, 2015 at 2:36 PM, Peter Hutterer wrote: > On Mon, Dec 22, 2014 at 11:51:05AM -0800, Dima Ryazanov wrote: > > They're off by 4 because of the scroll buttons. > > > >

Re: [PATCH weston] Fix "Back", "Forward", and other special mouse buttons in the X11 compositor.

Looks like this patch got discarded (according to patchwork)? This one is different from http://patchwork.freedesktop.org/patch/39499/. That one fixed the Wayland->X11 key code translation; this one fixes X11->Wayland. On Dec 22, 2014 11:51 AM, "Dima Ryazanov" wrote: > They&

[PATCH weston] Fix "Back", "Forward", and other special mouse buttons in the X11 compositor.

They're off by 4 because of the scroll buttons. (However, if you test them in XWayland, they'll appear to work because XWayland has the same bug; see http://lists.x.org/archives/xorg-devel/2014-December/044987.html) Signed-off-by: Dima Ryazanov --- src/compositor-x11.c | 5 +++

[PATCH v2] Fix "Back", "Forward", and other special mouse buttons in XWayland.

Currently, the indexes are off by 4 because of the scroll buttons. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-input.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index b8c543c..5e20418 100644

Re: [PATCH] Fix "Back", "Forward", and other special mouse buttons in XWayland.

Sure, I'll fix that. On Sun, Dec 21, 2014 at 8:43 PM, Peter Hutterer wrote: > On Sun, Dec 21, 2014 at 02:39:02AM -0800, Dima Ryazanov wrote: > > Currently, the indexes are off by 4 because of the scroll buttons. > > > > Signed-off-by: Dima Ryazanov > > --- >

[PATCH] Fix "Back", "Forward", and other special mouse buttons in XWayland.

Currently, the indexes are off by 4 because of the scroll buttons. Signed-off-by: Dima Ryazanov --- hw/xwayland/xwayland-input.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index b8c543c..ad30c31 100644

Re: [PATCH 3/4] queue-test: Add another assertion

I've brought this up once, but looks like it's acceptable in the test suite since it already relies on asserts: http://lists.freedesktop.org/archives/wayland-devel/2013-February/007454.html On Sep 28, 2014 6:57 PM, "Bill Spitzak" wrote: > On 09/28/2014 11:49 AM, Karsten Otto wrote: > > - w

[PATCH weston] xwayland: Clean up the WM properly if X server crashes

The X cleanup code uses wxs->wm to check if the WM has been created - but that variable was never initialized. So if X crashes, the WM doesn't get destroyed, causing a crash when it tries to repaint a window. Signed-off-by: Dima Ryazanov --- xwayland/launcher.c | 6 -- 1 file ch

weston crash in destroy_shell_surface

I haven't figured out how to fix the crash, but wanted to bring it up before the 1.4 release. It's pretty easy to reproduce it: 1. Open weston-terminal (or maybe another client) 2. Right-click the titlebar 3. Click "close" As far as I can tell, the problem is these lines in destroy_shell_surface

Re: [PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

> In fact it would mean than focus_window would be an unmapped windows, > which looks strange to me. > > Axel Davy > > Le 15/11/2013 11:01, Dima Ryazanov a écrit : > > Fixes a crash in Firefox when clicking an "install plugin" popup. > > Signed-off-by: Dima Ryazano

[PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

Fixes a crash in Firefox when clicking an "install plugin" popup. Signed-off-by: Dima Ryazanov --- src/xwayland/window-manager.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c index 5ee9480..6d29

[PATCH xwayland 1/3] Set the view to NULL when unmapping an X11 window

Fixes a crash caused by accessing a deleted view in weston_wm_window_schedule_repaint. It can be easily reproduced by switching between menus in Firefox. Signed-off-by: Dima Ryazanov --- src/xwayland/window-manager.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/xwayland/window

[PATCH xwayland 3/3] Check if the frame exists before reading its size

This fixes crashes caused by popup windows that don't have override_redirect (e.g., menus in VLC and KDE apps), though I don't know if this is correct. Signed-off-by: Dima Ryazanov --- src/xwayland/window-manager.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

occuring in > XWayland because of views (take vlc, go to the menu, crash). > > It appears ok to me to set view to NULL at these locations, but there's > probably something more to do. > > Axel Davy > > On 15/11/2013, Dima Ryazanov wrote : > > Ping :) > > >

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

Ping :) On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov wrote: > Fixes a crash caused by accessing a deleted view in > weston_wm_window_schedule_repaint. It can be easily reproduced by switching > between menus in Firefox. > > Signed-off-by: Dima Ryazanov > --- > src/xway

[PATCH xwayland] Set the view to NULL when unmapping an X11 window

Fixes a crash caused by accessing a deleted view in weston_wm_window_schedule_repaint. It can be easily reproduced by switching between menus in Firefox. Signed-off-by: Dima Ryazanov --- src/xwayland/window-manager.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/xwayland/window

Re: [PATCH xwayland] xwayland: Probe outputs on preinit

Actually, never mind. Not sure what the problem was, but I updated everything just now, and xwayland works! On Sat, Sep 7, 2013 at 1:51 AM, Jonas Ådahl wrote: > On Thu, Sep 05, 2013 at 09:00:51PM -0700, Dima Ryazanov wrote: > > Hi, > > > This actually made xwayland work f

  1   2   >