[ANNOUNCE] libinput 1.10.1

[Peter Hutterer]

libinput 1.10.1 is now available. This release fixes three crashers, one
during tapping, two on startup/resume when the device node or seat weren't
assigned correctly. You're strongly advised to update just to get those
fixes.

Three fixes to the libinput measure* tools as well, they should now work as
intended. And fixes for the 'libinput-debug-events' and
'libinput-list-devices' compat scripts that could lead to the wrong
bindir/libdir being used.

Maxin B. John (1):
  libinput-measure-touchpad-tap: use /usr/bin/env to invoke python3

Peter Hutterer (7):
  evdev: fail before open_restricted if the devnode doesn't exist
  evdev: add a quirk to disable debouncing on the MS Nano Transcievers
  udev: fix segfault when resuming before assigning a seat
  touchpad: only begin fake touches when we have at least one finger down
  tools: fix option parsing in libinput measure
  tools: fix inverse up/down threshold handling in measure touch-size
  libinput 1.10.1

Quentin Glidic (2):
  meson: Fix bindir usage in install script
  meson: Fix absolute libdir case in install script

git tag: 1.10.1

https://www.freedesktop.org/software/libinput/libinput-1.10.1.tar.xz
MD5:  b3d009f36691cb9c340a18109df837ef  libinput-1.10.1.tar.xz
SHA1: 1b2a8970960998c5798b0ecba07dcaab2b340084  libinput-1.10.1.tar.xz
SHA256: 877522d76575e1945c7b3a9eb92cab90d5ad0379c4ef0dbe13054e489d4c6665  
libinput-1.10.1.tar.xz
SHA512: 
69e7cd12f3d686d1b09afd93fe072ddd6f8c9a1f04c0a651c7dd02c5a20b3f8163c5b787b41bf3ae91db0da7d3e2958d315d6c9a2875259c62b0d290ac89d1fb
  libinput-1.10.1.tar.xz
PGP:  https://www.freedesktop.org/software/libinput/libinput-1.10.1.tar.xz.sig



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

Re: [PATCH] unstable: add xdg-session-management protocol

[Markus Ongyerth]

On 2018/2月/26 08:58, Mike Blumenkrantz wrote:
> for a variety of cases it's desirable to have a method for negotiating
> the restoration of previously-used states for a client's windows. this
> helps for e.g., a compositor/client crashing (definitely not due to
> bugs) or a backgrounded client deciding to temporarily destroy its
> surfaces in order to conserve resources

What's the intended workflow for the background client?
The protocol states that the session data should be removed on 
xdg_toplevel.destroy, which would not allow clients to reuse state after they 
gracefully exited, or "exited" partially (closing some windows, not the entire 
connection).

> 
> this protocol adds a method for managing such negotiation and is loosely
> based on the Enlightenment "session recovery" protocol which has been
> implemented and functional for roughly two years
> 
> some further reading: https://blogs.s-osg.org/recovery-journey-discovery/
> 
> Signed-off-by: Mike Blumenkrantz 
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am|   1 +
>  unstable/xdg-session-management/README |   4 +
>  .../xdg-session-management-unstable-v1.xml | 181 
> +
>  3 files changed, 186 insertions(+)
>  create mode 100644 unstable/xdg-session-management/README
>  create mode 100644 
> unstable/xdg-session-management/xdg-session-management-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..2b75114 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -17,6 +17,7 @@ unstable_protocols =
> \
>   
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  \
>   unstable/xdg-output/xdg-output-unstable-v1.xml  
> \
>   unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> + unstable/xdg-session-management/xdg-session-management-unstable-v1.xml  
> \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xdg-session-management/README 
> b/unstable/xdg-session-management/README
> new file mode 100644
> index 000..7bff401
> --- /dev/null
> +++ b/unstable/xdg-session-management/README
> @@ -0,0 +1,4 @@
> +xdg session management protocol
> +
> +Maintainers:
> +Mike Blumenkrantz 
> diff --git 
> a/unstable/xdg-session-management/xdg-session-management-unstable-v1.xml 
> b/unstable/xdg-session-management/xdg-session-management-unstable-v1.xml
> new file mode 100644
> index 000..0c36c16
> --- /dev/null
> +++ b/unstable/xdg-session-management/xdg-session-management-unstable-v1.xml
> @@ -0,0 +1,181 @@
> +
> +
> +  
> +Copyright 2018 Mike Blumenkrantz
> +Copyright 2018 Samsung Electronics Co., Ltd
> +Copyright 2018 Red Hat Inc.
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +  
> +Warning! The protocol described in this file is experimental and backward
> +incompatible changes may be made. Backward compatible changes may be 
> added
> +together with the corresponding interface version bump. Backward
> +incompatible changes are done by bumping the version number in the 
> protocol
> +and interface names and resetting the interface version. Once the 
> protocol
> +is to be declared stable, the 'z' prefix and the version number in the
> +protocol and interface names are removed and the interface version 
> number is
> +reset.
> +  
> +  
> +
> +  The xdg_session_manager interface defines base requests for creating 
> and
> +  managing a session for an application. Sessions persist across 
> application
> +  and compositor restarts unless explicitly destroyed. A session is 
> created
> + 

