[PATCH wayland-protocols v3] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

This new protocol description is a simplification over v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
Reviewed-by: Drew DeVault 
---
This patch introduces an updated text input protocol. The only content
change compared to v2 of the patch is that the cursor can span multiple
characters. This change is meant to accommodate for input methods where
pieces of pre-edit text can be adjusted separately.

To show an example, cursor_begin and cursor_end of preedit_string event
would mark the bounds of the blue highlight in the screenshot [0],
ignoring the vertical line which I've been told is not relevant in
Asian input methods.

This patch also fixes the metadata by correctly attributing Carlos
Garnacho in the commit, and makes the patch apply.

Thanks for the feedback.

Dorota Czaplejewicz

[0] https://i.imgur.com/MpibNVi.png

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 308 +
 2 files changed, 309 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..f5d43e7
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,308 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018 Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the pre-edit and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  have to always point to the first byte of an UTF-8 encoded code point.
+  Lengths are not allowed to contain just a part of an UTF-8 encoded code
+  point.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must perform zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the keyboard focus moves across
+  

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Drew DeVault]

On 2018-04-13  4:59 PM, Jonas Ådahl wrote:
> Neither these need the "set_mode" or "preferred_mode" stuff.

I don't think I'm following. I wonder if you have time to write up a
proposed revision to the patch?

> > Clients have an arbitrary surface in which they can render whatever they
> > want, including decorations. Compositors have an arbitrary surface in
> > which they can render whatever they want, including decorations. The
> > protocol acknowledges that after negotiations either party can do
> > whatever they want, but communicates their choice to each other so they
> > can make more educated decisions.
> 
> Not sure what you mean here. The surface is from the client here only,
> and the client has no wiggle room in the proposed protocol, only the
> compositor.

When I spoke of the compositor "surface" I meant like the GBM buffer or
whatever else it's drawing client surfaces on. And the client does have
wiggle room, like I said it can draw whatever it wants.

> > We've talked about similar approaches to other things in wlroots and, at
> > least for our group, the consensus is that we don't generally like
> > changing behaviors simply based on the existence of a resource. We may
> > as well be explicit.
> 
> As the protocol is defined here, the only way for these clients to
> function is to not bind the global though, as otherwise they might be
> force to do something that they cannot.

I think I see where you're getting at in these comments. I'll keep this
in mind for the next revision.

> That's something that can be done too. What I meant, however, was to
> rename the XML file and the directory which it is in. If new window
> types are added etc, their requirements might differ, but making the
> "protocol group" slightly more generic sounding, it'd be more flexible
> for additions in the future.

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

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Jonas Ådahl]

On Fri, Apr 13, 2018 at 10:48:56AM -0400, Drew DeVault wrote:
> On 2018-04-13  4:35 PM, Jonas Ådahl wrote:
> > Is this the consensus as well? Because if it should be possible, there
> > are those things I mentioned to consider regarding capabilities. A
> > potential mode could for example be to outsource drawing shadow or
> > something.
> 
> This use-case is valid, but seems thin to me. I don't think it's worth
> the additional complexity to implement. Just my personal opinion,
> though, I can't speak for others (however, the interested parties are
> all copied on this thread).
> 
> > Ignoring that for a bit, I guess the reason for allowing the compositor
> > to disregard the set mode to be that a client might not know whether
> > request ssd or csd? Especially in the example you gave above. Then what
> > is the purpose of the set_mode request at all?
> 
> Some clients may choose to respect the wishes of the compositor in some
> situations and not in others. GTK+, for example, supports adding UI
> elements to its titlebars. My patch for the old protocol only respects
> the compositor's decision if the program has not added any interactive
> elements to the titlebar.

In GTK+ I assume it could be implemented as,

* If there are widgets added to the titlebar, don't create the
  decoration object.

* If none are added, create the decoration object and obey the
  compositors order.

Neither these need the "set_mode" or "preferred_mode" stuff.

> 
> Clients have an arbitrary surface in which they can render whatever they
> want, including decorations. Compositors have an arbitrary surface in
> which they can render whatever they want, including decorations. The
> protocol acknowledges that after negotiations either party can do
> whatever they want, but communicates their choice to each other so they
> can make more educated decisions.

Not sure what you mean here. The surface is from the client here only,
and the client has no wiggle room in the proposed protocol, only the
compositor.

> 
> > Lets assume a client that have the ability to outsource window
> > decoration rendering, creates the decoration object; great, the
> > compositor will, based on its own preference and knowledge about the
> > window at configure time whether it wants to tile, decorate etc and
> > configures the surface accordingly. No need for the set_mode() request,
> > nor the preferred_mode event.
> > 
> > Client that doesn't have that ability (e.g. gedit, nautilus, chromiuim
> > etc) will simply not create the decoration object because the window
> > decoration is part of the main user interface. No need for the
> > set_mode() request, nor the preferred_mode event.
> 
> We've talked about similar approaches to other things in wlroots and, at
> least for our group, the consensus is that we don't generally like
> changing behaviors simply based on the existence of a resource. We may
> as well be explicit.

As the protocol is defined here, the only way for these clients to
function is to not bind the global though, as otherwise they might be
force to do something that they cannot.

> 
> > I'm not really talking about a new shell, but about e.g xdg_popup, or if
> > we for some reason need another xdg_surface based window type that is
> > neither xdg_popup or xdg_toplevel.
> 
> I see, this is a good point. I agree that it would be better to attach
> it to the xdg_surface rather than the toplevel, then.

That's something that can be done too. What I meant, however, was to
rename the XML file and the directory which it is in. If new window
types are added etc, their requirements might differ, but making the
"protocol group" slightly more generic sounding, it'd be more flexible
for additions in the future.


Jonas

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

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Drew DeVault]

On 2018-04-13  4:35 PM, Jonas Ådahl wrote:
> Is this the consensus as well? Because if it should be possible, there
> are those things I mentioned to consider regarding capabilities. A
> potential mode could for example be to outsource drawing shadow or
> something.

This use-case is valid, but seems thin to me. I don't think it's worth
the additional complexity to implement. Just my personal opinion,
though, I can't speak for others (however, the interested parties are
all copied on this thread).

> Ignoring that for a bit, I guess the reason for allowing the compositor
> to disregard the set mode to be that a client might not know whether
> request ssd or csd? Especially in the example you gave above. Then what
> is the purpose of the set_mode request at all?

