Re: Requests for Proposal for hosting XDC 2019

[Daniel Vetter]

On Thu, Jun 21, 2018 at 11:16 PM, Daniel Vetter  wrote:
> Hi all,
>
> The X.org board is soliciting proposals to host XDC in 2019. By the usual
> rotation a location in (North) America is preferred, but the board will also
> consider other locations, especially if there's an interesting co-location
> with another conference.
>
> If you consider hosting XDC, we have assembled a wiki page with what's
> generally expected and needed:
>
> https://www.x.org/wiki/Events/RFP/
>
> If possible the board would like to decide on the next location at XDC
> 2017 in Mountain View, please submit your proposal with at least the key

^^ should be XDC 2018 in La Coruna ofc.

So much for not properly updating the template again this year :-)
-Daniel

> information about location, possible dates and estimated costs to
> bo...@foundation.x.org latest by 31th August. An early quick heads-up
> to the board if you consider hosting would also be good, in case we
> need to adjust the schedule a bit. Also earlier is better since in
> generally there
> will be a bit of Q with organizers.
>
> And if you just have some questions about what organizing XDC entails,
> please feel free to chat with a previous organizers, or with someone from
> the board.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
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
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Requests for Proposal for hosting XDC 2019

[Daniel Vetter]

Hi all,

The X.org board is soliciting proposals to host XDC in 2019. By the usual
rotation a location in (North) America is preferred, but the board will also
consider other locations, especially if there's an interesting co-location
with another conference.

If you consider hosting XDC, we have assembled a wiki page with what's
generally expected and needed:

https://www.x.org/wiki/Events/RFP/

If possible the board would like to decide on the next location at XDC
2017 in Mountain View, please submit your proposal with at least the key
information about location, possible dates and estimated costs to
bo...@foundation.x.org latest by 31th August. An early quick heads-up
to the board if you consider hosting would also be good, in case we
need to adjust the schedule a bit. Also earlier is better since in
generally there
will be a bit of Q with organizers.

And if you just have some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.

Thanks, Daniel
-- 
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
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Dual display in clone mode or extended mode with Weston

[Matheus Santana]

On Thu, Jun 21, 2018 at 3:44 PM, Matheus Santana  wrote:

>
>
> On Thu, Jun 21, 2018 at 5:11 AM, Pekka Paalanen 
> wrote:
>
>> On Wed, 13 Jun 2018 17:40:59 +0530
>> Ashvini Deshmukh  wrote:
>>
>> > Hello All,
>> >
>> > I have read queries for dual display on freedesktop.org
>> >
>> > I need your help in the same context.
>> >
>> > Currently we are creating one application to support multiple displays
>> with
>> > Wayland.
>>
>> Hi,
>>
>> you are developing an application, ok. I assume that means a Wayland
>> client specifically.
>>
>> > We are unaware that one compositor will be sufficient for dual display.
>>
>> Sorry, I don't understand. Are you asking whether one Wayland
>> compositor could driver multiple displays? Yes, they can in general.
>> Capabilities will vary between different compositor implementations.
>>
>> > We need to know about how virtual framebuffer is created per display.
>>
>> As an application developer, why would you care about that? That is a
>> compositor internal implementation detail.
>>
>> Why virtual? Real outputs do not have virtual framebuffers, they have
>> real framebuffers as far as the compositor is concerned.
>>
>> > As DRM supports only one compositor,
>> > How to display same content on second display OR can we have different
>> user
>> > events on second display monitor.
>>
>> What do you mean?
>>
>> If a Wayland compositor supports and has been configured to show the
>> same content on multiple displays, then it will do that. From a Wayland
>> client perspective, there is nothing you need to do to have your
>> window show up on cloned displays compared to a single display case.
>>
>> By user events, do you mean input events?
>>
>> It is certainly possible to write a compositor that dedicates one set
>> of input devices for one display and another set of input devices for
>> the other display.
>>
>> Applications are expected to support multiple wl_seat globals (similar
>> to multi-pointer X in essence). There is nothing else they would need
>> to specifically support for a compositor that had multiple outputs,
>> cloned outputs, or divided input devices in any arbitrary way.
>>
>> I did not understand your requirements well enough to say how well
>> Weston would work for you.
>>
>> For example, Weston currently does not support multiple KMS devices,
>> but it does support multiple displays on a single KMS device. Support
>> for multiple KMS devices is desired in Weston though, so maybe it will
>> in the future.
>>
>
> I'm curious about what you specifically mean by KMS device. Each graphics
> card?
>

Found the response for this in SoC ideas page
:

Weston supports multiple outputs, but currently limits them to a single
> GPU. Add support to Weston's DRM backend to open several KMS devices, with
> the ability to use outputs from all of them.
>