Re: [PATCH 1/2] xdg-shell: move maximized state difnition together

[Mike Blumenkrantz]

With typos corrected:

Reviewed-By: Mike Blumenkrantz 

On Tue, Feb 27, 2018 at 8:23 AM Silvan Jegen  wrote:

> Hi
>
> One typo corrected below.
>
> On Tue, Feb 27, 2018 at 1:24 PM,   wrote:
> > From: Markus Ongyerth 
> >
> > The xdg-shell documentation had part of the maximized state render
> > implications in the `set_maximized` request documentation, not the
> > actual state.
> > This moves the relevant lines into the state description.
> >
> > Signed-off-by: Markus Ongyerth 
> > ---
> >  stable/xdg-shell/xdg-shell.xml | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/stable/xdg-shell/xdg-shell.xml
> b/stable/xdg-shell/xdg-shell.xml
> > index d524ea9..0b21364 100644
> > --- a/stable/xdg-shell/xdg-shell.xml
> > +++ b/stable/xdg-shell/xdg-shell.xml
> > @@ -724,6 +724,9 @@
> > 
> >   The surface is maximized. The window geometry specified in the
> configure
> >   event must be obeyed by the client.
> > +
> > + The client should drawy without shadow or other
>
> s/drawy/draw/
>
>
> Cheers,
>
> Silvan
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] xdg-shell: Make sure wording reflects expectations

[Mike Blumenkrantz]

Hi,

This seems like a reasonable direction for a change, though I would suggest
a slightly different approach. For all cases where it reads "the compositor
will respond by emitting", instead change to something like "if the
compositor decides to apply this state change then it will respond by
emitting". Such change clarifies the mechanism, as your patch intends,
while also preserving the requirement that the compositor emits a state and
geometry in a configure event in order to acknowledge requests for state
changes.

Regards,
Mike

On Tue, Feb 27, 2018 at 7:25 AM  wrote:

