[PATCH] Remove explicit dependency on $(WAYLAND_LIBS)

. HTH, Cheers, Olivier From 090928e71a4c06ee8f22cbf90b65dc4e248ee838 Mon Sep 17 00:00:00 2001 From: Olivier Fourdan ofour...@redhat.com Date: Wed, 3 Dec 2014 13:49:37 +0100 Subject: [PATCH] Remove explicit dependency on $(WAYLAND_LIBS) Xwayland Makefile explicitely set its dependencies

[PATCH] Remove explicit dependency on $(WAYLAND_LIBS)

dependency to avoid the problem (LDADD ought to be enough to get the right libraries linked). Signed-off-by: Olivier Fourdan ofour...@redhat.com --- hw/xwayland/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am index 4e0e1bb..9945540

[PATCH libinput] Do not abort on invalid speed.

a message). Signed-off-by: Olivier Fourdan ofour...@redhat.com --- src/evdev.c | 5 - src/filter.c | 3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 6e318dc..c96a66b 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1194,8 +1194,11

Re: [PATCH libinput] Do not abort on invalid speed.

, Olivier - Original Message - From: Peter Hutterer peter.hutte...@who-t.net To: Olivier Fourdan ofour...@redhat.com Cc: wayland-devel@lists.freedesktop.org Sent: Wednesday, 4 February, 2015 10:15:56 PM Subject: Re: [PATCH libinput] Do not abort on invalid speed. On Wed, Feb 04, 2015 at 10:34

Re: [PATCH libinput] Do not abort on invalid speed.

- From: Olivier Fourdan ofour...@redhat.com To: Peter Hutterer peter.hutte...@who-t.net Cc: wayland-devel@lists.freedesktop.org Sent: Wednesday, 4 February, 2015 10:28:22 PM Subject: Re: [PATCH libinput] Do not abort on invalid speed. Hi Peter, Weird, that occurs with xf86-drv-libinput

[PATCH libinput v2] Fix an abort if the device speed is NaN

speed = 1.0) will be false as well, thus triggering the abort() and the crash of the entire X server along with it. The solution is to use the same construct in both routines, so that it fails gracefully in libinput_device_config_accel_set_speed(). Signed-off-by: Olivier Fourdan ofour

Re: [PATCH libinput] Do not abort on invalid speed.

On 05/02/15 11:26, Olivier Fourdan wrote: On 05/02/15 02:30, Peter Hutterer wrote: On Wed, Feb 04, 2015 at 04:45:37PM -0500, Olivier Fourdan wrote: Hi Peter, Just to clarify, evdev_accel_config_set_speed() calls filter_set_speed() which calls accelerator_set_speed() which reaches

Re: [PATCH libinput] Do not abort on invalid speed.

Hey Peter, On 05/02/15 02:30, Peter Hutterer wrote: On Wed, Feb 04, 2015 at 04:45:37PM -0500, Olivier Fourdan wrote: Hi Peter, Just to clarify, evdev_accel_config_set_speed() calls filter_set_speed() which calls accelerator_set_speed() which reaches the assert(). My patch basically removes

Re: [PATCH] Fix mutex hang in colord on output removal

On 15/01/15 15:31, Richard Hughes wrote: How come this is removed too? I think I'd rather it stayed so we show a warning rather than explode in a ball of fire. ocms is taken from the container now (that was the casting error), so no need for the lookup from cms as we already have it. And if

[PATCH] Fix mutex hang in colord on output removal

be cms_output and not cms_colord. Signed-off-by: Olivier Fourdan ofour...@redhat.com --- src/cms-colord.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/src/cms-colord.c b/src/cms-colord.c index c541a34..a6b105c 100644 --- a/src/cms-colord.c +++ b/src/cms-colord.c

Re: [RFC PATCH] Allow more file descriptors than clients limit

usable clients in Xwayland (even if the client limit will remain a theoretical limit unlikely to be reachable in Xwayland). Signed-off-by: Olivier Fourdan ofour...@redhat.com --- See also: http://lists.x.org/archives/xorg-devel/2015-May/046543.html include/opaque.h | 1 + os/WaitFor.c