>
> I've just tried Weston with two displays and it worked out on the fly
> ("extended mode").
>
>
>> Weston's clone mode is currently limited to sharing a CRTC between all
>> displays, assuming someone reviews the final patch needed to configure
>> it. Support for this configuration does not seem to be common among PC
>> graphics hardware, embedded boards may have better chances.
>>
>
> What does CRTC stand for?
>
>>
>>
>> Thanks,
>> pq
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>
> Best regards,
> Matheus
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-web 3/3] building: refer to libinput docs for building info

[Matheus Santana]

This replaces outdated instructions on how to build libinput.

Signed-off-by: Matheus Santana 
---
 building.html | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/building.html b/building.html
index b075051..03f7e3e 100644
--- a/building.html
+++ b/building.html
@@ -219,26 +219,10 @@ $ cd ..
 
 http://www.freedesktop.org/wiki/Software/libinput/;>Libinput
 translates evdev events into Wayland events. It has been split from
-Weston as the code is reusable by any Wayland compositor on Linux.
-
-
-$ git clone https://cgit.freedesktop.org/wayland/libinput;>git://anongit.freedesktop.org/wayland/libinput
-$ cd libinput
-$ ./autogen.sh --prefix=$WLD
-$ make  make install
-$ cd ..
-
-
-
-You probably need the development package for
-  http://www.freedesktop.org/wiki/Software/libevdev/;>libevdev,
-  this is in https://cgit.freedesktop.org/libevdev;>git://anongit.freedesktop.org/libevdev
-
-https://sourceforge.net/projects/linuxwacom/;>libwacom source 
is in git://git.code.sf.net/p/linuxwacom/libwacom
-
-http://xkbcommon.org/;>libxkbcommon source is
-in http://github.com/xkbcommon/libxkbcommon;>git://github.com/xkbcommon/libxkbcommon.
-
+Weston as the code is reusable by any Wayland compositor on Linux.
+Head to
+https://wayland.freedesktop.org/libinput/doc/latest/building_libinput.html;>
+libinput docs for instructions on how to build it.
 
 Weston and demo applications
 
-- 
2.1.4

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

[PATCH wayland-web 2/3] building: use enable-llvm option

[Matheus Santana]

Fix

error: --enable-llvm is required when building r300

while building Mesa.

Signed-off-by: Matheus Santana 
---
 building.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/building.html b/building.html
index 35e8173..b075051 100644
--- a/building.html
+++ b/building.html
@@ -167,7 +167,7 @@ $ git clone https://cgit.freedesktop.org/mesa/mesa;>git://anongit.freed
 $ cd mesa
 $ ./autogen.sh --prefix=$WLD --enable-gles2 \
   --with-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi \
-  --with-gallium-drivers=r300,r600,swrast,nouveau
+  --with-gallium-drivers=r300,r600,swrast,nouveau --enable-llvm
 $ make  make install
 $ cd ..
 
-- 
2.1.4

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

[PATCH wayland-web 1/3] building: replace with-egl-platforms option

[Matheus Santana]

This gets rid of

WARNING: --with-egl-platforms is deprecated. Use --with-platforms
instead.

while building Mesa.

Signed-off-by: Matheus Santana 
---
 building.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/building.html b/building.html
index fdfa997..35e8173 100644
--- a/building.html
+++ b/building.html
@@ -166,7 +166,7 @@ more recent releases.
 $ git clone https://cgit.freedesktop.org/mesa/mesa;>git://anongit.freedesktop.org/mesa/mesa
 $ cd mesa
 $ ./autogen.sh --prefix=$WLD --enable-gles2 \
-  --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi \
+  --with-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi \
   --with-gallium-drivers=r300,r600,swrast,nouveau
 $ make  make install
 $ cd ..
-- 
2.1.4

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

Re: Dual display in clone mode or extended mode with Weston

[Matheus Santana]

On Thu, Jun 21, 2018 at 5:11 AM, Pekka Paalanen  wrote:

> On Wed, 13 Jun 2018 17:40:59 +0530
> Ashvini Deshmukh  wrote:
>
> > Hello All,
> >
> > I have read queries for dual display on freedesktop.org
> >
> > I need your help in the same context.
> >
> > Currently we are creating one application to support multiple displays
> with
> > Wayland.
>
> Hi,
>
> you are developing an application, ok. I assume that means a Wayland
> client specifically.
>
> > We are unaware that one compositor will be sufficient for dual display.
>
> Sorry, I don't understand. Are you asking whether one Wayland
> compositor could driver multiple displays? Yes, they can in general.
> Capabilities will vary between different compositor implementations.
>
> > We need to know about how virtual framebuffer is created per display.
>
> As an application developer, why would you care about that? That is a
> compositor internal implementation detail.
>
> Why virtual? Real outputs do not have virtual framebuffers, they have
> real framebuffers as far as the compositor is concerned.
>
> > As DRM supports only one compositor,
> > How to display same content on second display OR can we have different
> user
> > events on second display monitor.
>
> What do you mean?
>
> If a Wayland compositor supports and has been configured to show the
> same content on multiple displays, then it will do that. From a Wayland
> client perspective, there is nothing you need to do to have your
> window show up on cloned displays compared to a single display case.
>
> By user events, do you mean input events?
>
> It is certainly possible to write a compositor that dedicates one set
> of input devices for one display and another set of input devices for
> the other display.
>
> Applications are expected to support multiple wl_seat globals (similar
> to multi-pointer X in essence). There is nothing else they would need
> to specifically support for a compositor that had multiple outputs,
> cloned outputs, or divided input devices in any arbitrary way.
>
> I did not understand your requirements well enough to say how well
> Weston would work for you.
>
> For example, Weston currently does not support multiple KMS devices,
> but it does support multiple displays on a single KMS device. Support
> for multiple KMS devices is desired in Weston though, so maybe it will
> in the future.
>