> From: Markus Ongyerth 
>
> The wording in xdg-shell `set_*` requests implies the compositor *will*
> react to requests.
> This would give clients the control over its state, while they should
> just be able to kindly ask for a state change.
> This makes sure the language reflects that and changes "will" to "may"
> in the relevant requests description.
>
> Signed-off-by: Markus Ongyerth 
> ---
>  stable/xdg-shell/xdg-shell.xml | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/stable/xdg-shell/xdg-shell.xml
> b/stable/xdg-shell/xdg-shell.xml
> index 0b21364..c619634 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -842,7 +842,7 @@
> Maximize the surface.
>
> After requesting that the surface should be maximized, the
> compositor
> -   will respond by emitting a configure event with the "maximized"
> state
> +   may respond by emitting a configure event with the "maximized"
> state
> and the required window geometry. The client should then update its
> content, drawing it in a maximized state. The client must also
> acknowledge the configure when committing the new content (see
> @@ -852,11 +852,11 @@
> surface, for example which output and what region of the screen
> should
> be used.
>
> -   If the surface was already maximized, the compositor will still
> emit
> +   If the surface was already maximized, the compositor will emit
> a configure event with the "maximized" state.
>
> If the surface is in a fullscreen state, this request has no direct
> -   effect. It will alter the state the surface is returned to when
> +   effect. It may alter the state the surface is returned to when
> unmaximized if not overridden by the compositor.
>
>  
> @@ -866,7 +866,7 @@
> Unmaximize the surface.
>
> After requesting that the surface should be unmaximized, the
> compositor
> -   will respond by emitting a configure event without the "maximized"
> +   may respond by emitting a configure event without the "maximized"
> state. If available, the compositor will include the window
> geometry
> dimensions the window had prior to being maximized in the configure
> event. The client must then update its content, drawing it in a
> @@ -878,11 +878,11 @@
> unmaximized; usually the position the surface had before
> maximizing, if
> applicable.
>
> -   If the surface was already not maximized, the compositor will still
> +   If the surface was already not maximized, the compositor will
> emit a configure event without the "maximized" state.
>
> If the surface is in a fullscreen state, this request has no direct
> -   effect. It will alter the state the surface is returned to when
> +   effect. It may alter the state the surface is returned to when
> unmaximized if not overridden by the compositor.
>
>  
> @@ -892,7 +892,7 @@
> Make the surface fullscreen.
>
> After requesting that the surface should be fullscreened, the
> -   compositor will respond by emitting a configure event with the
> +   compositor may respond by emitting a configure event with the
> "fullscreen" state and the fullscreen window geometry. The client
> must
> also acknowledge the configure when committing the new content (see
> ack_configure).
> @@ -921,7 +921,7 @@
> Make the surface no longer fullscreen.
>
> After requesting that the surface should be unfullscreened, the
> -   compositor will respond by emitting a configure event without the
> +   compositor may respond by emitting a configure event without the
> "fullscreen" state.
>
> Making a surface unfullscreen sets states for the surface based on
> the following:
> --
> 2.16.2
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] build: honour libinput header location

[Emil Velikov]

From: Jan Engelhardt 

Add the respective CFLAGS to the build, otherwise the build will error
out as seen below.

src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory

[Emil Velikov: polish commit message]
Signed-off-by: Emil Velikov 
---
Jan, don't be shy to send patches upstream. Devs. won't bite... most of
the time ;-)
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index b5c29c04..8de40e51 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -43,7 +43,8 @@ AM_CPPFLAGS = \
-I$(top_builddir)/protocol  \
-DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
-DLIBEXECDIR='"$(libexecdir)"'  \
-   -DBINDIR='"$(bindir)"'
+   -DBINDIR='"$(bindir)"' \
+   $(LIBINPUT_BACKEND_CFLAGS)
 
 CLEANFILES = weston.ini\
ivi-shell/weston.ini\
-- 
2.16.0

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

Re: [PATCH 1/2] xdg-shell: move maximized state difnition together

[Silvan Jegen]

Hi

One typo corrected below.

On Tue, Feb 27, 2018 at 1:24 PM,   wrote:
> From: Markus Ongyerth 
>
> The xdg-shell documentation had part of the maximized state render
> implications in the `set_maximized` request documentation, not the
> actual state.
> This moves the relevant lines into the state description.
>
> Signed-off-by: Markus Ongyerth 
> ---
>  stable/xdg-shell/xdg-shell.xml | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index d524ea9..0b21364 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -724,6 +724,9 @@
> 
>   The surface is maximized. The window geometry specified in the 
> configure
>   event must be obeyed by the client.
> +
> + The client should drawy without shadow or other

s/drawy/draw/


Cheers,

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

Re: [PATCH wayland] connection: Print the content of arrays in closures

[Pekka Paalanen]

On Tue, 27 Feb 2018 12:39:59 +
Daniel Stone  wrote:

> Hi,
> 
> On 4 December 2017 at 08:08, Pekka Paalanen  wrote:
> > On Fri, 1 Dec 2017 17:08:15 + Daniel Stone  
> > wrote:  
> >> On 10 July 2017 at 19:28, Emmanuel Gil Peyrot
> >>  wrote:  
> >> > The current behaviour when WAYLAND_DEBUG is set is to print “array”,
> >> > which is quite unhelpful.
> >> >
> >> > This patch prints a list of the bytes present in the array.  It doesn’t
> >> > try to interpret it as uint32_t or anything, leaving that to the reader
> >> > because this information isn’t present in the protocol description.  
> >>
> >> To be honest, I'm not really wild about this one. All the array users
> >> I know of (key/button, xdg surface states) are uint32_t. I'd prefer to
> >> add a pretty-printing hint to the protocol - this could specify how to
> >> interpret arrays, and also scratch my long-standing itch of printing
> >> uints with %x rather than %u when it makes sense to ...  
> >
> > just a side note, if you start working on that, do also think of
> > bindings for (strongly) typed languages. ISTR requests to add type
> > information so that better bindings could be generated, and the
> > problem was where to stop defining the type system. I'm pretty sure if
> > printing hints are added, people will use them for bindings, whether we
> > wanted or not.  
> 
> Here's a strawman.
> 
> Since libwayland allows the signature to contain unknown/new values,
> as a hint, optionally allow the 'a' type to be preceded by:
>   - one character of either 'X', 'I', or 'U', indicating respectively
> that the value should be pretty-printed as hexidecimal / signed int /
> unsigned int, followed by
>   - either '1', '2' or '4' to indicate the byte width of the type
> (respectively 8/16/32 bits)

What about 64-bit integers, and float and double? I think the
touchscreen calibration extension will use an array of doubles.

> Similarly, allow the 'u' type to be preceded by 'X' indicating that
> the value should be pretty-printed in hex.

Sounds ok to me.

An alternative proposal is to just print whatever format that could be
fed into od or hexdump, which would avoid the feature creep in
libwayland and message signatures.


Thanks,
pq


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

Re: [PATCH wayland] connection: Print the content of arrays in closures

[Daniel Stone]

Hi,

On 4 December 2017 at 08:08, Pekka Paalanen  wrote:
> On Fri, 1 Dec 2017 17:08:15 + Daniel Stone  wrote:
>> On 10 July 2017 at 19:28, Emmanuel Gil Peyrot
>>  wrote:
>> > The current behaviour when WAYLAND_DEBUG is set is to print “array”,
>> > which is quite unhelpful.
>> >
>> > This patch prints a list of the bytes present in the array.  It doesn’t
>> > try to interpret it as uint32_t or anything, leaving that to the reader
>> > because this information isn’t present in the protocol description.
>>
>> To be honest, I'm not really wild about this one. All the array users
>> I know of (key/button, xdg surface states) are uint32_t. I'd prefer to
>> add a pretty-printing hint to the protocol - this could specify how to
>> interpret arrays, and also scratch my long-standing itch of printing
>> uints with %x rather than %u when it makes sense to ...
>
> just a side note, if you start working on that, do also think of
> bindings for (strongly) typed languages. ISTR requests to add type
> information so that better bindings could be generated, and the
> problem was where to stop defining the type system. I'm pretty sure if
> printing hints are added, people will use them for bindings, whether we
> wanted or not.

Here's a strawman.

Since libwayland allows the signature to contain unknown/new values,
as a hint, optionally allow the 'a' type to be preceded by:
  - one character of either 'X', 'I', or 'U', indicating respectively
that the value should be pretty-printed as hexidecimal / signed int /
unsigned int, followed by
  - either '1', '2' or '4' to indicate the byte width of the type
(respectively 8/16/32 bits)

Similarly, allow the 'u' type to be preceded by 'X' indicating that
the value should be pretty-printed in hex.

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

[PATCH 1/2] xdg-shell: move maximized state difnition together

[wl]

From: Markus Ongyerth 