Some clients may choose to respect the wishes of the compositor in some
situations and not in others. GTK+, for example, supports adding UI
elements to its titlebars. My patch for the old protocol only respects
the compositor's decision if the program has not added any interactive
elements to the titlebar.

Clients have an arbitrary surface in which they can render whatever they
want, including decorations. Compositors have an arbitrary surface in
which they can render whatever they want, including decorations. The
protocol acknowledges that after negotiations either party can do
whatever they want, but communicates their choice to each other so they
can make more educated decisions.

> Lets assume a client that have the ability to outsource window
> decoration rendering, creates the decoration object; great, the
> compositor will, based on its own preference and knowledge about the
> window at configure time whether it wants to tile, decorate etc and
> configures the surface accordingly. No need for the set_mode() request,
> nor the preferred_mode event.
> 
> Client that doesn't have that ability (e.g. gedit, nautilus, chromiuim
> etc) will simply not create the decoration object because the window
> decoration is part of the main user interface. No need for the
> set_mode() request, nor the preferred_mode event.

We've talked about similar approaches to other things in wlroots and, at
least for our group, the consensus is that we don't generally like
changing behaviors simply based on the existence of a resource. We may
as well be explicit.

> I'm not really talking about a new shell, but about e.g xdg_popup, or if
> we for some reason need another xdg_surface based window type that is
> neither xdg_popup or xdg_toplevel.

I see, this is a good point. I agree that it would be better to attach
it to the xdg_surface rather than the toplevel, then.

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

Re: [PATCHv3] Add name event to xdg-output

[Drew DeVault]

On 2018-04-13  4:16 PM, Jonas Ådahl wrote:
> If that is the case, I'd rather we introduced data that has actual
> meaning, like something similar to "connector" (even though connector is
> the wrong thing here since an "xdg_output" might not have one, maybe,
> something that doesn't identify the monitor itself, but how it is
> connected, if that is what you want) and then a different thing that is
> more meaningful to a user interface. Then whether the "this is string is
> user interface facing" should have anything to do with where the wire is
> plugged in or what is actually plugged in can be up to the software that
> is responsible for generating that string, but it should be clear what
> its purpose is.

This has already been discussed in the rest of the thread. We would have
to add meaning that isn't necessarily there. The meaning is deliberately
omitted. There are many cases we can suppose that make it difficult to
add any meaning. Instead of adding meaning, we make guarantees.

We have two audiences we need to communicate with: the client, and the
end-user. They have different needs.

The end-user only needs to be able to select an output using terminology
they will understand. We can trust compositor implementors to embue
these names with the right amount of meaning for this purpose and
to educate their users on their approach. All the client has to do to
fulfill this is faithfully communicate the name the compositor has
provided to the user.

The client needs to:

1. Provide the user a means to select an output in terms they will
   understand
2. Identify outputs across sessions

Any knowledge of the inputs that went into preparing the name are not
among the supported use-cases of this protocol. It's not important for
the client to understand that. They just need these two needs fulfilled.

To that end, rather than making a futile attempt to describe outputs in
terms that won't apply in all cases, the current revision aims only to
secure these two guarantees.

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

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Jonas Ådahl]

On Fri, Apr 13, 2018 at 10:03:11AM -0400, Drew DeVault wrote:
> On 2018-04-13  3:56 PM, Jonas Ådahl wrote:
> > What is the purpose of making the compositor changing the "preferred"
> > mode? If we would make the assumption that a compositor stays the same
> > during the whole session as in it'll either always prefer or not prefer
> > dealing with decorations, and we assume that we always only have the two
> > "modes", the protocol could probably be greatly simplified by just
> > having a destroy function, and assuming a client having created the
> > decoration object always outsourcing the drawing decorations etc to the
> > compositor.
> 
> It may change during the session. User might change their config files
> and reload, for example. A toplevel might be changed from a tiling
> layout to a floating one and the compositor might prefer floating
> toplevel decorate themselves, for example.

That's a good point.

> 
> > If we add more modes, compositor or clients are forced to support all
> > different combinations of modes to support new versions of the protocol.
> 
> I don't foresee new modes being added.

Is this the consensus as well? Because if it should be possible, there
are those things I mentioned to consider regarding capabilities. A
potential mode could for example be to outsource drawing shadow or
something.

Ignoring that for a bit, I guess the reason for allowing the compositor
to disregard the set mode to be that a client might not know whether
request ssd or csd? Especially in the example you gave above. Then what
is the purpose of the set_mode request at all?

Lets assume a client that have the ability to outsource window
decoration rendering, creates the decoration object; great, the
compositor will, based on its own preference and knowledge about the
window at configure time whether it wants to tile, decorate etc and
configures the surface accordingly. No need for the set_mode() request,
nor the preferred_mode event.

Client that doesn't have that ability (e.g. gedit, nautilus, chromiuim
etc) will simply not create the decoration object because the window
decoration is part of the main user interface. No need for the
set_mode() request, nor the preferred_mode event.

What other scenarios are there?

> 
> > Another thing to consider is whether non-toplevels ever want a similar
> > kind of protocol? It is not something we need to go into much further
> > details now, but it would be easy to add into this protocol by just
> > renaming the directory under unstable/ and the XML file to
> > "xdg-decorations" or something. Would we have another type of surface
> > that needs similar functionality, we could add that as a separate pair
> > of interfaces.
> 
> I think that for the time being it would be wise to proceed under the
> assumption that we won't have another shell that needs this. I would
> sooner advocate for the continued development of xdg-shell than for a
> new shell with desktop-like capabilities.
> 
> This might turn out to be short-sighted but a new shell would probably
> break enough other stuff that this'll just be another pill of many we
> have to swallow when the time comes.

I'm not really talking about a new shell, but about e.g xdg_popup, or if
we for some reason need another xdg_surface based window type that is
neither xdg_popup or xdg_toplevel.


Jonas

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

[PATCH] xdg-shell: add enums for tiled window state to toplevel configure

[Mike Blumenkrantz]

this adds implementation from a related discussion long ago in which
it was decided that it would be useful for clients to know if/where their
windows were tiled so that various behaviors and visuals could be modified
to improve UX