I'm curious about what you specifically mean by KMS device. Each graphics
card?

I've just tried Weston with two displays and it worked out on the fly
("extended mode").


> Weston's clone mode is currently limited to sharing a CRTC between all
> displays, assuming someone reviews the final patch needed to configure
> it. Support for this configuration does not seem to be common among PC
> graphics hardware, embedded boards may have better chances.
>

What does CRTC stand for?

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

Best regards,
Matheus
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EXT: [PATCH weston 0/1] Allow forcing outputs on

[Tomasz Olszak]

I probably mislead you, I probably haven't noticed difference between
starting weston without screens and weston state after disconnecting
all screens.
Still great that is was possible to fix so fast.

2018-06-21 15:01 GMT+02:00 Pekka Paalanen :
> On Thu, 21 Jun 2018 11:03:36 +0200
> Tomasz Olszak  wrote:
>
>> To reproduce the issue:
>>
>> weston.ini:
>> [output]
>> name=HDMI-A-2
>> mode=74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync
>> force-on=true
>>
>> Connect screen to HDMI-A-1 and start weston. You get weston info:
>> interface: 'wl_output', version: 3, name: 13
>>x: 0, y: 0, scale: 1,
>>physical_width: 410 mm, physical_height: 230 mm,
>>make: 'PHL', model: 'Philips 196V',
>>subpixel_orientation: unknown, output_transform: normal,
>>mode:
>> ...
>> interface: 'wl_output', version: 3, name: 14
>>x: 1366, y: 0, scale: 1,
>>physical_width: 0 mm, physical_height: 0 mm,
>>make: 'unknown', model: 'unknown',
>>subpixel_orientation: unknown, output_transform: normal,
>>mode:
>>width: 1280 px, height: 720 px, refresh: 59.855 Hz,
>>flags: current
>>
>
> The above is all ok. I thought you didn't have any real monitor
> connected and then the x coordinate became odd from the start.
>
>>
>> Now disconnect HDMI-A-1:
>> interface: 'wl_output', version: 3, name: 14
>>x: 2732, y: 0, scale: 1,
>>physical_width: 0 mm, physical_height: 0 mm,
>>make: 'unknown', model: 'unknown',
>>subpixel_orientation: unknown, output_transform: normal,
>>mode:
>>width: 1280 px, height: 720 px, refresh: 59.855 Hz,
>>flags: current
>>
>> That seems like a bug.
>
> Right, it's a bug, but not the kind of bug I expected. When the Philips
> gets disconnected, the remaining output should at most move to 0,0, not
> move further away.
>
> I've just sent patches to fix this:
> https://patchwork.freedesktop.org/series/45166/
>
>
> Thanks,
> pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: EXT: [PATCH weston 0/1] Allow forcing outputs on

[Pekka Paalanen]

On Thu, 21 Jun 2018 11:03:36 +0200
Tomasz Olszak  wrote:

> To reproduce the issue:
> 
> weston.ini:
> [output]
> name=HDMI-A-2
> mode=74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync
> force-on=true
> 
> Connect screen to HDMI-A-1 and start weston. You get weston info:
> interface: 'wl_output', version: 3, name: 13
>x: 0, y: 0, scale: 1,
>physical_width: 410 mm, physical_height: 230 mm,
>make: 'PHL', model: 'Philips 196V',
>subpixel_orientation: unknown, output_transform: normal,
>mode:
> ...
> interface: 'wl_output', version: 3, name: 14
>x: 1366, y: 0, scale: 1,
>physical_width: 0 mm, physical_height: 0 mm,
>make: 'unknown', model: 'unknown',
>subpixel_orientation: unknown, output_transform: normal,
>mode:
>width: 1280 px, height: 720 px, refresh: 59.855 Hz,
>flags: current
> 

The above is all ok. I thought you didn't have any real monitor
connected and then the x coordinate became odd from the start.