The xdg-shell documentation had part of the maximized state render
implications in the `set_maximized` request documentation, not the
actual state.
This moves the relevant lines into the state description.

Signed-off-by: Markus Ongyerth 
---
 stable/xdg-shell/xdg-shell.xml | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..0b21364 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -724,6 +724,9 @@

  The surface is maximized. The window geometry specified in the 
configure
  event must be obeyed by the client.
+
+ The client should drawy without shadow or other
+ decoration outside of the window geometry.

   
   
@@ -841,8 +844,7 @@
After requesting that the surface should be maximized, the compositor
will respond by emitting a configure event with the "maximized" state
and the required window geometry. The client should then update its
-   content, drawing it in a maximized state, i.e. without shadow or other
-   decoration outside of the window geometry. The client must also
+   content, drawing it in a maximized state. The client must also
acknowledge the configure when committing the new content (see
ack_configure).
 
-- 
2.16.2

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

[PATCH 2/2] xdg-shell: Make sure wording reflects expectations

[wl]

From: Markus Ongyerth 

The wording in xdg-shell `set_*` requests implies the compositor *will*
react to requests.
This would give clients the control over its state, while they should
just be able to kindly ask for a state change.
This makes sure the language reflects that and changes "will" to "may"
in the relevant requests description.

Signed-off-by: Markus Ongyerth 
---
 stable/xdg-shell/xdg-shell.xml | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 0b21364..c619634 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -842,7 +842,7 @@
Maximize the surface.
 