Re: How to create a Wayland Compositor?

Hi I am unhappy with all Desktop Environments / Window Managers out there. That's a lot of unhappiness :) Then I watched some online records of some talks about X / Wayland. I am now totally convinced that X is horrible. Beauty is always in the eyes of the beholder so I won't comment on

Re: How can an X11 tell it's running in XWayland?

Hi Jonas, On 31 July 2015 at 09:52, Jonas Ådahl jad...@gmail.com wrote: Might be missing something obvious but shouldn't it be possible to check whether ​​ WAYLAND_DISPLAY environment variable is set? Y ​eap, even simpler! Cheers, Olivier​ ___

How can an X11 tell it's running in XWayland?

Hi Some apps should be run in a plain X11 session but not in XWayland (e.g. an X11 screensaver makes no sense in Wayland/XWayland). There is one atom WL_SURFACE_ID that should be created only on/by XWayland (for obvious reasons), is that reliable enough to determine we're running on XWayland?

Re: How can an X11 tell it's running in XWayland?

Hi Thiago, On 31 July 2015 at 10:28, Thiago Macieira thi...@kde.org wrote: It might have been unset to cause a parent application to start inside X instead of using Wayland. ​Yes, I thought of that as well, however in this case I'm working on, it's for a screen saver so I reckon the

Re: [PATCH weston] desktop-shell: NULL check whether a popup parent is a shell surface

> get_shell_surface(parent) may return NULL if the client passed a > unassigned wl_surface or a wl_surface with a non-shell surface role > (such as cursor role). > > https://bugs.freedesktop.org/show_bug.cgi?id=92316 > > Signed-off-by: Jonas Ådahl <jad...@gmail.com>

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

Hi all, On 24 August 2015 at 11:56, Pekka Paalanen pekka.paala...@collabora.co.uk wrote Pushed: c0636dd..c7dbaa1 master - master Quick question, is the answer/suggestion I received back at the time here: http://lists.freedesktop.org/archives/wayland-devel/2015-July/023729.html still

Re: State of Wayland

Hi Bryce, cc'ing xorg-devel as well, see below, I would like to help with xwayland. - Original Message - > I've assembled a blog post with a run-down of our current status on > Wayland - bugs needing attention, features in the works, etc. > Thanks go to Pekka for helping gather all the

Re: State of Wayland

Hi Bryce, - Original Message - > That'd be great, thanks Olivier! > > I'm not sure if the wayland patchwork is representative of Xwayland > patches, as we tend to prune PW to show only items bound for weston and > wayland specifically. But perhaps we can get a patchwork queue set up >

Re: [PATCH] xwayland: Adjust screen size with rotation

Hi all, Any chance to get a review of this patch? Cheers, Olivier - Original Message - > As mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=92076#c5 > > Tested-by: Artem Chudinov > > Cheers, > Olivier > ___ >

[PATCH] xwayland: Adjust screen size with rotation

bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92076 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-output.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c

Re: [PATCH wayland] Contributing: explain Patchwork

Hi Pekka, On 21/09/15 09:41, Pekka Paalanen wrote: From: Pekka Paalanen Add general guidelines for using Patchwork, as we heavily rely on it nowadays. Signed-off-by: Pekka Paalanen Maybe you could also mention the command

Re: [PATCH wayland v2] Contributing: explain Patchwork

libinput patch management > - reword "if not found in Patchwork" > - reword "Not applicable" > - mention pwclient > > Cc: Bryce Harrington <br...@osg.samsung.com> > Cc: Olivier Fourdan <ofour...@redhat.com> > Sign

Re: [PATCH xwayland 1/4] xwayland: Add xwl_touch struct

Hey Carlos, On 27/05/15 18:41, Carlos Garnacho wrote: This struct holds information about each individual, ongoing touchpoint. A list of these is held by the xwl_seat. Signed-off-by: Carlos Garnacho lgtm Rebased and added this patch to my tree, but I don't have the

Re: [PATCH xwayland 2/4] xwayland: Implement the wl_touch interface