a window which is e.g., tiled on the right side of the screen would set the
right|top|bottom tiled states in configure

Signed-off-by: Mike Blumenkrantz 
Reviewed-by: Jonas Ådahl 

Changes since v2: simplified docs
Changes since v1: added since=2 to enum members
---
 stable/xdg-shell/xdg-shell.xml | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..c4dedd0 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -29,7 +29,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   The xdg_wm_base interface is exposed as a global object enabling clients
   to turn their wl_surfaces into windows in a desktop environment. It
@@ -115,7 +115,7 @@
 
   
 
-  
+  
 
   The xdg_positioner provides a collection of rules for the placement of a
   child surface relative to a parent surface. Rules can be defined to 
ensure
@@ -359,7 +359,7 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -528,7 +528,7 @@
 
   
 
-  
+  
 
   This interface defines an xdg_surface role which allows a surface to,
   among other things, set window-like properties such as maximize,
@@ -750,6 +750,30 @@
  keyboard or pointer focus.

   
+  
+   
+ The window is currently in a tiled layout and the left edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the right edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the top edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the bottom edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
 
 
 
@@ -989,7 +1013,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.14.3

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

Re: [PATCHv3] Add name event to xdg-output

[Jonas Ådahl]

On Fri, Apr 13, 2018 at 10:05:39AM -0400, Drew DeVault wrote:
> On 2018-04-13  4:02 PM, Jonas Ådahl wrote:
> > > - A client using fullscreen-shell could offer the user a list of outputs
> > >   by name to fullscreen on
> > 
> > I think this would need something different, an actual "human friendly"
> > name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings like
> > "DP-1", they are hardly helpful for selecting where to fullscreen.
> 
> In sway, we have a slightly more savvy base user than the general
> population, and we've educated them to understand connectors. However,
> this is exactly why the field is vague - other compositors can name them
> anything they like, including "Dell 24".

If that is the case, I'd rather we introduced data that has actual
meaning, like something similar to "connector" (even though connector is
the wrong thing here since an "xdg_output" might not have one, maybe,
something that doesn't identify the monitor itself, but how it is
connected, if that is what you want) and then a different thing that is
more meaningful to a user interface. Then whether the "this is string is
user interface facing" should have anything to do with where the wire is
plugged in or what is actually plugged in can be up to the software that
is responsible for generating that string, but it should be clear what
its purpose is.

> 
> > > - Xwayland can name the X11 outputs based on their genuine names rather
> > >   than assigning e.g. XWAYLAND0
> > 
> > If the protocol is loosly specified as in it's not known what format
> > you'll get, I don't think Xwayland can make any use of this.
> 
> Can you elaborate on what expectations Xwayland would have? I am open to
> restricting the format a bit, e.g. to ASCII characters or so.

If we'd add quotation marks, spaces etc I'm sure many things would break
here and there. If we start adding such restrictions, it'd hardly be
suitable as a "human readable" kind of thing.


Jonas

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

Re: [PATCH weston v6 00/73] Head-based output configuration API a.k.a clone mode infrastructure

[Pekka Paalanen]

On Thu, 12 Apr 2018 12:09:26 +0200
Daniel Stone  wrote:

> Hi Pekka,
> 
> On 16 February 2018 at 15:56, Pekka Paalanen  wrote:
> > here is the v6 of the shared-CRTC clone mode series. Since v5, quite
> > many patches have been extracted from this series, sent out and merged
> > upstream. However, now the series is bigger than ever, because here I am
> > posting the complete series, including the full DRM-backend migration
> > and DRM shared-CRTC clone mode implementation, thanks to having the
> > basic atomic modesetting landed upstream.  
> 
> I reviewed clonemode-7-part1 from
> https://gitlab.collabora.com/pq/weston, which is slightly revised (&
> significantly truncated) compared to this series. Here's a braindump:
> 
> When adding head_list to a weston_output, we can't send
> wp_presentation_feedback's sync_output event to the same resource for
> multiple wl_outputs:
> https://gitlab.collabora.com/pq/weston/commit/d0f5afff9213b81c329a98cdc7593a0101f953d5#note_7491

Fixed.

> Should be a pretty easy fix (don't iterate through multiple heads once
> you've sent an event to at least one head's resource), but I don't
> know what the long-term fix is. Maybe there isn't a good one.

I think the fix there is very much sufficient.

> I think this is also a small and easily-fixable bug:
> https://gitlab.collabora.com/pq/weston/commit/55206c5e8453722caed18d7fc6e3d9ed0966e623#note_7496

Unfortunately, it's complicated and not a bug. :-P
Explanation in Gitlab.

> The only real interface change I'd like to see is using a listener
> list rather than a single callback:
> https://gitlab.collabora.com/pq/weston/commit/ebb74da3c89d90810f8209340da33faeea3169bd#note_7493

Done.

> Here are a couple of throwaway comments and nitpicks; feel free to ignore 
> them:
> https://gitlab.collabora.com/pq/weston/commit/199fda53546128afb6c0553749dfa85bd00799a4#note_7492
> https://gitlab.collabora.com/pq/weston/commit/c618aa3dc9c2046e5540bbe444375f79e2e2c71f#note_7494
> https://gitlab.collabora.com/pq/weston/commit/6a20dd4e16ae75431149c19e42b52eaf2e179b8c#note_7495

Yeah.

> The rest looks good to me! I think it'd be good to merge 'libweston:
> cancel idle_repaint on output destroy' ASAP in particular. The fbdev
> and RDP patches are quite lazily Acked-by me, as I lost the will to
> live whilst trying to review them. The rest of the series, with at
> least the first three addressed, is Reviewed-by me.

Your R-b and A-b should be in place, the revised series is at
https://gitlab.collabora.com/pq/weston/commits/clonemode-8-part1

I ran through my test procedure from the v6 cover-letter, and
everything worked as expected there, except for the DRM-backend tests.

drmModeAtomicCommit() fails with -EBUSY after the "start with two
outputs, unplug and re-plug one" test. It happens already on upstream
master, so it's not introduced by this series. The panel has seconds
showing, and I am unplugging and replugging a DisplayPort monitor.

The zero outputs test fails on hotplug which looks like my bad in this
series, so I need to fix that before we land this. The test works fine
on upstream master.


Thanks,
pq


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