> 
> Now disconnect HDMI-A-1:
> interface: 'wl_output', version: 3, name: 14
>x: 2732, y: 0, scale: 1,
>physical_width: 0 mm, physical_height: 0 mm,
>make: 'unknown', model: 'unknown',
>subpixel_orientation: unknown, output_transform: normal,
>mode:
>width: 1280 px, height: 720 px, refresh: 59.855 Hz,
>flags: current
> 
> That seems like a bug.

Right, it's a bug, but not the kind of bug I expected. When the Philips
gets disconnected, the remaining output should at most move to 0,0, not
move further away.

I've just sent patches to fix this:
https://patchwork.freedesktop.org/series/45166/


Thanks,
pq


pgpGJ7goMQ9i8.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 2/2] libweston: fix output reflow on removal

[Pekka Paalanen]

From: Pekka Paalanen 

This is regression apparently introduced in
0de859ede4bad72b5d3b78e086632f02196d997f, which accidentally swapped the
sign of 'delta_width' in the original call site. If one removes an
output, the remaining outputs on the right are getting moved even
further to the right.

The outputs to the right should be moved to the left instead, to close
the gap left by the removed output.

Reported-by: Tomasz Olszak 
Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 8e01eacc..516be96b 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -5409,7 +5409,7 @@ weston_compositor_remove_output(struct weston_output 
*output)
 
weston_presentation_feedback_discard_list(>feedback_list);
 
-   weston_compositor_reflow_outputs(compositor, output, output->width);
+   weston_compositor_reflow_outputs(compositor, output, -output->width);
 
wl_list_remove(>link);
wl_list_insert(compositor->pending_output_list.prev, >link);
-- 
2.16.4

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

[PATCH weston 0/2] Fix output reflow on hot-unplug

[Pekka Paalanen]

From: Pekka Paalanen 

Hi,

see the second patch for the actual issue. The first patch fixes a bug
that went unnoticed because of the second bug.

This is pretty easy to test. Use the wayland or x11 backends and launch
with two outputs. Check the wl_output x,y with weston-info, close the
left output window, and check weston-info again. The remaining output
should be at x=0, y=0, but instead it was x = 2 * old_x.


Thanks,
pq

Pekka Paalanen (2):
  desktop-shell: fix output removal for background/panel
  libweston: fix output reflow on removal

 clients/desktop-shell.c | 37 -
 libweston/compositor.c  |  2 +-
 2 files changed, 25 insertions(+), 14 deletions(-)

-- 
2.16.4

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

[PATCH weston 1/2] desktop-shell: fix output removal for background/panel

[Pekka Paalanen]

From: Pekka Paalanen 

When the compositor has multiple outputs (not clones) and one of them is
removed, the ones remaining to the right will be moved to close the gap.
Because reflowing the remaining outputs happens before removing the
wl_output global, we get the new output x,y before the removal. This
causes us to consider the remaining output immediately to the right of
the removed output to be a clone of the removed output whose x,y don't
get updated. That will then hit the two assertions this patch removes.

The reason the assertions were not actually hit is because of a
compositor bug which moved the remaining outputs in the wrong direction.
The next patch will fix the reflow, so we need this patch first to avoid
the asserts.

Remove the assertions and hand over the background and panel if the
"clone" does not already have them. If the clone already has them, we
destroy the unnecessary background and panel.

Signed-off-by: Pekka Paalanen 
---
 clients/desktop-shell.c | 37 -
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 6d19d029..fcc0b657 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1337,19 +1337,30 @@ output_remove(struct desktop *desktop, struct output 
*output)
}
 
if (rep) {
-   /* If found, hand over the background and panel so they don't
-* get destroyed. */
-   assert(!rep->background);
-   assert(!rep->panel);
-
-   rep->background = output->background;
-   output->background = NULL;
-   rep->background->owner = rep;
-
-   rep->panel = output->panel;
-   output->panel = NULL;
-   if (rep->panel)
-   rep->panel->owner = rep;
+   /* If found and it does not already have a background or panel,
+* hand over the background and panel so they don't get
+* destroyed.
+*
+* We never create multiple backgrounds or panels for clones,
+* but if the compositor moves outputs, a pair of wl_outputs
+* might become "clones". This may happen temporarily when
+* an output is about to be removed and the rest are reflowed.
+* In this case it is correct to let the background/panel be
+* destroyed.
+*/
+
+   if (!rep->background) {
+   rep->background = output->background;
+   output->background = NULL;
+   rep->background->owner = rep;
+   }
+
+   if (!rep->panel) {
+   rep->panel = output->panel;
+   output->panel = NULL;
+   if (rep->panel)
+   rep->panel->owner = rep;
+   }
}
 
output_destroy(output);
-- 
2.16.4

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

Re: Session suspension and restoration protocol

[Simon McVittie]