On 27/05/15 18:41, Carlos Garnacho wrote: A DeviceIntPtr with touch valuators is also created in order to deliver the translated touch events. The lifetime of xwl_touch structs is tied to the wayland ones, finishing in either wl_touch.up() or wl_touch.cancel() Signed-off-by: Carlos Garnacho

Re: [PATCH xwayland 4/4] xwayland: Make the XYToWindowProc implementation aware of touchpoints

On 29/05/15 11:45, Carlos Garnacho wrote: Hey Jasper, On Wed, May 27, 2015 at 7:56 PM, Jasper St. Pierre wrote: I'm planning on removing this hook and just make compositors deal with the fallout. Unfortunately, it hasn't been merged yet.

Re: [PATCH xwayland 3/4] xwayland: Remove related touchpoints when unrealizing windows

On 27/05/15 18:42, Carlos Garnacho wrote: These sequences are forgotten to all purposes. Signed-off-by: Carlos Garnacho lgtm. Applied in my tree. Cheers, Olivier ___ wayland-devel mailing list

[pull request] xwayland fixes

Hi Adam, Could you please pull from the following git tree some fixes for Xwayland (some are quite old). Cheers, Olivier --- The following changes since commit 58d54ee82dfae5486bc09d04d2760c922d54d631: glamor: explicitly check for GL_OES_EGL_image (2015-09-17 11:03:15 -0400) are available

Re: [PATCH] xwayland: Adjust screen size with rotation

> bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92076 > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > --- > hw/xwayland/xwayland-output.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > As mentioned in https://bugs.freedesktop.org/

xdg-shell's set_parent method

Hi, xdg-shell's set_parent [1] request is used by toolkits and compositors to achieve what is done with transients in X11. But the ICCCM in X11 allows for transients to be "None", in which case the dialog will be treated as a transient for the group by most X11 window managers. Some

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hi Jonas, - Original Message - > On Mon, Jun 06, 2016 at 09:50:19AM -0400, Matthias Clasen wrote: > > To me, 'draw states' sounds a lot like 'mwm hints' - which would be a > > 180 degree reversal from semantic states back to presentation states. > > Do we really want to go down that road

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hi Benoit, - Original Message - > [...] > > My primary complain is that draw states should be merged with the > previously defined window/surface states, because by definition a draw > state is a state for a window, just like the state activated for example. I disagree here, if anything

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hi Benoit, - Original Message - > On 07/06/2016 10:30, Olivier Fourdan wrote: > > [...] > > I disagree here, if anything we should keep the semantic states separate, > > we wouldn't want to have something like "no_shadow" or "no_border"

[PATCH v2] xdg-shell: Add tiled state

When tiled, clients must obey the window geometry specified in the configure event and can choose to hide some of their decorations. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: Simplify the proposal and keep only one "tiled" state instead of one per

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hi Mike, Thanks for posting this, perfect timing to discuss this in light of the tiling discussions ^_~ I reckon tiling and shadows can be related (even though one is an actual state, the other is a draw state). For a bit of background on my comments below, see

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hi Jonas, - Original Message - > On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote: > > > > Do we really want reserved ranges here? > > > > Some people reckon having (undocumented) reserved ranges was a bad idea in > > "states",

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hey Just to make it clear, as a foreword to my comments inline below, I am not against the patch, far from it, I just wanted to make sure we considered edge values instead of only "no shadow", and we also considered other draw states. If we considered and dismissed them, fine. For reference,

Re: [PATCH RFC] xdg-shell: Add tiled states

Hi On 2 June 2016 at 16:44, Drew DeVault wrote: > [...] >> >> Why a separate protocol for that sole purpose, why not using Mike's >> "draw state" proposal? > > Your protocol suggests that the only ways a window can be tiled is > against an edge. This is not the case. In most

Re: [PATCH RFC] xdg-shell: Add tiled states

Hi On 2 June 2016 at 15:51, Drew DeVault wrote: > This protocol seems to be barking up the wrong tree. This protocol only > serves traditional floating WMs for whom tiling only goes as far as > filling 50% of the screen with a window (as mentioned by others) and > isn't very

[PATCH RFC] Add tiled states per edge

