[RFC 1/2] Introduce wl_probe_visible protocol

wl_probe_visible (for now _wl_probe_visible) is a reintroduction of the "wl_probe" method of making it possible to position a surface so that it is completely visible, when positioning it relative to some other already mapped surface. It works by checking what parts of a rectangle relative to an ex

[RFC 2/2] window: Use wl_probe_visible when positioning menus

To avoid positioning the menu offscreen, probe the visibility of the intended rectangle and adapt it before showing the popup. This patch is based by a patch[0] by Rob Bradford from 2013. [0] http://lists.freedesktop.org/archives/wayland-devel/2013-April/008667.html Signed-off-by: Jonas Ådahl --

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

On Wed, 2015-09-30 at 17:43 -0500, Michael Catanzaro wrote: > Minor issue: this and the next patch introduce the requirement that > accept is called on the data offer before the mouse grab is released. > I > now see this has always been required by mutter -- not sure why -- > but > it's new for Wes

Re: [PATCH wayland v4] protocol: Add DnD actions

Reviewed-by: Michael Catanzaro Nit regarding data_offer.action and data_source.action: "This event can be emitted multiple times during the drag-and-drop operation, mainly in response to source side changes (through data_source.set_actions), destination side changes (through data_offer.set_action

Re: [PATCH weston v3] data-device: Implement DnD actions

Reviewed-by: Michael Catanzaro On Wed, 2015-09-30 at 22:50 +0200, Carlos Garnacho wrote: > The policy in weston in order to determine the chosen DnD action is > deliberately simple, and is probably the minimals that any compositor > should be doing here. > > Besides honoring the set_actions requ

Re: [PATCH weston] data-device: Implement DnD progress notification

Reviewed-by: Michael Catanzaro Looks mostly good to me. The only problem I see is that you've left stale conditionals in both data_offer_accept and data_offer_receive, which can't be hit anymore since you added the bails up above. Be sure that fd gets freed in data_offer_receive when it's not sen

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

Reviewed-by: Michael Catanzaro These are important fixes for the protocol that will allow drags to work between GTK+ and Chrome. Thanks for working on this, Carlos! Nit #1: the existing documentation doesn't use the DnD abbreviation, so I would write out "drag-and-drop" in the documentation of t

[PATCH weston v3] data-device: Implement DnD actions

The policy in weston in order to determine the chosen DnD action is deliberately simple, and is probably the minimals that any compositor should be doing here. Besides honoring the set_actions requests on both wl_data_source and wl_data_offer, weston now will emit the newly added "action" events n

[PATCH weston] data-device: Implement DnD progress notification

Weston now sends wl_data_source.drop_performed and .drag_finished in order to notify about the different phases of DnD. wl_data_source.cancelled is also used as mentioned in the docs, being emitted also on DnD when the operation is meant to fail (eg. source and dest didn't agree on a mimetype). T

[PATCH wayland v4] protocol: Add DnD actions

These 2 requests have been added: - wl_data_source.set_actions: Notifies the compositor of the available actions on the data source. - wl_data_offer.set_actions: Notifies the compositor of the available actions on the destination side, plus the preferred action. Out of the data from these req

[PATCH wayland] protocol: Improve data source notification around DnD progress

Currently, there's no means for the DnD origin to know whether the destination is actually finished with the DnD transaction, short of finalizing it after the first transfer finishes, or leaking it forever. But this poses other interoperation problems, drag destinations might be requesting several

Re: [PATCH wayland] server: Make serial number 0 mean invalid

I don't necessarily like this. The absence of a serial can have radical meanings on behavior. Being able to pass 0 to mean "no serial" anywhere we currently rely on a serial seems like poor design to me, and can easily be done by mistake. In cases where we have two behaviors for serial-aware and n

[PATCH] wayland: add release request on wl_seat v2

Compared to the first version, I changed the description according to Jonas's comment. No real consensus have emerged on IRC or on the mailing list about version numbering. So I choosed to keep them as it is done now. David FORT (1): Add a release request on wl_seat protocol/wayland.xml | 11 +

[PATCH] wayland: add a release request on wl_seat

This is required if we want to correctly remove a wl_seat compositor-side. A wl_seat is announced as a global object, then it is bound by the client. When the compositor wants to remove the seat, it shall announce the global removal of the object. The client can then call the release request on the

Re: [PATCH weston] xdg-shell: Clarify ack_configure behaviour

On Tue, Sep 01, 2015 at 08:49:31AM -0700, Jasper St. Pierre wrote: > Reviewed-by: Jasper St. Pierre Thanks for reviewing. Pushed: To ssh://git.freedesktop.org/git/wayland/weston 0b7da01..dcba1a1 master -> master > On Tue, Sep 1, 2015 at 8:32 AM, Derek Foreman wrote: > > Right now many too

Re: [PATCH wayland] server: Make serial number 0 mean invalid

Hi, On 30 September 2015 at 16:59, Derek Foreman wrote: > Having an invalid serial number is quite useful - for example, we can > have protocol requests that optionally take a serial number or 0 > instead of having two similar requests. > > Signed-off-by: Derek Foreman > --- > > Well, let's see

Re: [PATCH weston] cosmetic: add missing line between variable declarations and code

On Wed, Sep 30, 2015 at 01:34:57PM -0500, Derek Foreman wrote: > Signed-off-by: Derek Foreman Reviewed-by: Bryce Harrington Pushed: To ssh://git.freedesktop.org/git/wayland/weston a3377cd..0b7da01 master -> master > --- > src/libinput-seat.c | 1 + > 1 file changed, 1 insertion(+) > > d

Re: [PATCH][weston] ivi-layout-transition: Standardize the check for layout_transition_register

Thanks for following up on this. On Wed, Sep 30, 2015 at 09:38:37AM -0300, Lucas Tanure wrote: > Check the return from layout_transition_register in order to fix > potential leak of memory pointed to by transition. And don't register a > null transition. > > Signed-off-by: Lucas Tanure Reviewed

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

On Wednesday, 30 September 2015, Derek Foreman wrote: > On 30/09/15 12:01 PM, Bill Spitzak wrote: > > My main concern is that programmers are going to search for the word > > "raise" to figure out how to raise windows. They are not going to search > > for "present" or "indicate_activity" or any o

Re: [PATCH weston 3/4] input: Move seat capability update sends out of init functions

On 29/09/15 09:47 PM, Jonas Ådahl wrote: > On Tue, May 05, 2015 at 03:01:53PM -0500, Derek Foreman wrote: >> This lets device_added() do additional processing before the update is >> sent, which will be useful later when recognizing keyboard capabilities. > > Is the point of this to unset the keyb

[PATCH weston] cosmetic: add missing line between variable declarations and code

Signed-off-by: Derek Foreman --- src/libinput-seat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libinput-seat.c b/src/libinput-seat.c index c9f9ed2..5f91b68 100644 --- a/src/libinput-seat.c +++ b/src/libinput-seat.c @@ -105,6 +105,7 @@ static void device_removed(struct udev_input *i

Re: [PATCH wayland] server: Make serial number 0 mean invalid

On Wed, Sep 30, 2015 at 9:45 AM, Derek Foreman wrote: > > So you're in favour of not bothering to give a helper function in > libwayland, and just expecting everyone to do their own thing? > I think so. Programmers want to know that it is a number, and not possibly some complex type that is expe

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

On Wed, Sep 30, 2015 at 10:27 AM, Derek Foreman wrote: > > Well, X calls similar functionality "UrgencyHint"... That's actually > more descriptive than imperative. The idea is that we let the > compositor know the surface needs attention, not that we tell it what to > do. > That was because th

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

On 30/09/15 12:01 PM, Bill Spitzak wrote: > > > On Tue, Sep 29, 2015 at 12:18 PM, Derek Foreman > wrote: > > > > 2. Call the function "xdg_surface_raise". Because raising is exactly > > what the client expects. It does not mean that it *has* to raise the

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

On Tue, Sep 29, 2015 at 12:18 PM, Derek Foreman wrote: > > > 2. Call the function "xdg_surface_raise". Because raising is exactly > > what the client expects. It does not mean that it *has* to raise the > > window. If you don't do this, lots of programmers are going to ask where > > the raise fun

Re: black surface in desktop shell fullscreen mode

If you are actually destroying the fullscreen surface, then this sounds like a bug. The inability to make a fullscreen surface partially-transparent is on purpose, though it might be considered a design error. I believe Weston is trying to pad out the buffer (which may be the wrong shape or size)

Re: [PATCH wayland] server: Make serial number 0 mean invalid

On 30/09/15 11:37 AM, Bill Spitzak wrote: > > > On Wed, Sep 30, 2015 at 8:59 AM, Derek Foreman > wrote: > > Having an invalid serial number is quite useful - for example, we can > have protocol requests that optionally take a serial number or 0 > inste

Re: [PATCH wayland] server: Make serial number 0 mean invalid

On Wed, Sep 30, 2015 at 8:59 AM, Derek Foreman wrote: > Having an invalid serial number is quite useful - for example, we can > have protocol requests that optionally take a serial number or 0 > instead of having two similar requests. > > Signed-off-by: Derek Foreman > --- > > Well, let's see wh

[PATCH wayland] server: Make serial number 0 mean invalid

Having an invalid serial number is quite useful - for example, we can have protocol requests that optionally take a serial number or 0 instead of having two similar requests. Signed-off-by: Derek Foreman --- Well, let's see where this goes ;) I've seen a few times now when having an invalid ser

[PATCH][weston] ivi-layout-transition: Standardize the check for layout_transition_register

Check the return from layout_transition_register in order to fix potential leak of memory pointed to by transition. And don't register a null transition. Signed-off-by: Lucas Tanure --- ivi-shell/ivi-layout-transition.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a

Re: State of Wayland protocol development

On Tue, Sep 29, 2015 at 09:14:26PM +0100, Daniel Stone wrote: > Hi Jonas, > > On 18 September 2015 at 08:00, Jonas Ådahl wrote: > > Right now, the way to get a protocol officially declared stable is, more > > or less, to implement it in weston, wait for a while maybe making > > changes, and then

black surface in desktop shell fullscreen mode

Hi all As I known, when a window is fullscreen, desktop shell will create a black surface after it. If the window is transparent later, it shows a black screen. But the app developers maybe except it to be hide. Just take QWindow function hide for example, app1 start app2, then app2 call hide, it

Re: random window positon with desktop shell

Hi Daniel I agree with you. Maybe waylandsink can resolve this problem. But we need update Qt too. Thank you. 2015-09-30 16:01 GMT+08:00 Daniel Stone : > Hi Nancy, > > On 30 September 2015 at 08:56, zou lan wrote: > > I use the player in qtmultimedia examples. But our video team modify the > >

Re: random window positon with desktop shell

Hi Nancy, On 30 September 2015 at 08:56, zou lan wrote: > I use the player in qtmultimedia examples. But our video team modify the > code xvimagesink to v4L2sink. They say we can't support xvimagesink. > My Qt version is 5.4.1 now. Newer versions support waylandsink, which performs the same func

Re: State of Wayland protocol development

On 29 September 2015 at 21:14, Daniel Stone wrote: > On 18 September 2015 at 08:00, Jonas Ådahl wrote: >> The main issue, I believe, is that we lack defined procedure and agreed >> upon requirements for what may actually be placed in such a repository. I >> don't think it makes sense to have a sa

Re: random window positon with desktop shell

Hi Giulio I use the player in qtmultimedia examples. But our video team modify the code xvimagesink to v4L2sink. They say we can't support xvimagesink. My Qt version is 5.4.1 now. Best Regards Nancy 2015-09-30 15:36 GMT+08:00 Giulio Camuffo : > 2015-09-30 10:33 GMT+03:00 zou lan : > > Hi all >

Re: random window positon with desktop shell

Hi, On 30 September 2015 at 08:36, Giulio Camuffo wrote: > 2015-09-30 10:33 GMT+03:00 zou lan : >> I ask this because I run a qt media player on platform wayland, I find it >> shows video contents in anothor hardware layer through V4L2 interface, but >> the UI is in fb layer by wayland path. So V

Re: random window positon with desktop shell

2015-09-30 10:33 GMT+03:00 zou lan : > Hi all > > I ask this because I run a qt media player on platform wayland, I find it > shows video contents in anothor hardware layer through V4L2 interface, but > the UI is in fb layer by wayland path. So V4L2 interfaces need to know the > UI window start pos

Re: random window positon with desktop shell

Hi all I ask this because I run a qt media player on platform wayland, I find it shows video contents in anothor hardware layer through V4L2 interface, but the UI is in fb layer by wayland path. So V4L2 interfaces need to know the UI window start position. But wayland don't have protocol to get th