Re: [PATCHv3] Add name event to xdg-output

[Drew DeVault]

On 2018-04-13  4:02 PM, Jonas Ådahl wrote:
> > - A client using fullscreen-shell could offer the user a list of outputs
> >   by name to fullscreen on
> 
> I think this would need something different, an actual "human friendly"
> name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings like
> "DP-1", they are hardly helpful for selecting where to fullscreen.

In sway, we have a slightly more savvy base user than the general
population, and we've educated them to understand connectors. However,
this is exactly why the field is vague - other compositors can name them
anything they like, including "Dell 24".

> > - Xwayland can name the X11 outputs based on their genuine names rather
> >   than assigning e.g. XWAYLAND0
> 
> If the protocol is loosly specified as in it's not known what format
> you'll get, I don't think Xwayland can make any use of this.

Can you elaborate on what expectations Xwayland would have? I am open to
restricting the format a bit, e.g. to ASCII characters or so.

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

Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Drew DeVault]

On 2018-04-13  3:56 PM, Jonas Ådahl wrote:
> What is the purpose of making the compositor changing the "preferred"
> mode? If we would make the assumption that a compositor stays the same
> during the whole session as in it'll either always prefer or not prefer
> dealing with decorations, and we assume that we always only have the two
> "modes", the protocol could probably be greatly simplified by just
> having a destroy function, and assuming a client having created the
> decoration object always outsourcing the drawing decorations etc to the
> compositor.

It may change during the session. User might change their config files
and reload, for example. A toplevel might be changed from a tiling
layout to a floating one and the compositor might prefer floating
toplevel decorate themselves, for example.

> If we add more modes, compositor or clients are forced to support all
> different combinations of modes to support new versions of the protocol.

I don't foresee new modes being added.

> Another thing to consider is whether non-toplevels ever want a similar
> kind of protocol? It is not something we need to go into much further
> details now, but it would be easy to add into this protocol by just
> renaming the directory under unstable/ and the XML file to
> "xdg-decorations" or something. Would we have another type of surface
> that needs similar functionality, we could add that as a separate pair
> of interfaces.

I think that for the time being it would be wise to proceed under the
assumption that we won't have another shell that needs this. I would
sooner advocate for the continued development of xdg-shell than for a
new shell with desktop-like capabilities.

This might turn out to be short-sighted but a new shell would probably
break enough other stuff that this'll just be another pill of many we
have to swallow when the time comes.

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

Re: [PATCHv3] Add name event to xdg-output

[Jonas Ådahl]

On Wed, Apr 11, 2018 at 08:35:34AM -0400, Drew DeVault wrote:
> On 2018-04-11  9:17 AM, Philipp Kerling wrote:
> > maybe I missed it at some point in the discussion (sorry if that is the
> > case), but what is your use case for the "name?" What are clients
> > expected to use it for?
> 
> This is ideally combined with other protocols. Some example use-cases:
> 
> - A client using fullscreen-shell could offer the user a list of outputs
>   by name to fullscreen on

I think this would need something different, an actual "human friendly"
name, like 'Dell 24"' or 'Builtin monitor'. If you'd have strings like
"DP-1", they are hardly helpful for selecting where to fullscreen.

> - Xwayland can name the X11 outputs based on their genuine names rather
>   than assigning e.g. XWAYLAND0

If the protocol is loosly specified as in it's not known what format
you'll get, I don't think Xwayland can make any use of this.


Jonas

> 
> --
> Drew DeVault
> ___
> 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 wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol

[Jonas Ådahl]

On Sat, Mar 24, 2018 at 07:08:15AM -0400, Simon Ser wrote:
> This adds a new protocol to negotiate server-side rendering of window
> decorations for xdg-toplevels. This allows compositors that want to draw
> decorations themselves to send their preference to clients, and clients that
> prefer server-side decorations to request them.
> 
> This is inspired by a protocol from KDE [1] which has been implemented in
> KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> provides an updated protocol with those concerns taken into account.
> 
> Signed-off-by: Simon Ser 
> Reviewed-by: Drew DeVault 
> Reviewed-by: David Edmundson 
> Reviewed-by: Alan Griffiths 
> Reviewed-by: Tony Crisci 
> 
> [1] 
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> [2] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> ---
> 
> This was iterated on privately between representatives of Sway and wlroots
> (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
> Mir (Alan Griffiths).
> 
> A proof-of-concept of a client and server implementation is available at [1].
> 
> Changes from v3 to v4:
> - Updated the definition of decorations to remove unnecessary constraints 
> (Eike)
> - Fix ambiguity in zxdg_toplevel_decoration_v1 description (Peter)
> - Specify that the decoration object must be destroyed before the toplevel
>   (Pekka, Peter)
> - Changed decoration mode enum to "client_side" and "server_side" (Peter)
> - Replaced "server" with "compositor" in preferred_mode event description
>   (Peter)
> - State that the mode sent by the compositor with the configure event must be
>   obeyed (Peter)
> - Reword client-side decorations description (Eike)

Hi,

I have some questions about some of the details.

What is the purpose of making the compositor changing the "preferred"
mode? If we would make the assumption that a compositor stays the same
during the whole session as in it'll either always prefer or not prefer
dealing with decorations, and we assume that we always only have the two
"modes", the protocol could probably be greatly simplified by just
having a destroy function, and assuming a client having created the
decoration object always outsourcing the drawing decorations etc to the
compositor.

If there is some reason that it actually should be changeable, or that
more modes may be added later, I think there are two problems:

If we add more modes, compositor or clients are forced to support all
different combinations of modes to support new versions of the protocol.

This could be solveable by doing two changes:

1) Make "preferred_mode" an ordered array with supported modes in the
order of preference. 2) Don't let the compositor ignore the set_mode()
request. That way, the compositor will let the client know what it can
do and how it prefers things, and the client can safely make a decision
it knows it can support. With this, I don't think we'd need the
configure event anymore as well, we'd just assume the "set_mode" request
to be part of the wl_surface transaction.


Another thing to consider is whether non-toplevels ever want a similar
kind of protocol? It is not something we need to go into much further
details now, but it would be easy to add into this protocol by just
renaming the directory under unstable/ and the XML file to
"xdg-decorations" or something. Would we have another type of surface
that needs similar functionality, we could add that as a separate pair
of interfaces.