On Wed, 20 Jun 2018 at 21:26:26 +0200, Roman Gilg wrote:
> On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie  wrote:
> > When we discussed this on #gnome-hackers we were talking about doing
> > restoration by passing the restored session ID as platform_data to the
> > Activate method defined by
> > https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus
> > which would mean that for trivial/stateless apps, it would be enough to
> > ignore it and just start up, which DBusActivatable implementations like
> > GtkApplication will already do. Is there a reason why you've opted to define
> > a new method instead?
> 
> I think it makes sense to have a separate method, because a client can
> dbus-activate with the protocol any dbus-activatable app. Imagine a
> rogue client tries to dbus-activate an app, which is not written to
> use this extension but provides the Activate method.

A rogue client, you say. What's the threat model here?

If the threat model is that clients can be malicious, it seems like the
worst-case is that a malicious client can tell the compositor to trigger
activation of an app that, when launched, does something undesirable
or dangerous without further user interaction. Are you relying on an
assumption that apps that do something undesirable or dangerous on
activation will never implement the state-restore protocol?

If the threat model is that clients can be malicious, then it seems
a bad idea to have an Exec= fallback code path, because running an
executable (with unexpected command-line arguments that it might
misinterpret or ignore) seems like just as plausible a way to do bad
things as calling Activate() on it.

I think the real problem here is that the compositor or session manager
doesn't necessarily have a secure way to associate Wayland clients with
their D-Bus identities. Perhaps this means the protocol used to register
for this service should be based on D-Bus, not Wayland? Systems for
running untrusted or partially-trusted apps already need to "firewall"
access to the D-Bus session bus (for example Flatpak knows how to
do this), and in particular they need to make sure that untrusted apps
can't own well-known names other than their own.

If the register_session_suspension request was replaced by a
RegisterSessionSuspension() D-Bus method, then the implementation of
that method in the compositor or session manager could check that the
method call sender (unique name) matches the current owner of the D-Bus
well-known name corresponding to the requested desktop ID. For example,
if it gets a method call from unique name ":1.123" asking it to restore
desktop_id = "org.gnome.Builder.desktop" later, then it could ask the
dbus-daemon who currently owns "org.gnome.Builder", and only continue to
process the method call if the answer is ":1.123".

I can't think of an equivalent for that setup that would be suitable for
an Exec= fallback path.

> In this sense the protocol should be extended with the information
> that the Restore method should also return an error, if the
> restoration id is not found.

In case you're not aware, D-Bus method calls can always raise an
error, which behaves a bit like a C++/Java/Python exception, and
happens instead of returning their documented "out" parameters (if
any). Erorrs have a mandatory machine-readable *name* and an optional
(but strongly recommended) human-readable *message*. If a particular
error situation is an important part of your protocol design, you
can document a specific error name to be used in that situation, for
example "org.freedesktop.SessionSuspension1.Error.RestoreNotImplemented".
Callers must be robust against error names that they do not understand,
which they should treat as meaning "there was some other error".

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

Re: [PATCH] client: Allow send error recovery without an abort

[Pekka Paalanen]

On Tue, 19 Jun 2018 21:06:15 -0700
Lloyd Pique  wrote:

> I did think of one more option to avoid the dup() abort.
> 
> - Open MAX_FDS_OUT to reserve a pool of fds (open /dev/nul or something
> innocuous)
> - Whenever the core client needs to dup a caller fd, use dup2/dup3 on an fd
> in the pool
> - Whenever the core client is done with the caller fd, use dup2/dup3 to
> release it and point it back at something innocuous.

Sorry, I don't think we are that desperate. :-)

I think we have established there probably isn't any reasonable way to
recover from dup() failure without disconnecting.

> Separately, as my client is a service level nested server, I could
> effectively configure it with setrlimit, and bump up the pool to the 1000
> fds to fill the entire ring buffer. That would work, but may not be a
> general solution for simpler clients, especially since the default limit is
> only 1024.

Very rare client would even be sending tons of fds. Usually a client
has few buffers per wl_surface, and fds are sent when creating
wl_buffers but not when re-using them. A window being continuously
resized would be the usual cause of sending fds constantly since buffer
resize often implies allocation. Even then, the rate would be limited
to one buffer per display refresh and surface for a well-behaved client.

Outside buffers, the use of fds is very rare in general. This is why
you are the first to seriously hit and investigate this problem. You
have probably the first app that is hitting the 28 fds limit, at least
I don't recall hearing about such before.

Therefore I claim that most clients return to their main event loop to
sleep well before they have queued even a dozen fds. Your Wayland
client could have its rlimit raised, and sounds like it should have in
any case. This is why I think the dup() failure does not really need a
recovery mechanism that would keep the Wayland connection alive.


Thanks,
pq

> If blocking is out, maybe the only thing I can do is add an option to
> configure the amount of fd's the core will reserve/enqueue? However, while
> it isn't a dangerous option, it also wouldn't just necessarily with a
> default of 28, without the developer knowing what larger value to set.
> 
> (To make it clear, I'm thinking through this final issue with the fd limit
> as best I can before I go ahead and revise my patch)
> 
> - Lloyd