event when tiled, just like when maximized or fullscreen. They may also change their decorations, of course, but not only. This takes ideas from Jonas and Matthias, as discussed in GNOME bug #766860. Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=766860 Olivier Fourdan (1): xdg-shell: Add ti

[PATCH RFC] xdg-shell: Add tiled states

When tiled, clients must obey the window geometry specified in the configure event and can choose to hide some of their decorations. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27 +++ 1 file chang

Re: [PATCH RFC] xdg-shell: Add tiled states

Hi Mike, - Original Message - > I've read the ticket linked in the other mail, but your use of "tiled" here > is confusing to me since you (and the ticket) appear to be conflating two > separate-but-unrelated meanings. "Tiled" is a type of window layout policy > which organizes windows

Re: [PATCH] xdg-shell: add draw states for xdg_surface

Hey - Original Message - > On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote: > > [...] > > If we considered and dismissed them, fine. > > They are not "actively" considered in this patch, but as I mentioned > earlier, I think tiling state

Re: [PATCH] clients: fix build on Linux

Hi Emmanuel, > POSIX.1-2008 (and likely prior versions), and thus Linux as well, > define ioctl() in this header, so it seems strange it doesn’t exist on > your system. I based my patch on a couple of information I found here: https://bugzilla.redhat.com/show_bug.cgi?id=439403

[PATCH] clients: fix build on Linux

Cannot find out why stropts.h is needed and Linux doesn't support streams anyway, so there is no stropts.h. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- clients/simple-dmabuf-v4l.c | 1 - 1 file changed, 1 deletion(-) diff --git a/clients/simple-dmabuf-v4l.c b/clients/simple-

Re: [PATCH] clients: fix build on Linux