Jonas

> 
> [1] https://github.com/swaywm/wlroots/pull/638
> 
>  Makefile.am|   1 +
>  unstable/xdg-toplevel-decoration/README|   4 +
>  .../xdg-toplevel-decoration-unstable-v1.xml| 139 
> +
>  3 files changed, 144 insertions(+)
>  create mode 100644 unstable/xdg-toplevel-decoration/README
>  create mode 100644 
> unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..07744e9 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-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml  
>   \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xdg-toplevel-decoration/README 
> b/unstable/xdg-toplevel-decoration/README
> new file mode 100644
> index 000..e927110
> --- /dev/null
> +++ 

Re: [PATCH] xdg-shell: add enums for tiled window state to toplevel configure

[Jonas Ådahl]

On Tue, Apr 10, 2018 at 09:05:28AM -0400, Mike Blumenkrantz wrote:
> this adds implementation from a related discussion long ago in which
> it was decided that it would be useful for clients to know if/where their
> windows were tiled so that various behaviors and visuals could be modified
> to improve UX
> 
> a window which is e.g., tiled on the right side of the screen would set the
> right|top|bottom tiled states in configure
> 
> Signed-off-by: Mike Blumenkrantz 

Looks good to me. I'll have a look about adding the other thing missing
to make the gtk_shell tiling stuff obsolete. I have one comment below
inline. With that fixed, this is

Reviewed-by: Jonas Ådahl 


> 
> Changes since v1: added since=2 to enum members
> ---
>  stable/xdg-shell/xdg-shell.xml | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index d524ea9..629b983 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -29,7 +29,7 @@
>  DEALINGS IN THE SOFTWARE.
>
>  
> -  
> +  
>  
>The xdg_wm_base interface is exposed as a global object enabling 
> clients
>to turn their wl_surfaces into windows in a desktop environment. It
> @@ -115,7 +115,7 @@
>  
>
>  
> -  
> +  
>  
>The xdg_positioner provides a collection of rules for the placement of 
> a
>child surface relative to a parent surface. Rules can be defined to 
> ensure
> @@ -359,7 +359,7 @@
>  
>
>  
> -  
> +  
>  
>An interface that may be implemented by a wl_surface, for
>implementations that provide a desktop-style user interface.
> @@ -528,7 +528,7 @@
>  
>
>  
> -  
> +  
>  
>This interface defines an xdg_surface role which allows a surface to,
>among other things, set window-like properties such as maximize,
> @@ -750,6 +750,30 @@
> keyboard or pointer focus.
>   
>
> +  
> + 

I think the summary attribute should only go in the description element.
I also just noticed they are all the same. Might not need the "now" as
well, since the state might change, but not necessarily the tiled-ness.


Jonas

> +   The window is currently in a tiled layout and the left edge is 
> considered to be
> +   adjacent to another part of the tiling grid.
> + 
> +  
> +  
> + 
> +   The window is currently in a tiled layout and the right edge is 
> considered to be
> +   adjacent to another part of the tiling grid.
> + 
> +  
> +  
> + 
> +   The window is currently in a tiled layout and the top edge is 
> considered to be
> +   adjacent to another part of the tiling grid.
> + 
> +  
> +  
> + 
> +   The window is currently in a tiled layout and the bottom edge is 
> considered to be
> +   adjacent to another part of the tiling grid.
> + 
> +  
>  
>  
>  
> @@ -989,7 +1013,7 @@
>  
>
>  
> -  
> +  
>  
>A popup surface is a short-lived, temporary surface. It can be used to
>implement for example menus, popovers, tooltips and other similar user
> -- 
> 2.14.3
> 
> ___
> 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: [PATCHv3] Add name event to xdg-output

[Pekka Paalanen]

On Tue, 10 Apr 2018 20:27:55 -0400
Drew DeVault  wrote:

> Signed-off-by: Drew DeVault 
> Reviewed-by: Simon Ser 
> ---
> This version clarifies the uniqueness constraint, mapping of names to
> wl_outputs, and persistence between sessions.
> 
>  .../xdg-output/xdg-output-unstable-v1.xml | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index 0c0c481..b46c9df 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -77,7 +77,7 @@
>  
>
>  
> -  
> +  
>  
>An xdg_output describes part of the compositor geometry.
>  

Hi,

the version bump on zxdg_output_manager_v1 seems to be missing.

> @@ -157,5 +157,22 @@
>
>  
>  
> +
> +  
> +Many compositors will assign names to their outputs, show them to the 
> user,
> +allow them to be configured by name, etc. The client may wish to know 
> this
> +name as well to offer the user similar behaviors.
> +
> +The naming convention is compositor defined. Each name is unique among 
> all
> +wl_output globals, but if a wl_output global is destroyed the same name 
> may
> +be reused later. The names will also remain consistent across sessions 
> with
> +the same hardware and software configuration.
> +
> +The name event is sent after creating an xdg_output (see
> +xdg_output_manager.get_xdg_output).

The other events have more precise wording here, allowing the event to
be sent again if the information changes.

> +  
> +  
> +
> +
>
>  

Otherwise looks good to me, judging from our past discussions.


Thanks,
pq


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

Re: Wayland presentation extension (video protocol) WIP after RFCv2

[Daniel Stone]

Hi,

On 13 April 2018 at 12:29, Michel Dänzer  wrote:
> On 2018-04-13 11:43 AM, Daniel Stone wrote:
>> On 13 April 2018 at 10:17, Michel Dänzer  wrote:
>>> Also, both higher-level APIs I know of which allow the application to
>>> specify a target timestamp for presentation (VDPAU and
>>> VK_GOOGLE_display_timing) use "not before" semantics. So, maybe the
>>> not_before flag can be dropped, and flags can be added later for
>>> different semantics, if a need for them ever materializes.
>
> Just to be clear, I meant that the default semantics should be "not before".

Understood. I think we need to fix/clarify the feedback side of
things, so that the app knows when exactly critical presentation
deadlines are, in order to synchronise its rendering loop. Once we
have that down properly, not-before for queuing makes sense.

>> ... that being said, VK_GOOGLE_display_timing's 'present margin' is
>> probably enough to cover these, rather than having to deal in absolute
>> timestamps.
>
> Not sure what you mean. presentMargin is the amount of time the
> application could have delayed the vkQueuePresentKHR call while still
> allowing to meet the desiredPresentTime as closely as possible. It
> doesn't affect that the image shouldn't be presented before
> desiredPresentTime.