pgpSerXt_JLaR.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] client: Allow send error recovery without an abort

[Pekka Paalanen]

On Tue, 19 Jun 2018 13:23:44 -0700
Lloyd Pique  wrote:

> Hi Pekka,
> 
> - ABI to query a "flush recommended" flag; This flag would be set when
> >   the soft-buffer is at least half-full, and cleared when it drops
> >   to... below half? empty?  
> 
> 
> This sounds reasonable, I'm happy to incorporate this first bit into my
> patch, but .
> 
> 
> > - When a client is doing lots of request sending without returning to
> >   its main loop which would call wl_display_flush() anyway, it can
> >   query the flag to see if it needs to flush.  
> 
> 
> > - If flush ever fails, stop all request sending, poll for writable and
> >   try again. How to do this is left for the application. Most
> >   importantly, the application could set some state and return to its
> >   main event loop to do other stuff in the mean while.
> >  
> 
> > You're right that this wouldn't help an application that sends requests
> > from multiple threads a lot. They would need to be checking the flag
> > practically for every few requests, but at least that would be cheaper
> > than calling wl_display_flush() outright.
> >  
> 
> 
> [...]
> 
> 
> 
> > Can you think of any way to recover from dupfd failure without
> > disconnecting?  
> 
> 
> There are only two ways I can think of to recover from the dupfd failure:
> 
> 1) Don't dup(). The purpose of it is to enqueue fds in the fds_out ring
> buffer across multiple send calls. If instead a send call that had fd's did
> an immediate flush, there would be no need for the dupe. The downside is
> that the caller doesn't get a chance to do its wl_display_flush() under
> conditions where it can do a wait.

The purpose of dup() is to allow the program close() the fd
immediately after calling a message sending function. We also do not
want to flush on every request, that's the whole reason a buffer even
exists.

Or do you propose that dup() failure would trigger a flush and retry?

A flush could free more fd space, but yeah, implicit flushes always
have the issue with failing.

> 2) Add a new "send-error" flag, breaking existing code, and requiring the
> client to check after every send call and somehow do its own recovery and
> retry the send calls.
> 
> I don't think anyone would want the second, except maybe as some
> fundamental redesign that new clients were written anew for.

Yes, there is a reason why message sending functions do not return a
status. It would be too hard to deal with aside from mostly ignoring it.

> The first might actually be acceptable to me in practice.
> 
> Assuming the one wl_abort() after the call to wl_closure_send() becomes a
> display_fatal_error(), and an EAGAIN here is converted to an EPIPE or other
> fatal error, I don't think I will see EAGAIN very often if ever.
> 
> As you said, the kernel buffers are large. I don't know if that also
> applies to fd's, but I would expect it has much larger limits there too.
> 
> But that is based on what I'm think I'm running into. Another client might
> not want that.
> 
> I'm out of immediate ideas. What do you think?

Let's deal with one thing at a time. I'd suggest getting the full
fds_out capacity into use first, and see where that gets us. The second
step would be the "flush recommended" API.

If dup() becomes the next problem, we'll think about that then.
However, I'm still not convinced that dup() failure should be
recoverable without disconnecting. A program shouldn't be operating
near the fd space cap, like it shouldn't be operating near stack
exhaustion either. It comes down to what we would consider reasonable
in both behaviour and error recovery.


Thanks,
pq


pgp_KVekAOlTB.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] client: Allow send error recovery without an abort

[Pekka Paalanen]

On Tue, 19 Jun 2018 12:10:36 -0700
Lloyd Pique  wrote:

> Hi Pekka,
> 
> On Tue, Jun 19, 2018 at 5:12 AM Pekka Paalanen  wrote:
> 

> > If I'm reading the code right, MAX_FDS_OUT is only a limit for a single
> > sendmsg() call. The fds_out buffer is capable of holding 1k fds.
> >  
> 
> > We have 4kB message data buffer (what I've been calling the
> > soft-buffer, as opposed to in-kernel buffers). A minimal request to
> > carry an fd would be header (8B) plus fd (4B), so that's 12B. That
> > makes at most 341 fds until the soft-buffer is full. That should well
> > fit into the 1k fds that fds_out can hold.
> >
> > One could have more fds in a single request. Let's say four. The
> > request size becomes 24B carrying 4 fds. That makes 680 fds for a full
> > soft-buffer. Should still be fine.  
> 
> 
> The limit is both the maximum amount per sendmsg() call, as well as the
> maximum amount that can be sent by a single send request.
> 
> The fd's are added once at a time by a call to wl_connection_put_fd(),
> which forces a flush once the limit is reached. Those calls are made by
> copy_fds_to_connection(), called once per message send from
> wl_closure_send().

Hi,

ah, so there is an artificial limit there as well. I missed that. So
that is what prevents the fds from accumulating in fds_out indefinitely.