After requesting that the surface should be maximized, the compositor
-   will respond by emitting a configure event with the "maximized" state
+   may respond by emitting a configure event with the "maximized" state
and the required window geometry. The client should then update its
content, drawing it in a maximized state. The client must also
acknowledge the configure when committing the new content (see
@@ -852,11 +852,11 @@
surface, for example which output and what region of the screen should
be used.
 
-   If the surface was already maximized, the compositor will still emit
+   If the surface was already maximized, the compositor will emit
a configure event with the "maximized" state.
 
If the surface is in a fullscreen state, this request has no direct
-   effect. It will alter the state the surface is returned to when
+   effect. It may alter the state the surface is returned to when
unmaximized if not overridden by the compositor.
   
 
@@ -866,7 +866,7 @@
Unmaximize the surface.
 
After requesting that the surface should be unmaximized, the compositor
-   will respond by emitting a configure event without the "maximized"
+   may respond by emitting a configure event without the "maximized"
state. If available, the compositor will include the window geometry
dimensions the window had prior to being maximized in the configure
event. The client must then update its content, drawing it in a
@@ -878,11 +878,11 @@
unmaximized; usually the position the surface had before maximizing, if
applicable.
 
-   If the surface was already not maximized, the compositor will still
+   If the surface was already not maximized, the compositor will
emit a configure event without the "maximized" state.
 
If the surface is in a fullscreen state, this request has no direct
-   effect. It will alter the state the surface is returned to when
+   effect. It may alter the state the surface is returned to when
unmaximized if not overridden by the compositor.
   
 
@@ -892,7 +892,7 @@
Make the surface fullscreen.
 
After requesting that the surface should be fullscreened, the
-   compositor will respond by emitting a configure event with the
+   compositor may respond by emitting a configure event with the
"fullscreen" state and the fullscreen window geometry. The client must
also acknowledge the configure when committing the new content (see
ack_configure).
@@ -921,7 +921,7 @@
Make the surface no longer fullscreen.
 
After requesting that the surface should be unfullscreened, the
-   compositor will respond by emitting a configure event without the
+   compositor may respond by emitting a configure event without the
"fullscreen" state.
 
Making a surface unfullscreen sets states for the surface based on the 
following:
-- 
2.16.2

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

[PATCH 0/2] Improve wording in xdg-shell

[wl]

From: Markus Ongyerth 

Hi,

this is a small patch series that pulls together the definition of the
maximized state and slightly improves the wording in xdg-shell `set_*` requests
to reflect the amount of control clients have.

Cheers,
ongy

Markus Ongyerth (2):
  xdg-shell: move maximized state difnition together
  xdg-shell: Make sure wording reflects expectations

 stable/xdg-shell/xdg-shell.xml | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

-- 
2.16.2

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

Re: [PATCH weston 1/2 v3] compositor-drm: Add support for DRM lease

[Marius-cristian Vlad]

Hi Philipp, Pekka,

On Thu, 2018-02-22 at 10:29 +0200, Pekka Paalanen wrote:
> On Wed, 21 Feb 2018 17:16:07 +0100
> Philipp Zabel  wrote:
> 
> > Hi Marius,
> > 
> > On Wed, 2018-02-21 at 16:49 +0200, Marius Vlad wrote:
> > > Signed-off-by: Marius Vlad 
> > > ---
> > >  Makefile.am|   2 +
> > >  compositor/main.c  |   9 ++
> > >  configure.ac   |   4 +
> > >  libweston/compositor-drm.c | 272
> > > +
> > >  libweston/compositor.c |   1 +
> > >  libweston/compositor.h |   2 +
> > >  6 files changed, 290 insertions(+)
> > > 
> > > diff --git a/Makefile.am b/Makefile.am
> > > index b5c29c0..439fa73 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -163,6 +163,8 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES
> > > = \
> > >   protocol/viewporter-server-protocol.h   \
> > >   protocol/linux-dmabuf-unstable-v1-protocol.c\
> > >   protocol/linux-dmabuf-unstable-v1-server-protocol.h 
> > >   \
> > > + protocol/drm-lease-unstable-v1-protocol.c   \
> > > + protocol/drm-lease-unstable-v1-server-protocol.h
> > > \
> > >   protocol/relative-pointer-unstable-v1-protocol.c
> > > \
> > >   protocol/relative-pointer-unstable-v1-server-protocol.h 
> > >   \
> > >   protocol/pointer-constraints-unstable-v1-protocol.c 
> > >   \
> > > diff --git a/compositor/main.c b/compositor/main.c
> > > index 18810f2..020553f 100644
> > > --- a/compositor/main.c
> > > +++ b/compositor/main.c
> > > @@ -1092,6 +1092,15 @@ drm_backend_output_configure(struct
> > > wl_listener *listener, void *data)
> > >   api->set_seat(output, seat);
> > >   free(seat);
> > >  
> > > + char *lease;
> > > + weston_config_section_get_string(section, "lease",
> > > , "off");
> > > + if (!strncmp(lease, "on", 2)) {
> > > + output->lease = true;  
> > 
> > Should this be enabled by default for non-desktop outputs?
> > 
> > I suppose this is out of scope for this patchset, but I'd be
> > curious
> > if adding a non_desktop property to struct weston_output would be
> > appropriate.
> 
> That property would belong in struct weston_head instead, introduced
> by
> this series:
> https://patchwork.freedesktop.org/series/32898/
> 
> I also think "leasable" would be orthogonal to "non-desktop" as well.
> "leasable" applies more to the KMS resources, particularly the CRTC,
> for which we don't currently have an object in the DRM-backend, but
> we
> will need one to help with the handling of unused crtcs. "leasable"
> would go well in that object. 


Marking "leasable" an output using "non-desktop" can remove the need to
have a "lease" option in the config file. I see this working nicely
with HMDs. "non-desktop" property can also remove the need to iterate
over all connected connectors and request a lease (or at least the need
to talk to weston). The client still needs to go over each connectors
but this time, it requests the lease directly. 

On the other hand for Auto, the EDID quirk might not be available so 
we still need a method which can tell (hint) which output can be
leased. The configuration file allows a way to control that. (i.e, 
in under no circumstance I want this output to be disabled/leased)

Can a combination of both be more suitable to fit both use-cases?

- Mark "leasable" any "non-desktop" property but also the ones found in
configuration file.

- For the client, if it finds a "non-desktop" property for that
connector it can use it directly, other-wise fall-backs to request a
lease for each connected connector. 



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