Hi Derek, - Original Message - > > stropts.h is not available on Linux. > Well, this is all fascinating. :) Yeah, sorry, my sentence was badly worded, I should have written "streams is not available on Linux upstream" instead (even though there've been 3rd party modules in the past).

[PATCH] clients: fix build on Linux

stropts.h is not available on Linux. Check for this header in the configure script and include it only if available to avoid a build failure on systems which do not have stropts.h. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- clients/simple-dmabuf-v4l.c | 2 ++ config

Override redirect windows with keyboard grabs on Xwayland

Hi all, First of all, sorry for cross posting, but I am not really sure where the issue is to be addressed... I am looking into https://bugs.freedesktop.org/show_bug.cgi?id=96547 and concluded this is actually the same as https://bugzilla.gnome.org/show_bug.cgi?id=752956 Basically, long

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

Hi Yong, - Original Message - > Hi Olivier, > Some minor spelling corrections below. (Same as the previous response, > replying again to associate with this latest patch version.) I'm happy > to correct these with my own separate patch after this is merged. > > > > --- > > v2: Rename

Re: [PATCH] Fix compilation error when git commit message has quotes (")

Hi, On 7 April 2016 at 10:14, Chokshi, Mitul wrote: > This e-mail and any attachments may contain confidential material for the > sole > use of the intended recipient(s). > ​​ > Any review or distribution by others is > ​​ > strictly prohibited. If you are not the

Re: [PATCH v2] xdg-shell: add preferred min/max size requests

Hi Bill, > I think it would be ok to set both the minimum and maximum with a single > request. Yes, agreed. Cheers, Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org

[PATCH v3] xdg-shell: add preferred min/max size requests

urate animation, etc. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413 --- v2: Rename the request to "set_preferred_max_size", add "set_preferred_min_size" as well v3: Rebase above patch 72427

[PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

se, draw an accurate animation, etc. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413 --- v2: Rename the request to "set_preferred_max_size", add "set_preferred_min_size" as well v3: Rebase above patch 72427

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

Hi Bill, > > > > It allows a client to say "I look best below this size, but if the > > > compositor wants to fill a larger rectangle, I can draw something nicer > > > than the compositor can do (the compositor can only pad or scale)". > > > > That's something different, isn't it? The compositor

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

> On 04/12/2016 08:17 AM, Olivier Fourdan wrote: > [...] > > > > But that raise another point, what if the client itself specifies a > > geometry (using set_window_geometry) outside of the min/max? > > > > I reckon that would be a protocol error as well

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

Hi Jonas, > What is the point of making the max/min size just "preferred"? What are > the use cases when compositor should ignore the hint? > > I suppose one would be when a client sets a relatively small max size, > but then asks to be maximized or fullscreened, forcing the compositor to >

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

Hi Mike, - Original Message - > I think this should probably use uint instead of int for params since zero > is the "unset" number. Otherwise you have to write something about negative > sizes. Reason I used "int" is because these are limits for size, which are expressed with int as

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

Hi Jasper, - Original Message - > I figured min/max would be double-buffered state and require a commit > to take affect. In fact, anything else means that we can't extend with > additional size constraints in the future, since they couldn't be > applied atomically. Completely agree,

[PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

"set_max_size" and "set_min_size" to xdg-shell so that the client can tell the compositor what would be its smallest/largest acceptable size, and that the compositor can decide if maximize or fullscreen is achievable, draw an accurate animation, etc. Signed-off-by: Olivier Fourdan

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

Hi, > > Good point. Setting an invalid state should probably result in a > > protocol error. > > No this cannot be a protocol error because that makes it difficult to > change the size range to a new one that does not intersect the old one. > > Perhaps having the commit of an invalid state be

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

> > > Good point. Setting an invalid state should probably result in a > > > protocol error. > > > > No this cannot be a protocol error because that makes it difficult to > > change the size range to a new one that does not intersect the old one. > > > > Perhaps having the commit of an invalid

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

Hi Mike. > Okay, if we're not going with uints then at the least can the "use 0 to > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly > cover that case? I think we should simply indicate that the width and height must be greater than or equal to zero, so we remain

[PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

"set_max_size" and "set_min_size" to xdg-shell so that the client can tell the compositor what would be its smallest/largest acceptable size, and that the compositor can decide if maximize or fullscreen is achievable, draw an accurate animation, etc. Signed-off-by: Olivier Fourdan

Re: weston-info

On 6 April 2016 at 14:12, Daniel Stone wrote: > > Just a fly by shed color thought. If we in the future want to add more > > generic debug tools (for example something like xev that is a bit more > > nice than "WAYLAND_DEBUG=1 weston-terminal |& grep -e '[insert complex > >

Re: [PATCH v2] xdg-shell: add preferred min/max size requests

Hi Jasper, > > [...] > > + > > +If never set, the size of the surface is not limited by the > > client. > > + > > +A value of zero for either width, height or both means that the > > +client has no preference regarding the maximum size in the given > > +dimension.

Re: [PATCH v4 xdg-shell-unstable-v6] xdg-shell: add preferred min/max size requests

Hi > I see no reason for "preferred" to be in the name. There is no intention to > be able to ever specify a "real" min/max size so this word does not > distinguish the values from any thing else. This was asked explicitly on irc #wayland last Monday (iirc) by SardemFF7. This is not to

[PATCH] xdg-shell: add set_max_size request

"set_max_size" to xdg-shell so that the client can tell the compositor which would be its largest acceptable size, so that the compositor can decide if maximize or fullscreen makes sense, draw an accurate animation, etc. Signed-off-by: Olivier Fourdan <ofour...@redhat.com>

weston-info

Hi all, weston-info seems like a generally useful tool, even outside of weston, and gives interesting information on the compositor, supported interfaces, outputs, inputs... Only thing that seems fairly specific is the presentation timing client protocol. I think it could be beneficial to move

Re: [PATCH] xdg-shell: add set_max_size request

Hi all, - Original Message - > On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre" > > said: > > > I think min/max hints are acceptable in xdg-shell. > > i agree. they are realistic things a apps have as constraints on their > content. > knowing in advance

Re: [PATCH] xdg-shell: add set_max_size request

Hi Jasper, - Original Message - > "hint" just means "don't bother setting this flag, since it won't do > anything". > > If we want min/max size rules, I want them to be enforced. Compositors > SHOULD NOT attempt to configure windows above or below the requested > size. Right, so it gets

Re: weston-info

Hi Pekka, On 5 April 2016 at 10:30, Pekka Paalanen wrote: > ​[...] > > > this is a good idea indeed. > > Originally weston-info was needed in Weston repository, because it was > useful in reporting specific information from extensions being > developed in Weston. Nowadays

[PATCH v2] xdg-shell: add preferred min/max size requests

urate animation, etc. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413 --- v2: Rename the request to "set_preferred_max_size", add "set_preferred_min_size" as well unstable/xdg-shell/xdg-shell-unstab

Re: [PATCH] xdg-shell: add set_max_size request

Hi Mike, Thanks for starting the discussion! :) - Original Message - > Just to play devil's advocate, do we really want to start getting into size > hint type stuff? After this will be min size, then step size, then aspect, > ... I think these are different issues. min size, step size,

Re: [PATCH] xdg-shell: add set_max_size request

Hi Mike, > Hm, you raise some interesting points. However, I think your argument is > somewhat misled by your claim that "this case is unique". If there is an > application which does not want to be larger than a certain size, why could > there not also be an application which does not want to be

Re: [PATCH] xdg-shell: add set_max_size request

Hi Mike, - Original Message - > [...] > > Yes, I know you are not currently advocating for it, but you've proved my > point--others will see this go in and then they will push for it. Adding > any form of size hints is a slipper slope which leads to more size hints > imo. My turn to

Re: [PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

lient can tell the compositor what would be its smallest/largest > acceptable size, and that the compositor can decide if maximize or > fullscreen is achievable, draw an accurate animation, etc. > > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > Bugzilla: https://bugzi

[PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

"set_max_size" and "set_min_size" to xdg-shell so that the client can tell the compositor what would be its smallest/largest acceptable size, and that the compositor can decide if maximize or fullscreen is achievable, draw an accurate animation, etc. Signed-off-by: Olivier Fourdan

Re: Protocol for window previews/thumbnails

Hi, On 12 May 2016 at 00:35, ade low wrote: > [...] > It is important that it is a standard, cross-compositor protocol. For > example, if I am using my app on "xfwm-wayland" and then I decide that I > want to switch to KWin, my app should continue to work. As a side note,

Re: [PATCH] xdg-shell: add invalid min/max size errors

Hi Yong, > > These error types seem to help resolve the issues discussed, regarding > invalid min/max size requests, and is > > Reviewed-by Yong Bakos Thanks for the review. Meanwhile on irc, Jonas has pointed me toward

[PATCH] xdg-shell: add invalid min/max size errors

Given that set_min_size and set_max_size requests can raise protocol errors, add the errors that will be raised. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- unstable/xdg-shell/xdg-shell-unstable-v6.xml | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff

[PATCH v8 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

"set_max_size" and "set_min_size" to xdg-shell so that the client can tell the compositor what would be its smallest/largest acceptable size, and that the compositor can decide if maximize or fullscreen is achievable, draw an accurate animation, etc. Signed-off-by: Olivier Fourdan

xdg-shell: about configure, states and ack_configure

Hi all, Following the discussion around the min/max size addition to xdg-shell v6, I would like to get one point about configure events clarified, if possible. First, a quick reminder of what the spec currently says: 1. configure: The configure event asks the client to resize its surface

Re: xdg-shell: about configure, states and ack_configure

- Original Message - > On Thu, 21 Apr 2016 03:57:52 -0400 (EDT) > Olivier Fourdan <ofour...@redhat.com> wrote: > > > Hi all, > > > > Following the discussion around the min/max size addition to > > xdg-shell v6, I would like to get one poi

Re: [PATCH 1/3 v3] wayland-server: Add API to control globals visibility

Hi Yong, Thanks for your follow-up. I don;t necessarily agree with your all of comments though, see below. > > @@ -164,6 +165,15 @@ wl_global_create(struct wl_display *display, > > void > > wl_global_destroy(struct wl_global *global); > > > > +typedef bool

Re: [PATCH 1/3 v3] wayland-server: Add API to control globals visibility

Hi Yong, > Despite the R-b's you received, and I hate to encourage you to do > a v4, I would like to suggest two things that are important: > - naming > - more comments/doc > > I'll send another email soon with some suggestions to save you time. Sure, I would need some more details and a

Re: [PATCH weston 1/2] input: Update keyboard serial on press and release

; > When dealing with popup windows which require a match in serials, if the > event that caused the popup to be shown is a key release, then the popup > would be dismissed. > > This occurs when navigating gtk+ sub-menus using the keyboard. > > Signed-off-by: Olivier Fourdan &l

Re: [PATCH weston 2/2] shell: Check for keyboard driven popup as well

s can > also be triggered by keyboard shortcuts. > > If a user activates a menu without any previous pointer ineraction with > the client, weston would dismiss the xdg-popup because the keyboard > serial would not match the popup serial. > > Signed-off-by: Olivier Fourdan <of

[RFC PATCH wayland] wayland-server: Add API to control globals visibility

their own private interfaces that regular clients should not use. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- src/wayland-server-core.h | 8 +++ src/wayland-server.c | 38 ++- tests/display-test.c

Re: Override redirect windows with keyboard grabs on Xwayland

Hi Adam, > > That mechanism would probably not work as is with O-R windows for a > > couple of reasons: > > Your descriptions here seem to assume the inability to fix the > compositor, which to me seems... insane? No, I did not assume this, but I find focus management in X11 to be quite

[PATCH 1/3 v3] wayland-server: Add API to control globals visibility

their own private interfaces that regular clients should not use. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: Follow-up on Jonas' comments on v1: Add global's data as user data in callback filter function Pass wl_global instead of wl_interface in callback filter fu

[PATCH 0/3] Re: [PATCH v2] wayland-server: Add API to control globals visibility

globals being > advertised to all clients. The default is no filter. Done > Jonas Thanks again for your review, Cheers, Olivier Olivier Fourdan (3): wayland-server: Add API to control globals visibility wayland-server: Add functions to wl_global tests: Add a test for glo

[PATCH 2/3 v3] wayland-server: Add functions to wl_global

When using a wl_global, a server may need to retrieve the associated wl_interface and user data. Add a couple of convenient functions wl_global_get_interface() and wl_global_get_user_data() for this purpose. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v3: split out as i

[PATCH 3/3 v3] tests: Add a test for global filter

Test if the global filter is effectively filtering out the global when the filter returns false. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v3: split out as its own commit tests/display-test.c | 58 1 file chang

Re: [PATCH 1/3 v3] wayland-server: Add API to control globals visibility

sn't prevent a client from binding an interface if > it knows the name and id. Do we care? registry_bind() will raise an WL_DISPLAY_ERROR_INVALID_OBJECT if a client try to bind an interface which is filtered out, so this should be covered, or am I missing something? Cheers, Olivier > 2016-08-0

[PATCH weston 1/2] input: Update keyboard serial on press and release

be dismissed. This occurs when navigating gtk+ sub-menus using the keyboard. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=768017 --- libweston/input.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib

[PATCH weston 2/2] shell: Check for keyboard driven popup as well

with the client, weston would dismiss the xdg-popup because the keyboard serial would not match the popup serial. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=768017 --- desktop-shell/shell.c | 14 +++--- 1 file changed, 11 insertions

Re: Override redirect windows with keyboard grabs on Xwayland

Hey Adam, > This feels a lot like any other "app wants attention" case where you > should just get a pulsing button or bouncing icon in the taskbar. The > o-r window might be mapped and focused from Xwayland's perspective but > there's nothing compelling wayland to actually show or focus it >

[PATCH 3/3 v6] tests: Add a test for global filter

Test if the global filter is effectively filtering out the global when the filter returns false. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v3: split out as its own commit v4: Follow up on Jonas' comments: assert(hi.has_data_offer == false) instead of assert(hi.has_data

Re: [PATCH 1/3 v3] wayland-server: Add API to control globals visibility

Hi Yong > I thought you'd say that. :) > Ok, I get it - I did think of those things as well although coming to > a different conclusion. However, just consider this... > > > [...] > > I agree with your reasons above, but this is a setter associated with > a struct member, and the struct member

Re: [PATCH 3/3 v4] tests: Add a test for global filter

ter is effectively filtering out the global when > the filter returns false. > > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > --- > v3: split out as its own commit > v4: Follow up on Jonas' comments: > assert(hi.has_data_offer == false) inste

  1   2   3   >