> On a flush (forced or not), the fd's are closed by close_fds(), which then
> advances the tail to the head, emptying the ring buffer again.
> 
> That the output fd butter is over-large at 4k just allows much of the ring
> buffer code to be reused. It will never actually hold 1024 fds enqueued for
> output though.
> 
> (The input fd buffer may allow 1k fd's. I did not examine that carefully to
> be sure).
> 
> I think this limit is still a problem. I could change it to actually allow
> 1k fd's to be queued up, but then that will make the dup() more likely to
> fail (more in the other reply).

Yes, upping it to 1k for real would be my suggestion. I think it should
be large enough to accommodate any amount of fds so that the limiting
factor will be the soft-buffer size.

I think the 4 fds in a minimal message is a reasonable upper limit. It
is very rare to find even two fds in a single message, because such a
message cannot be sent at all without all the declared fds. There is no
way to send a "null" fd, so protocol design should favour one message
per fd when the number of fds is variable.


> > However, wl_connection_flush() attempts to write out at most
> > MAX_FDS_OUT fds at a time, but all of the message data. OTOH, one
> > cannot even try to flush out fds without any message data, IIRC
> > sendmsg() doesn't support that. So it can run out of message data while
> > fds accumulate and finally fill fds_out up, causing irrecoverable
> > failure.
> >
> > Do your observations support this theory?
> >  
> 
> I haven't observed a problem case like that. Any normal individual request
> will probably only use a few fd's, and I don't think there is a way for a
> request to not carry some non-fd data.
> 
> I can imagine someone creating a new protocol message that does take more
> than 28 fd's in a request, where that would then fail to flush if there
> were no other normal message data also already queued up. But that seems a
> very abnormal use. wl_closure_marshal() would be the best place for a check
> (it already checks for null objects -- see "goto err_null"), and I didn't
> find other bound check on the number of fd's in a request on a quick look
> through the code.
> 
> But I'll study the code a bit more in case there is some subtlety that
> escapes me.

Yeah, there probably isn't any upper limit coded for number of fds in a
single message, or number of arguments, aside from a generic send
failure.

I believe it would be good to introduce an upper limit of maybe 4 fds
per message. Or at least suggest it. It should be done in both
wayland-scanner and libwayland.

> > It seems we should somehow flush less message data so that we can call
> > sendmsg() enough times to handle all the fds and avoid them piling up.
> > But if we do so, we must be very careful with any potential assumptions
> > on receiving side on the ordering between message data and related fds.
> >  
> 
> I expect that the receiving code will just pull the next fd out of the
> fds_in ring buffer when turning the messages back into wl_closures for each
> message, as it realizes an fd is needed for any argument.
> 
> But I haven't looked at the code. Another thing I will check to be safe.

That is my understanding as well, which means that fds must arrive with
or before the corresponding other message data. They cannot arrive
later. It should be ok to lift this restriction if necessary, but maybe
it's better to make sure data cannot arrive before fds.


Thanks,
pq

> > Even the author of the client would usually not know. It would make a
> > very hard API to use correctly.
> >  
> 
> Ok, I won't introduce anything like that.
> 
> 
> > My 

LayerManagerControl dump surface command is not working with gstreamer pipeline.

[Ikshwaku Chauhan]

Dear All,



We are facing issue when we are trying to take the surface dump for a video
running on the display. we are observing the following behaviors:



1. When we run a video file through gstreamer
 pipeline then, not able to take the
surface dump with LayerManagerControl command.

Command used : LayerManagerControl dump surface 90 to surface.png  Only
getting a dot when we zoom in the generated image file.



2. But able to get the screen dump for video playback

Command used: LayerManagerControl dump screen 0 to screen.png. Getting the
proper screen dump.



3. When we run EGLWLMockNavigation, then both surface and screen dumps are
working properly.



We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
on TI's Soc.

Could anyone tell us what might be the issue, or we are missing any
configuration?



Thanks in advance.



Best Regards,

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

Re: EXT: [PATCH weston 0/1] Allow forcing outputs on

[Tomasz Olszak]

To reproduce the issue:

weston.ini:
[output]
name=HDMI-A-2
mode=74.50  1280 1344 1472 1664  720 723 728 748 -hsync +vsync
force-on=true

Connect screen to HDMI-A-1 and start weston. You get weston info:
interface: 'wl_output', version: 3, name: 13
   x: 0, y: 0, scale: 1,
   physical_width: 410 mm, physical_height: 230 mm,
   make: 'PHL', model: 'Philips 196V',
   subpixel_orientation: unknown, output_transform: normal,
   mode:
...
interface: 'wl_output', version: 3, name: 14
   x: 1366, y: 0, scale: 1,
   physical_width: 0 mm, physical_height: 0 mm,
   make: 'unknown', model: 'unknown',
   subpixel_orientation: unknown, output_transform: normal,
   mode:
   width: 1280 px, height: 720 px, refresh: 59.855 Hz,
   flags: current