Makes sense. No argument. :)

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

Re: Wayland presentation extension (video protocol) WIP after RFCv2

[Michel Dänzer]

On 2018-04-13 11:43 AM, Daniel Stone wrote:
> On 13 April 2018 at 10:17, Michel Dänzer  wrote:
> 
>> Also, both higher-level APIs I know of which allow the application to
>> specify a target timestamp for presentation (VDPAU and
>> VK_GOOGLE_display_timing) use "not before" semantics. So, maybe the
>> not_before flag can be dropped, and flags can be added later for
>> different semantics, if a need for them ever materializes.

Just to be clear, I meant that the default semantics should be "not before".


> ... that being said, VK_GOOGLE_display_timing's 'present margin' is
> probably enough to cover these, rather than having to deal in absolute
> timestamps.

Not sure what you mean. presentMargin is the amount of time the
application could have delayed the vkQueuePresentKHR call while still
allowing to meet the desiredPresentTime as closely as possible. It
doesn't affect that the image shouldn't be presented before
desiredPresentTime.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland presentation extension (video protocol) WIP after RFCv2

[Daniel Stone]

Hi Michel,

On 13 April 2018 at 10:17, Michel Dänzer  wrote:
> reviving an old topic... Inspired by the thread "RFC for a render API to
> support adaptive sync and VRR" currently happening on the dri-devel list.

I've been following that thread pretty keenly.

> On 2014-02-26 10:30 AM, Pekka Paalanen wrote:
>> Since then, there has been plenty of discussion, some protocol changes
>> towards a v3, and I have a WIP implementation. My current work can be
>> found at
>> http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-WIP2
>> for now. When I get back, the branch will be rewritten and/or
>> abandoned.
>
> I looked at
> https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=presentation-WIP4=5cacb71c28052d9a491ad969d74d9145cfe9936d

FWIW, the feedback - not queuing - side got merged a long time ago:
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time/presentation-time.xml

> First, I'd like to question that "turns-to-light" are good semantics for
> the timestamps, since the Wayland compositor and driver stack generally
> don't know the delay from scanout to the display emitting light.

I agree. In reality, it's implemented as the timestamp we got from
KMS, which a) is not turned-to-light, and b) not directly useful to
the app. Knowing what I do now, I'd probably want:
  * the compositor's critical decision point, i.e. the absolute latest
time at which the client must have committed its buffer and have the
commit processed by the compositor (depends on compositor
implementation)
  * the hardware/driver's critical decision point, i.e. when all
fences must have signalled in order to present for the next frame
(just before start of vbl / end of previous vactive; strictly later
than previous)
  * actual real turned-to-light (strictly later than previous and
almost certainly static offset gained from CEA or whatever)

> Applications which are sensitive to this delay can deal with it by other
> means, e.g.:
>
> * Video players usually have a delay setting, which the user can tweak
>   for optimal audio/video sync.
> * Some games have a calibration function, e.g. displaying regular
>   flashes and asking the player to press a button on each flash.
> * Mario has access to very precise measurement gear at work, the data
>   from which is used in applications for this I presume.
>
> The protocol tries to account for that the compositor may approximate
> the "turns-to-light" time:
>
> Compositors may approximate this from the framebuffer flip
> completion events from the system, and the latency of the
> physical display path if known.

You can probably tell from this that it was mainly designed for media
A/V sync, and not necessarily to drive repaint loops.

> But I'm afraid that's not really helpful, as it means the application
> cannot trust the timestamps but needs something as described above
> anyway. So it doesn't really buy anything over "scanout starts"
> semantics, for which the driver stack can provide accurate timestamps.

If we know from CEA that we have a fixed 100ms latency on the output
path, we should report that to the client. We're not going to get it
perfect obviously, but I think getting as accurate time-to-light as we
possibly can is a really good goal. It just doesn't solve the other
two cases, for the winsys client to know when it has to present to the
compositor, and also to know when any fences have to have completed.

> Also, both higher-level APIs I know of which allow the application to
> specify a target timestamp for presentation (VDPAU and
> VK_GOOGLE_display_timing) use "not before" semantics. So, maybe the
> not_before flag can be dropped, and flags can be added later for
> different semantics, if a need for them ever materializes.

... that being said, VK_GOOGLE_display_timing's 'present margin' is
probably enough to cover these, rather than having to deal in absolute
timestamps.

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

Re: Wayland presentation extension (video protocol) WIP after RFCv2

[Michel Dänzer]

Hi Pekka,


reviving an old topic... Inspired by the thread "RFC for a render API to
support adaptive sync and VRR" currently happening on the dri-devel list.


On 2014-02-26 10:30 AM, Pekka Paalanen wrote:
> Hi all,
> 
> I just wanted to mention where I am with this at the moment, as it
> seems like it will be some time before I can come back to this.
> 
> The RFCv2 thread started at:
> http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html
> 
> Since then, there has been plenty of discussion, some protocol changes
> towards a v3, and I have a WIP implementation. My current work can be
> found at
> http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-WIP2
> for now. When I get back, the branch will be rewritten and/or
> abandoned.

I looked at
https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=presentation-WIP4=5cacb71c28052d9a491ad969d74d9145cfe9936d
.


First, I'd like to question that "turns-to-light" are good semantics for
the timestamps, since the Wayland compositor and driver stack generally
don't know the delay from scanout to the display emitting light.
Applications which are sensitive to this delay can deal with it by other
means, e.g.:

* Video players usually have a delay setting, which the user can tweak
  for optimal audio/video sync.
* Some games have a calibration function, e.g. displaying regular
  flashes and asking the player to press a button on each flash.
* Mario has access to very precise measurement gear at work, the data
  from which is used in applications for this I presume.

The protocol tries to account for that the compositor may approximate
the "turns-to-light" time:

Compositors may approximate this from the framebuffer flip
completion events from the system, and the latency of the
physical display path if known.

But I'm afraid that's not really helpful, as it means the application
cannot trust the timestamps but needs something as described above
anyway. So it doesn't really buy anything over "scanout starts"
semantics, for which the driver stack can provide accurate timestamps.


Also, both higher-level APIs I know of which allow the application to
specify a target timestamp for presentation (VDPAU and
VK_GOOGLE_display_timing) use "not before" semantics. So, maybe the
not_before flag can be dropped, and flags can be added later for
different semantics, if a need for them ever materializes.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 21/25] protocol: add weston_touch_calibration

[Pekka Paalanen]

On Fri, 13 Apr 2018 14:31:39 +1000
Peter Hutterer  wrote:

> On Wed, Apr 11, 2018 at 02:00:49PM +0300, Pekka Paalanen wrote:
> > On Wed, 11 Apr 2018 10:16:46 +1000
> > Peter Hutterer  wrote:  

> > > > > > +  
> > > > > > +
> > > > > > +  On creation, this object is tied to a specific touch device. 
> > > > > > The
> > > > > > +  server sends a configure event which the client must obey 
> > > > > > with the
> > > > > > +  associated wl_surface.
> > > > > > +
> > > > > > +  Once the client has committed content to the surface, the 
> > > > > > server can
> > > > > > +  grab the touch input device, prevent it from emitting normal 
> > > > > > touch events,
> > > > > > +  show the surface on the correct output, and relay input 
> > > > > > events from the
> > > > > > +  touch device via this protocol object.
> > > > > > +
> > > > > > +  Touch events from other touch devices than the one tied to 
> > > > > > this object
> > > > > > +  must generate wrong_touch events on at least touch-down and 
> > > > > > must not
> > > > > > +  generate normal or calibration touch events.
> > > > > > +
> > > > > > +  At any time, the server can choose to cancel the calibration 
> > > > > > procedure by
> > > > > > +  sending the cancel_calibration event. This should also be 
> > > > > > used if the
> > > > > > +  touch device disappears or anything else prevents the 
> > > > > > calibration from
> > > > > > +  continuing on the server side.
> > > > > > +
> > > > > > +  If the wl_surface is destroyed, the server must cancel the 
> > > > > > calibration.
> > > > > > +
> > > > > > +  The touch event coordinates and conversion results are 
> > > > > > delivered in
> > > > > > +  calibration units. Calibration units are in the closed 
> > > > > > interval
> > > > > > +  [0.0, 1.0] mapped into 32-bit unsigned integers. An integer 
> > > > > > can be  
> > > > > 
> > > > > should probably add what 0.0 and 1.0 represent on each axis, i.e. 
> > > > > nominal
> > > > > width and height of the device's sensor. Or is this something we need 
> > > > > to
> > > > > hide?
> > > > 
> > > > I'm not sure. The underlying assumption is that there is a finite and
> > > > closed range of values a sensor can output, and that is mapped to [0,
> > > > 1]. I don't know what nominal width and height are or can the values
> > > > extend to negative. It might be easier to define the calibration units
> > > > without defining those first.
> > > 
> > > sorry, I used "nominal" before I rewrote to use "sensor", probably made it
> > > more confusing. On some devices, the sensor is larger than the screen so 
> > > you
> > > can get coordinates outside the screen area. This is not a technical
> > > problem, just a user perception mismatch that doens't need to be exposed 
> > > and
> > > after all that's what calibration is about.
> > > 
> > > Once you apply calibration though you can get real negative coordinates,
> > > especially if the device advertises a [n:m] range but then sends events 
> > > less
> > > than n. For example, all synaptics touchpads (pre 2014, some after that) 
> > > do
> > > that.  
> > 
> > But wait, if there are actually devices that report the range [n:m] but
> > can still send values less than n or greater than m, it means I cannot
> > transmit those with the encoding set up here, because
> > libinput_event_touch_get_x_transformed(touch_event, 1) can return
> > values outside of [0, 1] even when the loaded calibration matrix is
> > identity. Is that right?  
> 
> correct, that can happen.
> 
> > Do I need to find an encoding to cope with that, or can I just reject
> > such touches?
> > 
> > I mean, the range [n:m] is in raw input coordinates, before any
> > normalization or calibration in userspace, right?  
> 
> uhm. let me just detail this and you can pick which one was the answer to
> that question:
> - the kernel exposes [n:m] axis ranges for ABS_X/Y and the MT equivalents
> - libinput converts this into mm by default, see libinput_event_touch_get_x()
> - libinput converts this to a ranged value [0:N] when calling
>   libnput_event_touch_get_x_transformed(N). This is what weston uses to get
>   the screen coordinates.
> 
> Both libinput values have the calibration factored in already.
> 
> Weston doesn't ever see raw input coordinates. But if you use
> get_x_transformed, you can get values outside [0:N]. This happens when
> the [n:m] range is incorrect. Accommodating for some error margin, libinput
> will print a warning to the log when this happens.
> 
> The correct solution would be to warn the user that the device is garbage
> and make them put a 60-evdev.hwdb quirk in to fix the axis ranges.
> Depending on the device, this could be a generic solution but let's not bet
> on that...
> 
> The user-friendly solution would be to have two layers of mapping. By
> default, you map the libinput 

Re: [PATCHv2] text-input: Add v3 of the text-input protocol

[Silvan Jegen]

On Thu, Apr 12, 2018 at 9:53 PM, Dorota Czaplejewicz
 wrote:
> On Thu, 12 Apr 2018 21:26:08 +0200
> Silvan Jegen  wrote:
>
>> Hi Dorota
>>
>> On Wed, Apr 11, 2018 at 03:03:58PM +0200, Dorota Czaplejewicz wrote:
>> > This new protocol description is a simplification over v2.
>> >
>> > - All pre-edit text styling is gone.
>> > - No events regarding input panel (OSK) state nor covered rectangle.
>> >   Compositors are still free to handle situations where the keyboard
>> >   focus rectangle is covered by the input panel.
>> > - No set_preferred_language request for clients.
>> > - There is no event to send keysyms. Compositors can use wl_keyboard
>> >   interface instead.
>> >
>> > Reviewed-by: Drew DeVault 
>> > ---
>> >
>> > Hi,
>> >
>> > This patch follows the original proposal by Carlos Garnacho. It's the
>> > result of my work on behalf of Purism to get good on-screen keyboard
>> > support in Wayland. It incorporates changes coming from discussions
>> > with Sway/wlroots developers [0], as well as issues pointed out in
>> > response to the original proposal.
>> >
>> > Changes over the original:
>> > - typos, whitespace and naming as pointed out by Silvan Jegen
>> > - an explicit description of what happens to state: it's conceptually
>> >   double-buffered, and is not altered between focus events
>> > - removed the serial number on enter/leave events, as it's unambiguous
>> >   which surface has focus
>> >
>> > This protocol has already been implemented: in wlroots [0], rootston
>> > [1], and GTK3 [2]. We're counting on more projects to upstream support
>> > in order to settle on a single protocol for text input in the long
>> > term. Help and feedback appreciated!
>> >
>> > Cheers,
>> > Dorota Czaplejewicz
>> >
>> > PS. Sorry about the misformatted email on Monday.
>> >
>> > [0] https://github.com/swaywm/wlroots/pull/776
>> > [1] https://code.puri.sm/dorota.czaplejewicz/gtk
>> > [2] https://code.puri.sm/dorota.czaplejewicz/wlroots/src/text_input_test
>>
>> The last two references seem to be switched.
>>
>> I also might be dense but when I am trying to build the text_input_test
>> branch of your wlroots repo I get the following error because of a
>> missing text_input.h header file:
>>
>> [41/132] Compiling C object 'rootston/rootston@exe/main.c.o'.
>> FAILED: rootston/rootston@exe/main.c.o
>> cc  -Irootston/rootston@exe -Irootston -I../rootston -Iinclude -I../include 
>> -I/usr/include/libdrm -I/usr/include/libevdev-1.0/ 
>> -I/usr/include/libwacom-1.0 -I/usr/include/glib-2.0 
>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 
>> -I/home/silvan/builds/wlroots-dorota/build -fdiagnostics-color=always -pipe 
>> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O0 -g 
>> -Wno-unused-parameter '-DWLR_SRC_DIR="/home/silvan/builds/wlroots-dorota"' 
>> -DWL_HIDE_DEPRECATED -MD -MQ 'rootston/rootston@exe/main.c.o' -MF 
>> 'rootston/rootston@exe/main.c.o.d' -o 'rootston/rootston@exe/main.c.o' -c 
>> ../rootston/main.c
>> In file included from ../include/rootston/cursor.h:4:0,
>>  from ../include/rootston/input.h:9,
>>  from ../include/rootston/server.h:15,
>>  from ../rootston/main.c:13:
>> ../include/rootston/seat.h:7:10: fatal error: rootston/text_input.h: No such 
>> file or directory
>>  #include "rootston/text_input.h"
>>   ^~~
>> compilation terminated.
>> [42/132] Compiling C object 'rootston/rootston@exe/output.c.o'.
>> FAILED: rootston/rootston@exe/output.c.o
>> cc  -Irootston/rootston@exe -Irootston -I../rootston -Iinclude -I../include 
>> -I/usr/include/libdrm -I/usr/include/libevdev-1.0/ 
>> -I/usr/include/libwacom-1.0 -I/usr/include/glib-2.0 
>> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 
>> -I/home/silvan/builds/wlroots-dorota/build -fdiagnostics-color=always -pipe 
>> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O0 -g 
>> -Wno-unused-parameter '-DWLR_SRC_DIR="/home/silvan/builds/wlroots-dorota"' 
>> -DWL_HIDE_DEPRECATED -MD -MQ 'rootston/rootston@exe/output.c.o' -MF 
>> 'rootston/rootston@exe/output.c.o.d' -o 'rootston/rootston@exe/output.c.o' 
>> -c ../rootston/output.c
>> In file included from ../include/rootston/cursor.h:4:0,
>>  from ../include/rootston/input.h:9,
>>  from ../include/rootston/server.h:15,
>>  from ../rootston/output.c:18:
>> ../include/rootston/seat.h:7:10: fatal error: rootston/text_input.h: No such 
>> file or directory
>>  #include "rootston/text_input.h"
>>
>> ... etc.
>>
>> Am I supposed to generate that file myself somehow?
>>
>>
>> Cheers,
>>
>> Silvan
>
> Hi Silvan,
>
> thank you for noticing, I apparently didn't check in that file. That has been 
> hopefully fixed - I recreated and pushed it to the repository.

Awesome! I will test the code as soon as I find the time (most likely tomorrow).


> Sorry about the silly mistake.

[PATCH] compositor-headless: Report a more realistic physical size

[Johan Klokkhammer Helsing]

Some clients rely on the physical size to determine the physical DPI. With the
previous implementation, we would report 1px==1mm, which is a DPI of 25.4,
which is incredibly low.

The problem is solved by setting a physical size so the DPI is close to 72
instead. If the output is scaled, the DPI is set to the corresponding multiple
of 72.

This makes the headless backend more usable for automated testing of DPI
sensitive functionality such as point sized fonts.

Signed-off-by: Johan Klokkhammer Helsing 
---
 libweston/compositor-headless.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/libweston/compositor-headless.c b/libweston/compositor-headless.c
index 9307a36a..9f1a1a72 100644
--- a/libweston/compositor-headless.c
+++ b/libweston/compositor-headless.c
@@ -180,12 +180,19 @@ err_malloc:
return -1;
 }
 
+static int
+physical_size_for_dpi(int pixels, int dpi)
+{
+   static const float mm_per_inch = 25.4;
+   return pixels * mm_per_inch / dpi;
+}
+
 static int
 headless_output_set_size(struct weston_output *base,
 int width, int height)
 {
struct headless_output *output = to_headless_output(base);
-   int output_width, output_height;
+   int output_width, output_height, output_dpi;
 
/* We can only be called once. */
assert(!output->base.current_mode);
@@ -207,9 +214,10 @@ headless_output_set_size(struct weston_output *base,
output->base.make = "weston";
output->base.model = "headless";
 
-   /* XXX: Calculate proper size. */
-   output->base.mm_width = width;
-   output->base.mm_height = height;
+   /* XXX: Make this configurable */
+   output_dpi = 72 * output->base.scale;
+   output->base.mm_width = physical_size_for_dpi(output_width, output_dpi);
+   output->base.mm_height = physical_size_for_dpi(output_height, 
output_dpi);
 
output->base.start_repaint_loop = headless_output_start_repaint_loop;
output->base.repaint = headless_output_repaint;
-- 
2.16.3

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