Now disconnect HDMI-A-1:
interface: 'wl_output', version: 3, name: 14
   x: 2732, y: 0, scale: 1,
   physical_width: 0 mm, physical_height: 0 mm,
   make: 'unknown', model: 'unknown',
   subpixel_orientation: unknown, output_transform: normal,
   mode:
   width: 1280 px, height: 720 px, refresh: 59.855 Hz,
   flags: current

That seems like a bug.

2018-06-20 14:14 GMT+02:00 Pekka Paalanen :
> On Tue, 19 Jun 2018 14:07:08 +0200
> Tomasz Olszak  wrote:
>
>> Hi,
>>
>> While I was testing this patch I ended up with:
>>
>> interface: 'wl_output', version: 3, name: 14
>> x: 2732, y: 0, scale: 1,
>>
>>
>> This happened when I used force-on on second "HDMI-A-2" display.
>>
>> When I used force-on on HDMI-A-1 everything worked as expected. anx x=y=0
>
> Hi,
>
> I did a quick test on a device with two connectors, both unplugged, and
> forcing each one on at a time. I didn't see the issue. I'll try to see
> how it could still happen. Would you have a weston log of the failure
> case along with full weston-info output?
>
>
> Thanks,
> pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Dual display in clone mode or extended mode with Weston

[Pekka Paalanen]

On Wed, 13 Jun 2018 17:40:59 +0530
Ashvini Deshmukh  wrote:

> Hello All,
> 
> I have read queries for dual display on freedesktop.org
> 
> I need your help in the same context.
> 
> Currently we are creating one application to support multiple displays with
> Wayland.

Hi,

you are developing an application, ok. I assume that means a Wayland
client specifically.

> We are unaware that one compositor will be sufficient for dual display.

Sorry, I don't understand. Are you asking whether one Wayland
compositor could driver multiple displays? Yes, they can in general.
Capabilities will vary between different compositor implementations.

> We need to know about how virtual framebuffer is created per display.

As an application developer, why would you care about that? That is a
compositor internal implementation detail.

Why virtual? Real outputs do not have virtual framebuffers, they have
real framebuffers as far as the compositor is concerned.

> As DRM supports only one compositor,
> How to display same content on second display OR can we have different user
> events on second display monitor.

What do you mean?

If a Wayland compositor supports and has been configured to show the
same content on multiple displays, then it will do that. From a Wayland
client perspective, there is nothing you need to do to have your
window show up on cloned displays compared to a single display case.

By user events, do you mean input events?

It is certainly possible to write a compositor that dedicates one set
of input devices for one display and another set of input devices for
the other display.

Applications are expected to support multiple wl_seat globals (similar
to multi-pointer X in essence). There is nothing else they would need
to specifically support for a compositor that had multiple outputs,
cloned outputs, or divided input devices in any arbitrary way.

I did not understand your requirements well enough to say how well
Weston would work for you.

For example, Weston currently does not support multiple KMS devices,
but it does support multiple displays on a single KMS device. Support
for multiple KMS devices is desired in Weston though, so maybe it will
in the future.

Weston's clone mode is currently limited to sharing a CRTC between all
displays, assuming someone reviews the final patch needed to configure
it. Support for this configuration does not seem to be common among PC
graphics hardware, embedded boards may have better chances.


Thanks,
pq


pgpx9wsvsSWC4.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: how to handle the last_error of wl_display

[Pekka Paalanen]

On Thu, 21 Jun 2018 11:59:57 +0800
zou lan  wrote:

> Hi pekka
> 
> I find the last_error is caused by
> wl_display_flush()-->wl_connection_flush(). The sendmsg() return fail.
> 
> Many applications write code like this:
> 
> redraw()
> {
> wl_surface_commit();
> wl_display_sync();
> wl_display_flush();
> }
> 
> while (1) {
> redraw();
> }
> 

Yes, this is a typical example of an essentially broken application.

> The code will block to wait buffer release event  if there is no free
> buffer. But if display->last_error happen, the wl_display_dispatch_queue()
> fail too. Does the application use the wl_display_flush() right?

The bug is more likely that the application is flooding the compositor,
too rarely waiting for anything. This has high chances of filling up
both the kernel socket buffer and libwayland-client's send buffer,
which is fatal to the connection, leading to at least a disconnect. It
can also lead to abort() currently, though there is interest to fix
that to just disconnect.

The example you gave does not actually block on anything. Are you sure
your application is regularly waiting for compositor events?

You might also want to read the recent thread:
https://lists.freedesktop.org/archives/wayland-devel/2018-June/038437.html

The client is responsible for checking the return value of
wl_display_flush(), and poll the Wayland fd for writable if the
function indicates an EAGAIN condition. While flush fails, the client
must restrain from sending any further requests as those may overflow
the buffers and cause a disconnect.


Thanks,
pq


pgppok6oW3g4J.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel