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

[Carlos Garnacho]

Hi!,

On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian  wrote:
> (forgot to reply to the list)
>
> On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
>> On Wed, 11 Apr 2018 11:26:22 -0700
>>
>> Weng Xuetian  wrote:
>> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
>> > > On Sun, 11 Mar 2018 20:30:14 +0100
>> > >
>> > > Carlos Garnacho  wrote:
>> > > > This new protocol description is a vast simplification over v2,
>> > > > highlights
>> > > > are:
>> > > > - All pre-edit text styling is gone, the protocol doesn't seem the
>> > > > place
>> > > >
>> > > >   to convey UI state. Clients are in better knowledge of how to make
>> > > >   the
>> > > >   pre-edit string distinguishable from regular text.
>> >
>> > As an long-time input method developer and CJK user, I'd prefer to keep
>> > the
>> > styling. In Chinese or Japanese, partially converted text are common and
>> > styling is useful to help user to distinguish which text is currently
>> > being
>> > converted. [1] But for the sake of in-app consistency, I'd say we don't
>> > need that much capability about styling though. Among all input methods
>> > supported by fcitx [2], only underline/highlight is being commonly used.
>> > Recently I started to use some strike style in only one single input
>> > method though, it can also be useful in certain cases.
>>
>> I think this use case is covered. For indicating what's currently being
>> changed, this protocol is using "preedit string". In GTK, the preedit text
>> is displayed with an underline, making is always clear what the suggestion
>> pertains to.
> I think you can take a closer look at [1].
>
> "葵あ" is the complete preedit text. The input method is converting "葵" and
> giving the candidates for it, the あ part is not yet handled by input method
> (but typed by user and appears in the preedit). That's why "葵" is being
> highlighted.

IIUC, is あ simply unhighlighted till handled by the IM (and the
suggestion menu changes accordingly)? do preedit text styles in other
fcitx IMs convey the same or different info?

I wonder if we are missing some on-the-wire state, rather than text
styling support per se. And given the can of worms styling brings in
(hard to know how to stand out from the IM side, a11y and color
blindness issues, ...), I would personally rather have a hint system
than let the IM meddle with a foreign UI.

>
> In a single CJK text composition, CJK people would type the full sentence
> ahead instead of word by word because this helps input method to understand
> the whole context and improve the prediction.

I'm no CJK expert, so this might not apply neatly, but note there is a
set_surrounding_text request to help IM get context outside the
preedit string. This may even be combined with
delete_surrounding_text+commit_string to alter text outside preedit,
too.

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

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

[Carlos Garnacho]

Hi!,

Thanks for picking up on this Dorota, and sorry for catching up late,
initial discussion started on days off, and I still have a big pile of
"to go through" email.

On Wed, Apr 11, 2018 at 3:03 PM, 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

Cheers Silvan :).

> - an explicit description of what happens to state: it's conceptually
>   double-buffered, and is not altered between focus events

Thanks for spelling that out, quite an omission in my original
proposal... I have some comments below on this.

> - removed the serial number on enter/leave events, as it's unambiguous
>   which surface has focus

Right, I think that could be safely left out. However the checks for
untimely requests gets a bit more hairy (eg. checking that the
text_input client and the focus surface client are the same).
Something along the lines of "the compositor should ignore requests
from other clients than the focused surface's" could maybe be added on
docs, at least.

>
> 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
>
>  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 

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

[Eike Hein]

On 03/24/2018 08:08 PM, 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 


Forgotten in my previous reply:

Reviewed-by: Eike Hein 


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

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

[Weng Xuetian]

(forgot to reply to the list)

On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
> On Wed, 11 Apr 2018 11:26:22 -0700
> 
> Weng Xuetian  wrote:
> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > > On Sun, 11 Mar 2018 20:30:14 +0100
> > > 
> > > Carlos Garnacho  wrote:
> > > > This new protocol description is a vast simplification over v2,
> > > > highlights
> > > > are:
> > > > - All pre-edit text styling is gone, the protocol doesn't seem the
> > > > place
> > > > 
> > > >   to convey UI state. Clients are in better knowledge of how to make
> > > >   the
> > > >   pre-edit string distinguishable from regular text.
> > 
> > As an long-time input method developer and CJK user, I'd prefer to keep
> > the
> > styling. In Chinese or Japanese, partially converted text are common and
> > styling is useful to help user to distinguish which text is currently
> > being
> > converted. [1] But for the sake of in-app consistency, I'd say we don't
> > need that much capability about styling though. Among all input methods
> > supported by fcitx [2], only underline/highlight is being commonly used.
> > Recently I started to use some strike style in only one single input
> > method though, it can also be useful in certain cases.
> 
> I think this use case is covered. For indicating what's currently being
> changed, this protocol is using "preedit string". In GTK, the preedit text
> is displayed with an underline, making is always clear what the suggestion
> pertains to.
I think you can take a closer look at [1].

"葵あ" is the complete preedit text. The input method is converting "葵" and 
giving the candidates for it, the あ part is not yet handled by input method 
(but typed by user and appears in the preedit). That's why "葵" is being 
highlighted.

In a single CJK text composition, CJK people would type the full sentence 
ahead instead of word by word because this helps input method to understand 
the whole context and improve the prediction. 

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


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

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

[Dorota Czaplejewicz]

On Wed, 11 Apr 2018 11:26:22 -0700
Weng Xuetian  wrote:

> On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > On Sun, 11 Mar 2018 20:30:14 +0100
> > 
> > Carlos Garnacho  wrote:  
> > > This new protocol description is a vast simplification over v2, highlights
> > > are:
> > > - All pre-edit text styling is gone, the protocol doesn't seem the place
> > > 
> > >   to convey UI state. Clients are in better knowledge of how to make the
> > >   pre-edit string distinguishable from regular text.  
> As an long-time input method developer and CJK user, I'd prefer to keep the 
> styling. In Chinese or Japanese, partially converted text are common and 
> styling is useful to help user to distinguish which text is currently being 
> converted. [1] But for the sake of in-app consistency, I'd say we don't need 
> that much capability about styling though. Among all input methods supported 
> by fcitx [2], only underline/highlight is being commonly used. Recently I 
> started to use some strike style in only one single input method though, it 
> can also be useful in certain cases.

I think this use case is covered. For indicating what's currently being 
changed, this protocol is using "preedit string". In GTK, the preedit text is 
displayed with an underline, making is always clear what the suggestion 
pertains to.
> 
> > > 
> > > - No input panel (OSK) state nor covered rectangle events. This leaks
> > > 
> > >   assumptions about the coordinate space of windows, and clients aren't
> > >   fully capable of handling all possible situations (eg. if the OSK fully
> > >   covers the surface). At the very least it could be split into a generic
> > >   protocol of its own, this version of the protocol simply doesn't get
> > >   into this business, compositors are still free to handle situations
> > >   where
> > >   the keyboard focus rectangle is covered by the input panel.
> > > 
> > > - Less state is to be kept on compositors. Clients must now reissue all
> > > 
> > >   applying IM state whenever the surface gains focus (or internal focus
> > >   changes), instead of state requests being independent from focus.
> > > 
> > > - No set_preferred_language request for clients, modern desktops have
> > > 
> > >   generally moved towards session-wide IM settings, it seems hard to
> > >   conciliate this piece of information flowing in both directions.
> > > 
> > > - There is no event to send keysyms. The handling ought to be by all means
> > > 
> > >   identical to wl_keyboard's, compositors might just use that interface.  
> Let input method itself to send any key event is somewhat an important 
> feature. Common use cases includes "sending backspace key via OSK", or 
> "simulating another keyboard layout". Fcitx (5, which is under developlment) 
> provides ability to use a keyboard layout without changing the system global 
> layout, which can be extremely helpful for users using multiple layout. For 
> example,  the hotkey key binding would keep the same while they can still 
> using the custom layout (e.g. position of ctrl + z is different under us/de).
> 
> I assume that you mean that it is replaced by creating sythatical key event  
> via compositor and sending them via wl_keyboard? I'm not so sure if that 
> works, especially when there is no real phyiscal keyboard.
> 
I read it the same way. At the same time, I also don't see a reason to 
duplicate the keyboard interface in another protocol - the compositor can tell 
the application that there's a regular (but virtual) keyboard connected and 
send events using the regular wl_keyboard protocol.

Cheers,
Dorota

> [1] https://i.imgur.com/MpibNVi.png
> [2] https://fcitx-im.org/
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

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

[Weng Xuetian]

On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> On Sun, 11 Mar 2018 20:30:14 +0100
> 
> Carlos Garnacho  wrote:
> > This new protocol description is a vast simplification over v2, highlights
> > are:
> > - All pre-edit text styling is gone, the protocol doesn't seem the place
> > 
> >   to convey UI state. Clients are in better knowledge of how to make the
> >   pre-edit string distinguishable from regular text.
As an long-time input method developer and CJK user, I'd prefer to keep the 
styling. In Chinese or Japanese, partially converted text are common and 
styling is useful to help user to distinguish which text is currently being 
converted. [1] But for the sake of in-app consistency, I'd say we don't need 
that much capability about styling though. Among all input methods supported 
by fcitx [2], only underline/highlight is being commonly used. Recently I 
started to use some strike style in only one single input method though, it 
can also be useful in certain cases.

> > 
> > - No input panel (OSK) state nor covered rectangle events. This leaks
> > 
> >   assumptions about the coordinate space of windows, and clients aren't
> >   fully capable of handling all possible situations (eg. if the OSK fully
> >   covers the surface). At the very least it could be split into a generic
> >   protocol of its own, this version of the protocol simply doesn't get
> >   into this business, compositors are still free to handle situations
> >   where
> >   the keyboard focus rectangle is covered by the input panel.
> > 
> > - Less state is to be kept on compositors. Clients must now reissue all
> > 
> >   applying IM state whenever the surface gains focus (or internal focus
> >   changes), instead of state requests being independent from focus.
> > 
> > - No set_preferred_language request for clients, modern desktops have
> > 
> >   generally moved towards session-wide IM settings, it seems hard to
> >   conciliate this piece of information flowing in both directions.
> > 
> > - There is no event to send keysyms. The handling ought to be by all means
> > 
> >   identical to wl_keyboard's, compositors might just use that interface.
Let input method itself to send any key event is somewhat an important 
feature. Common use cases includes "sending backspace key via OSK", or 
"simulating another keyboard layout". Fcitx (5, which is under developlment) 
provides ability to use a keyboard layout without changing the system global 
layout, which can be extremely helpful for users using multiple layout. For 
example,  the hotkey key binding would keep the same while they can still 
using the custom layout (e.g. position of ctrl + z is different under us/de).

I assume that you mean that it is replaced by creating sythatical key event  
via compositor and sending them via wl_keyboard? I'm not so sure if that 
works, especially when there is no real phyiscal keyboard.

[1] https://i.imgur.com/MpibNVi.png
[2] https://fcitx-im.org/



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

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

[Jonas Ådahl]

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

Hi,

I'll let Carlos review the these changes, and I'll give it a go
eventually too, but just wanted to point out two things:

This patch does not apply. I suspect this may be because you didn't use
git-send-email. Using git-send-email (also with e.g.
--subject-prefix="PATCH wayland-protocols v2") is the work flow we
currently use.

The other thing is that the patch itself seems to be very similar to the
one Carlos made which you also write you based this one of. As so is the
case, you should not change the authorship of the patch, but instead add
your own "Signed-off-by" while optionally explaining the changes you did
compared to the original patch, either in the commit message or outside
the same way as the message I'm currently replying to was made.


Jonas

> 
> 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
> 
>  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 

Re: [PATCH] Add Meson build system

[Jonas Ådahl]

On Wed, Apr 11, 2018 at 06:04:26PM +0100, Emmanuele Bassi wrote:
> Hi Jonas;
> 
> On 11 April 2018 at 17:45, Jonas Ådahl  wrote:
> 
> > FWIW, I did something similar, here:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-
> > October/035399.html
> > because I wanted to add build tests. IIRC there is some bug that I only
> > fixed locally.
> >
> >
> Yes, I was planning to reference the work you did in the cover letter for
> this patch, but git-send-email is terrible.
> 
> I honestly didn't look at your patchset before doing this work — and, to be
> fair, I did this over my lunch break, so I didn't really get into doing
> anything more than a mechanical port.
> 
> I'd be happy to improve the build by merging my approach and yours. My
> patch is slightly more idiomatic with regards to recent Meson; it allows
> using wayland-protocols as a subproject, as it doesn't use
> `meson.source_root()` in paths; and it generates the pkg-config file
> directly instead of going through a template file.

That'd be great. Mostly what I care about is being able to run the build
tests, but not during the "configure" part, as that resulted in too much
"spam" effectively hiding any useful information one might wanted to
have seen. IIRC it needed some tricks to make that work.

> 
> I did leave the Autotools build in place because I don't know if people
> using wayland-protocols can also rely on having a recent version of Meson
> and Python 3.

Yea, might have been a bit too eager regarding the removal, I'd be fine
with leaving autotools there for a while.


Jonas

> 
> Ciao,
>  Emmanuele.
> 
> On Wed, Apr 11, 2018 at 05:27:49PM +0100, Emmanuele Bassi wrote:
> > > From: Emmanuele Bassi 
> > >
> > > Meson is a next generation build system, and various projects in the
> > > larger Linux ecosystem already moved to it — for instance:
> > >
> > >   - the X11 server
> > >   - the X11 protocols repository
> > >   - Mesa
> > >   - libdrm
> > >
> > > The added benefit for adding Meson support is that projects using Meson
> > > and depending on wayland-protocols can use the subproject functionality
> > > to always pull the latest version of the protocols without necessarily
> > > updating their build environment.
> > > ---
> > >  meson.build   | 89 +++
> > >  meson_options.txt |  5 +++
> > >  2 files changed, 94 insertions(+)
> > >  create mode 100644 meson.build
> > >  create mode 100644 meson_options.txt
> > >
> > > diff --git a/meson.build b/meson.build
> > > new file mode 100644
> > > index 000..c078ff3
> > > --- /dev/null
> > > +++ b/meson.build
> > > @@ -0,0 +1,89 @@
> > > +project('wayland-protocols', 'c',
> > > +  version: '1.13',
> > > +  license: 'MIT',
> > > +  meson_version: '>= 0.45.0',
> > > +)
> > > +
> > > +wayland_scanner_dep = dependency('wayland-scanner', required: false)
> > > +wayland_scanner_opt = get_option('wayland_scanner')
> > > +wayland_scanner_bin = ['wayland-scanner']
> > > +
> > > +if wayland_scanner_opt != ''
> > > +  wayland_scanner_bin += wayland_scanner_opt
> > > +endif
> > > +
> > > +if wayland_scanner_dep.found()
> > > +  wayland_scanner_bin += wayland_scanner_dep.get_
> > pkgconfig_variable('wayland_scanner')
> > > +endif
> > > +
> > > +wayland_scanner = find_program(wayland_scanner_bin)
> > > +
> > > +pkgdatadir = join_paths(get_option('datadir'), meson.project_name())
> > > +
> > > +protocol_files = []
> > > +
> > > +# name, [version, ...]
> > > +unstable_protocols = [
> > > +  [ 'pointer-gestures', ['v1',], ],
> > > +  [ 'fullscreen-shell', ['v1',], ],
> > > +  [ 'linux-dmabuf', ['v1',], ],
> > > +  [ 'text-input', ['v1',], ],
> > > +  [ 'input-method', ['v1',], ],
> > > +  [ 'xdg-shell', ['v5', 'v6',], ],
> > > +  [ 'relative-pointer', ['v1',], ],
> > > +  [ 'pointer-constraints', ['v1',], ],
> > > +  [ 'tablet', ['v1', 'v2',], ],
> > > +  [ 'xdg-foreign', ['v1', 'v2',], ],
> > > +  [ 'idle-inhibit', ['v1',], ],
> > > +  [ 'xwayland-keyboard-grab', ['v1',], ],
> > > +  [ 'keyboard-shortcuts-inhibit', ['v1',], ],
> > > +  [ 'xdg-output', ['v1',], ],
> > > +  [ 'input-timestamps', ['v1',], ],
> > > +]
> > > +
> > > +foreach p: unstable_protocols
> > > +  p_name = p[0]
> > > +  p_versions = p[1]
> > > +  foreach version: p_versions
> > > +xml_file = join_paths('unstable', p_name, '@0@-unstable-@1
> > @.xml'.format(p_name, version))
> > > +protocol_files += [[p_name, files(xml_file)]]
> > > +install_data(xml_file, install_dir: join_paths(pkgdatadir,
> > 'unstable', p_name))
> > > +  endforeach
> > > +endforeach
> > > +
> > > +stable_protocols = [
> > > +  'presentation-time',
> > > +  'viewporter',
> > > +  'xdg-shell',
> > > +]
> > > +
> > > +foreach p_name: stable_protocols
> > > +  xml_file = join_paths('stable', p_name, '@0@.xml'.format(p_name))
> > > +  protocol_files += [[p_name, files(xml_file)]]
> > > +  install_data(xml_file, install_dir: join_paths(pkgdatadir, 'stable',
> > 

Re: [PATCH] Add Meson build system

[Emmanuele Bassi]

Hi Jonas;

On 11 April 2018 at 17:45, Jonas Ådahl  wrote:

> FWIW, I did something similar, here:
> https://lists.freedesktop.org/archives/wayland-devel/2017-
> October/035399.html
> because I wanted to add build tests. IIRC there is some bug that I only
> fixed locally.
>
>
Yes, I was planning to reference the work you did in the cover letter for
this patch, but git-send-email is terrible.

I honestly didn't look at your patchset before doing this work — and, to be
fair, I did this over my lunch break, so I didn't really get into doing
anything more than a mechanical port.

I'd be happy to improve the build by merging my approach and yours. My
patch is slightly more idiomatic with regards to recent Meson; it allows
using wayland-protocols as a subproject, as it doesn't use
`meson.source_root()` in paths; and it generates the pkg-config file
directly instead of going through a template file.

I did leave the Autotools build in place because I don't know if people
using wayland-protocols can also rely on having a recent version of Meson
and Python 3.

Ciao,
 Emmanuele.

On Wed, Apr 11, 2018 at 05:27:49PM +0100, Emmanuele Bassi wrote:
> > From: Emmanuele Bassi 
> >
> > Meson is a next generation build system, and various projects in the
> > larger Linux ecosystem already moved to it — for instance:
> >
> >   - the X11 server
> >   - the X11 protocols repository
> >   - Mesa
> >   - libdrm
> >
> > The added benefit for adding Meson support is that projects using Meson
> > and depending on wayland-protocols can use the subproject functionality
> > to always pull the latest version of the protocols without necessarily
> > updating their build environment.
> > ---
> >  meson.build   | 89 +++
> >  meson_options.txt |  5 +++
> >  2 files changed, 94 insertions(+)
> >  create mode 100644 meson.build
> >  create mode 100644 meson_options.txt
> >
> > diff --git a/meson.build b/meson.build
> > new file mode 100644
> > index 000..c078ff3
> > --- /dev/null
> > +++ b/meson.build
> > @@ -0,0 +1,89 @@
> > +project('wayland-protocols', 'c',
> > +  version: '1.13',
> > +  license: 'MIT',
> > +  meson_version: '>= 0.45.0',
> > +)
> > +
> > +wayland_scanner_dep = dependency('wayland-scanner', required: false)
> > +wayland_scanner_opt = get_option('wayland_scanner')
> > +wayland_scanner_bin = ['wayland-scanner']
> > +
> > +if wayland_scanner_opt != ''
> > +  wayland_scanner_bin += wayland_scanner_opt
> > +endif
> > +
> > +if wayland_scanner_dep.found()
> > +  wayland_scanner_bin += wayland_scanner_dep.get_
> pkgconfig_variable('wayland_scanner')
> > +endif
> > +
> > +wayland_scanner = find_program(wayland_scanner_bin)
> > +
> > +pkgdatadir = join_paths(get_option('datadir'), meson.project_name())
> > +
> > +protocol_files = []
> > +
> > +# name, [version, ...]
> > +unstable_protocols = [
> > +  [ 'pointer-gestures', ['v1',], ],
> > +  [ 'fullscreen-shell', ['v1',], ],
> > +  [ 'linux-dmabuf', ['v1',], ],
> > +  [ 'text-input', ['v1',], ],
> > +  [ 'input-method', ['v1',], ],
> > +  [ 'xdg-shell', ['v5', 'v6',], ],
> > +  [ 'relative-pointer', ['v1',], ],
> > +  [ 'pointer-constraints', ['v1',], ],
> > +  [ 'tablet', ['v1', 'v2',], ],
> > +  [ 'xdg-foreign', ['v1', 'v2',], ],
> > +  [ 'idle-inhibit', ['v1',], ],
> > +  [ 'xwayland-keyboard-grab', ['v1',], ],
> > +  [ 'keyboard-shortcuts-inhibit', ['v1',], ],
> > +  [ 'xdg-output', ['v1',], ],
> > +  [ 'input-timestamps', ['v1',], ],
> > +]
> > +
> > +foreach p: unstable_protocols
> > +  p_name = p[0]
> > +  p_versions = p[1]
> > +  foreach version: p_versions
> > +xml_file = join_paths('unstable', p_name, '@0@-unstable-@1
> @.xml'.format(p_name, version))
> > +protocol_files += [[p_name, files(xml_file)]]
> > +install_data(xml_file, install_dir: join_paths(pkgdatadir,
> 'unstable', p_name))
> > +  endforeach
> > +endforeach
> > +
> > +stable_protocols = [
> > +  'presentation-time',
> > +  'viewporter',
> > +  'xdg-shell',
> > +]
> > +
> > +foreach p_name: stable_protocols
> > +  xml_file = join_paths('stable', p_name, '@0@.xml'.format(p_name))
> > +  protocol_files += [[p_name, files(xml_file)]]
> > +  install_data(xml_file, install_dir: join_paths(pkgdatadir, 'stable',
> p_name))
> > +endforeach
> > +
> > +pkgconfig = import('pkgconfig')
> > +pkgconfig.generate(
> > +  name: meson.project_name(),
> > +  description: 'Wayland protocol files',
> > +  version: meson.project_version(),
> > +  variables: [
> > +'datarootdir=${prefix}/@0@'.format(get_option('datadir')),
> > +'pkgdatadir=${pc_sysrootdir}${datarootdir}/@0@'.format(
> meson.project_name()),
> > +  ],
> > +  install_dir: join_paths(get_option('datadir'), 'pkgconfig'),
> > +)
> > +
> > +scan_test = find_program('tests/scan.sh')
> > +foreach p: protocol_files
> > +  p_name = p[0]
> > +  p_file = p[1]
> > +  test('verify ' + p_name,
> > +scan_test,
> > +args: [ p_file, ],
> > +env: [
> > +  

Re: [PATCH] Add Meson build system

[Jonas Ådahl]

FWIW, I did something similar, here:
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035399.html
because I wanted to add build tests. IIRC there is some bug that I only
fixed locally.


Jonas

On Wed, Apr 11, 2018 at 05:27:49PM +0100, Emmanuele Bassi wrote:
> From: Emmanuele Bassi 
> 
> Meson is a next generation build system, and various projects in the
> larger Linux ecosystem already moved to it — for instance:
> 
>   - the X11 server
>   - the X11 protocols repository
>   - Mesa
>   - libdrm
> 
> The added benefit for adding Meson support is that projects using Meson
> and depending on wayland-protocols can use the subproject functionality
> to always pull the latest version of the protocols without necessarily
> updating their build environment.
> ---
>  meson.build   | 89 +++
>  meson_options.txt |  5 +++
>  2 files changed, 94 insertions(+)
>  create mode 100644 meson.build
>  create mode 100644 meson_options.txt
> 
> diff --git a/meson.build b/meson.build
> new file mode 100644
> index 000..c078ff3
> --- /dev/null
> +++ b/meson.build
> @@ -0,0 +1,89 @@
> +project('wayland-protocols', 'c',
> +  version: '1.13',
> +  license: 'MIT',
> +  meson_version: '>= 0.45.0',
> +)
> +
> +wayland_scanner_dep = dependency('wayland-scanner', required: false)
> +wayland_scanner_opt = get_option('wayland_scanner')
> +wayland_scanner_bin = ['wayland-scanner']
> +
> +if wayland_scanner_opt != ''
> +  wayland_scanner_bin += wayland_scanner_opt
> +endif
> +
> +if wayland_scanner_dep.found()
> +  wayland_scanner_bin += 
> wayland_scanner_dep.get_pkgconfig_variable('wayland_scanner')
> +endif
> +
> +wayland_scanner = find_program(wayland_scanner_bin)
> +
> +pkgdatadir = join_paths(get_option('datadir'), meson.project_name())
> +
> +protocol_files = []
> +
> +# name, [version, ...]
> +unstable_protocols = [
> +  [ 'pointer-gestures', ['v1',], ],
> +  [ 'fullscreen-shell', ['v1',], ],
> +  [ 'linux-dmabuf', ['v1',], ],
> +  [ 'text-input', ['v1',], ],
> +  [ 'input-method', ['v1',], ],
> +  [ 'xdg-shell', ['v5', 'v6',], ],
> +  [ 'relative-pointer', ['v1',], ],
> +  [ 'pointer-constraints', ['v1',], ],
> +  [ 'tablet', ['v1', 'v2',], ],
> +  [ 'xdg-foreign', ['v1', 'v2',], ],
> +  [ 'idle-inhibit', ['v1',], ],
> +  [ 'xwayland-keyboard-grab', ['v1',], ],
> +  [ 'keyboard-shortcuts-inhibit', ['v1',], ],
> +  [ 'xdg-output', ['v1',], ],
> +  [ 'input-timestamps', ['v1',], ],
> +]
> +
> +foreach p: unstable_protocols
> +  p_name = p[0]
> +  p_versions = p[1]
> +  foreach version: p_versions
> +xml_file = join_paths('unstable', p_name, 
> '@0@-unstable-@1@.xml'.format(p_name, version))
> +protocol_files += [[p_name, files(xml_file)]]
> +install_data(xml_file, install_dir: join_paths(pkgdatadir, 'unstable', 
> p_name))
> +  endforeach
> +endforeach
> +
> +stable_protocols = [
> +  'presentation-time',
> +  'viewporter',
> +  'xdg-shell',
> +]
> +
> +foreach p_name: stable_protocols
> +  xml_file = join_paths('stable', p_name, '@0@.xml'.format(p_name))
> +  protocol_files += [[p_name, files(xml_file)]]
> +  install_data(xml_file, install_dir: join_paths(pkgdatadir, 'stable', 
> p_name))
> +endforeach
> +
> +pkgconfig = import('pkgconfig')
> +pkgconfig.generate(
> +  name: meson.project_name(),
> +  description: 'Wayland protocol files',
> +  version: meson.project_version(),
> +  variables: [
> +'datarootdir=${prefix}/@0@'.format(get_option('datadir')),
> +
> 'pkgdatadir=${pc_sysrootdir}${datarootdir}/@0@'.format(meson.project_name()),
> +  ],
> +  install_dir: join_paths(get_option('datadir'), 'pkgconfig'),
> +)
> +
> +scan_test = find_program('tests/scan.sh')
> +foreach p: protocol_files
> +  p_name = p[0]
> +  p_file = p[1]
> +  test('verify ' + p_name,
> +scan_test,
> +args: [ p_file, ],
> +env: [
> +  'SCANNER=@0@'.format(wayland_scanner.path()),
> +],
> +  )
> +endforeach
> diff --git a/meson_options.txt b/meson_options.txt
> new file mode 100644
> index 000..09a8618
> --- /dev/null
> +++ b/meson_options.txt
> @@ -0,0 +1,5 @@
> +option('wayland_scanner',
> +  description: 'The wayland-scanner binary to use',
> +  type: 'string',
> +  value: ''
> +)
> -- 
> 2.17.0
> 
> ___
> 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] Add Meson build system

[Emmanuele Bassi]

From: Emmanuele Bassi 

Meson is a next generation build system, and various projects in the
larger Linux ecosystem already moved to it — for instance:

  - the X11 server
  - the X11 protocols repository
  - Mesa
  - libdrm

The added benefit for adding Meson support is that projects using Meson
and depending on wayland-protocols can use the subproject functionality
to always pull the latest version of the protocols without necessarily
updating their build environment.
---
 meson.build   | 89 +++
 meson_options.txt |  5 +++
 2 files changed, 94 insertions(+)
 create mode 100644 meson.build
 create mode 100644 meson_options.txt

diff --git a/meson.build b/meson.build
new file mode 100644
index 000..c078ff3
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,89 @@
+project('wayland-protocols', 'c',
+  version: '1.13',
+  license: 'MIT',
+  meson_version: '>= 0.45.0',
+)
+
+wayland_scanner_dep = dependency('wayland-scanner', required: false)
+wayland_scanner_opt = get_option('wayland_scanner')
+wayland_scanner_bin = ['wayland-scanner']
+
+if wayland_scanner_opt != ''
+  wayland_scanner_bin += wayland_scanner_opt
+endif
+
+if wayland_scanner_dep.found()
+  wayland_scanner_bin += 
wayland_scanner_dep.get_pkgconfig_variable('wayland_scanner')
+endif
+
+wayland_scanner = find_program(wayland_scanner_bin)
+
+pkgdatadir = join_paths(get_option('datadir'), meson.project_name())
+
+protocol_files = []
+
+# name, [version, ...]
+unstable_protocols = [
+  [ 'pointer-gestures', ['v1',], ],
+  [ 'fullscreen-shell', ['v1',], ],
+  [ 'linux-dmabuf', ['v1',], ],
+  [ 'text-input', ['v1',], ],
+  [ 'input-method', ['v1',], ],
+  [ 'xdg-shell', ['v5', 'v6',], ],
+  [ 'relative-pointer', ['v1',], ],
+  [ 'pointer-constraints', ['v1',], ],
+  [ 'tablet', ['v1', 'v2',], ],
+  [ 'xdg-foreign', ['v1', 'v2',], ],
+  [ 'idle-inhibit', ['v1',], ],
+  [ 'xwayland-keyboard-grab', ['v1',], ],
+  [ 'keyboard-shortcuts-inhibit', ['v1',], ],
+  [ 'xdg-output', ['v1',], ],
+  [ 'input-timestamps', ['v1',], ],
+]
+
+foreach p: unstable_protocols
+  p_name = p[0]
+  p_versions = p[1]
+  foreach version: p_versions
+xml_file = join_paths('unstable', p_name, 
'@0@-unstable-@1@.xml'.format(p_name, version))
+protocol_files += [[p_name, files(xml_file)]]
+install_data(xml_file, install_dir: join_paths(pkgdatadir, 'unstable', 
p_name))
+  endforeach
+endforeach
+
+stable_protocols = [
+  'presentation-time',
+  'viewporter',
+  'xdg-shell',
+]
+
+foreach p_name: stable_protocols
+  xml_file = join_paths('stable', p_name, '@0@.xml'.format(p_name))
+  protocol_files += [[p_name, files(xml_file)]]
+  install_data(xml_file, install_dir: join_paths(pkgdatadir, 'stable', p_name))
+endforeach
+
+pkgconfig = import('pkgconfig')
+pkgconfig.generate(
+  name: meson.project_name(),
+  description: 'Wayland protocol files',
+  version: meson.project_version(),
+  variables: [
+'datarootdir=${prefix}/@0@'.format(get_option('datadir')),
+
'pkgdatadir=${pc_sysrootdir}${datarootdir}/@0@'.format(meson.project_name()),
+  ],
+  install_dir: join_paths(get_option('datadir'), 'pkgconfig'),
+)
+
+scan_test = find_program('tests/scan.sh')
+foreach p: protocol_files
+  p_name = p[0]
+  p_file = p[1]
+  test('verify ' + p_name,
+scan_test,
+args: [ p_file, ],
+env: [
+  'SCANNER=@0@'.format(wayland_scanner.path()),
+],
+  )
+endforeach
diff --git a/meson_options.txt b/meson_options.txt
new file mode 100644
index 000..09a8618
--- /dev/null
+++ b/meson_options.txt
@@ -0,0 +1,5 @@
+option('wayland_scanner',
+  description: 'The wayland-scanner binary to use',
+  type: 'string',
+  value: ''
+)
-- 
2.17.0

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

Basic Weston Questions

[John Frankish]

Sorry to ask such basic questions, but I was unable to find details on:

When you minimize an application window in Weston, where does it go to? How do 
you get it back?

Is it possible to change the date/time format in the top right hand corner of 
the display?

___
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]

More good questions.

On 2018-04-11 11:02 AM, Pekka Paalanen wrote:
> There is still the corner-case of: can removing wl_output global A
> cause the name for wl_output global B to change, but I suppose that
> falls to common sense to not do so strange things.

I suppose I can add a note about this if another protocol revision is
required for other reasons.

> I do wonder, if I used a naming scheme like this:
> 
>   on top: Intel GMA: DVI-D-1: Viewsonic VP171B (S/N: 8764358365)
>   on bottom: GeForce 8800: HDMI-2: HP ZDisplay K99 (S/N: 98728462)
> 
> and then the user reconfigures the output layout, can the compositor
> send updated names to all clients that already have an xdg-output object?

You could do this but it would be exceedingly silly of you considering
that the other xdg_output requests furnish the client with layout
information anyway.

--
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-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
- A client using wlroot's new layer-shell protocol (which will be
  submitted for standardization once we finish proving it with our
  implementation) can do something similar
- Xwayland can name the X11 outputs based on their genuine names rather
  than assigning e.g. XWAYLAND0

--
Drew DeVault
___
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 Wed, 11 Apr 2018 10:16:46 +1000
Peter Hutterer  wrote:

> On Tue, Apr 10, 2018 at 02:01:10PM +0300, Pekka Paalanen wrote:
> > On Mon, 9 Apr 2018 12:54:43 +1000
> > Peter Hutterer  wrote:
> >   
> > > On Fri, Mar 23, 2018 at 02:01:01PM +0200, Pekka Paalanen wrote:  
> > > > From: Pekka Paalanen 
> > > > 
> > > > This is a Wayland protocol extension to allow the calibration of
> > > > touchscreens in Weston.
> > > > 
> > > > See: https://phabricator.freedesktop.org/T7868
> > > > 
> > > > Signed-off-by: Pekka Paalanen 
> > > > ---
> > > >  Makefile.am   |   5 +-
> > > >  protocol/weston-touch-calibration.xml | 320 
> > > > ++
> > > >  2 files changed, 324 insertions(+), 1 deletion(-)
> > > >  create mode 100644 protocol/weston-touch-calibration.xml  
> >   
> > > > +  
> > > > +
> > > > +  This is the global interface for calibrating a touchscreen input
> > > > +  coordinate transformation. It is recommended to make this 
> > > > interface
> > > > +  privileged.
> > > > +
> > > > +  This interface can be used by a client to show a calibration 
> > > > pattern and
> > > > +  receive uncalibrated touch coordinates, facilitating the 
> > > > computation of
> > > > +  a calibration transformation that will align actual touch 
> > > > positions
> > > > +  on screen with their expected coordinates.
> > > > +
> > > > +  Immediately after being bound by a client, the server sends the
> > > > +  touch_device events.
> > > 
> > > s/server/compositor/, in a few more places  
> > 
> > I'm a bit mixed there. I tried to be consistent with "server", but one
> > "compositor" still remained. There are a couple dozen "server".
> > 
> > Is your point that all Wayland spec language should be using
> > "compositor" to talk about the server-side?  
> 
> Yeah, sorry, should've made this clear. 30 years of confusion about X'
> client and server model suggests using 'compositor' and 'client' is
> superior, simply because at least you know one side for sure now :)

I wouldn't be so sure, the misconception that Wayland is a display
server, desktop projects just write their compositors and without
understanding that server=compositor was pretty wide-spread. :-)

At least the client and server model is still the same. Compositor used
to be a client or neither really, and now it is a server, so I could
argue that "compositor" is more confusing than "server". Hence I tend
to talk about a display server nowadays.

But ok, I can follow the precedent and call it "compositor".


> > > > +   An event carries the touch device identification and the 
> > > > associated
> > > > +   output or head (display connector) name.
> > > > +
> > > > +   On platforms using udev, the device identification is the udev 
> > > > DEVPATH.
> > > 
> > > do we want to really set this in stone in the protocol? Also, the DEVPATH
> > > is without /sys, right? Why not make this an open format and let the 
> > > client
> > > figure it out. It's not hard to strcmp for /sys or /dev/input/event in the
> > > client and iirc we have precedence for that in the tablet protocol. or in
> > > libinput for tablets, can't remember now :)  
> > 
> > Yes, I wanted to have a clear, unambgious definition. What udev calls
> > the DEVPATH is the path without /sys. We can revise this decision
> > if there ever arises a need for anything else, but it's still a Weston
> > private protocol for now.
> > 
> > When would one use /dev paths?  
> 
> *shrug*, not sure in this case, just used that as an example here. Point was
> more: prefixing with /sys makes it a lot more identifiable than just using
> the DEVPATH, not least because you can immediately stat that path (or ls, 
> important
> for bug reporters).
> 
> also, udev_device_new_from_syspath() seems to error out if it doesn't start
> with "/sys", so any programmatic user would have to pre-pend /sys anway.

Ok, I can change it to be "DEVPATH prefixed with /sys". Or is SYSPATH a
thing defined by udev? There is udev_device_get_syspath() but I cannot
get 'udevadm info' to print that. Originally I wanted to stick to what
I can see with 'udevadm info'.

> > Btw. are device node and DEVPATH equally racy wrt. device getting
> > replaced with a different one?  
> 
> not 100% sure. Theory is that if you have the DEVPATH you can get the
> devnode through udev and by then all races should've been resolved. If you
> get the device node independently, then you're bound to run into races.

Alright, I'll pay no further thought to device nodes.

> > We could have rules like if it starts with /sys, remove /sys and you
> > have the DEVPATH; if it starts with /dev, it's the device node, and so
> > on, but I don't see the point. So rather than pretending that I cater
> > for other environments, I just rule them out for now.  
> 

RE: Wayland Weston blank screen with drm-backend

[John Frankish]

> > > Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank 
> > > screen on a machine with intel hd4400 graphics when staring with:
> > >
> > > WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id 
> > > -u) weston-launch >weston.log 2>&1
> > > 
> > > X works fine and, a couple of mesa upgrades ago, Weston worked fine 
> > > - full output log attached, any troubleshooting suggestions would be 
> > > appreciated.
> > > 
> > Ah - it seems it is due to using "--with-cairo=glesv2" rather than 
> > "--with-cairo=image", but why?
> > 
> the glesv2 option has been discouraged for years, so no-one tests it.
> It's no surprise it's broken. You can see configure.ac warning you about it 
> since May 2015.
> 
> It only exists so that one could theoretically build the couple demo programs 
> that actually need it. > It's been a wish to rewrite those demos to not need 
> it, since the demos themselves are
> still valuable, but no-one has had the time for it. That's also why the 
> option has not been
> completely removed yet.
> 
Thanks for the explanation :)

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

Re: Wayland Weston blank screen with drm-backend

[Pekka Paalanen]

On Wed, 11 Apr 2018 08:35:22 +
John Frankish  wrote:

> > Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a 
> > machine with intel
> > hd4400 graphics when staring with:
> > 
> > WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u) 
> > weston-launch >weston.log 2>&1
> > 
> > X works fine and, a couple of mesa upgrades ago, Weston worked fine - full 
> > output log attached,
> > any troubleshooting suggestions would be appreciated.
> >   
> Ah - it seems it is due to using "--with-cairo=glesv2" rather than 
> "--with-cairo=image", but why?

Hi,

the glesv2 option has been discouraged for years, so no-one tests it.
It's no surprise it's broken. You can see configure.ac warning you
about it since May 2015.

It only exists so that one could theoretically build the couple demo
programs that actually need it. It's been a wish to rewrite those demos
to not need it, since the demos themselves are still valuable, but
no-one has had the time for it. That's also why the option has not been
completely removed yet.


Thanks,
pq


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

RE: Wayland Weston blank screen with drm-backend

[John Frankish]

> Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a 
> machine with intel
> hd4400 graphics when staring with:
> 
> WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u) 
> weston-launch >weston.log 2>&1
> 
> X works fine and, a couple of mesa upgrades ago, Weston worked fine - full 
> output log attached,
> any troubleshooting suggestions would be appreciated.
> 
Ah - it seems it is due to using "--with-cairo=glesv2" rather than 
"--with-cairo=image", but why?

___
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.
>  
> @@ -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.

So the name needs to be human-friendly, good.

> +
> +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.

Excellent, you already took care of what I just wrote in the previous
email.

> +
> +The name event is sent after creating an xdg_output (see
> +xdg_output_manager.get_xdg_output).

Specifying when the event can be sent or expected, good. It is also
mandatory to send in interface version 2, and consistency rule above
implies that a compositor cannot suddenly change the name.

There is still the corner-case of: can removing wl_output global A
cause the name for wl_output global B to change, but I suppose that
falls to common sense to not do so strange things.

I do wonder, if I used a naming scheme like this:

on top: Intel GMA: DVI-D-1: Viewsonic VP171B (S/N: 8764358365)
on bottom: GeForce 8800: HDMI-2: HP ZDisplay K99 (S/N: 98728462)

and then the user reconfigures the output layout, can the compositor
send updated names to all clients that already have an xdg-output object?

> +  
> +  
> +
> +
>
>  


Thanks,
pq


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

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

[Pekka Paalanen]

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

> Will it address your concerns if I:
> 
> 1. Add a statement clarifying that the names are unique across all
>living wl_outputs and may be reused if the corresponding wl_output
>global is removed
> 2. Add a statement clarifying that persistence of names between sessions
>is only guaranteed for the same hardware & software configuration

Hi Drew,

yes, these statements would be very good. Make sure you refer to
wl_output globals and not just wl_outputs, because the wl_output
protocol objects (wl_proxy) can be, even if should not, left lingering
by a client even when the global has been removed.

I was going to propose that you would actually leave the persistence
explicitly unreliable with a sentence something like this:

"Persistence of the name delivered by an xdg-output is only
guaranteed for the lifetime of the corresponding wl_output
global."

This would imply to clients that if they save the name e.g. in a config
file, they cannot really rely on the same appearing on the next launch.
The reason I'm worrying about this is that otherwise someone is bound
to use the xdg-output name as part of session state restoration.

But your point 2 is good too. I think it is sufficient even for the
session restoration, should anyone (ab)use it for such. It also implies
answers to all the questions I posed, I believe.

Thank you for your effort in perfecting this.


Thanks,
pq


pgp32PsXdmchz.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

[Philipp Kerling]

Hi,

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?
The description mentions "similar behaviors", but it is unclear to me
what you are referring to.

Regards,
Philipp

2018-04-10 (火) の 20:27 -0400 に Drew DeVault さんは書きました:
> 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.
>  
> @@ -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).
> +  
> +  
> +
> +
>
>  
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Same ilm surface on multiple layer support

[Vikas Patil]

Hi Emre Ucan,

Thanks a lot for your quick response. I am able to show same surface on two
layers now. I have taken following two commit to weston 1.11.0. Attached
here same as  patch to weston 1.11.0.

"5e8d55da698e58"
"67bd21232fa549"

However if I use any of the below commands to analyze then it is not
exiting and I need to prress "CTRl+C" to come out from command. Do you know
if this is the normal behavior or some fix is available for this ?

root@linux-a1 :~# LayerManagerControl analyze surface 10
^C

root@ linux-a1 :~# LayerManagerControl get scene
screen 0 (0x0)
---
- resolution:   x=800, y=480
- hardware layer count: 0
- layer render order:   1000(0x3e8), 2000(0x7d0),

layer 1000 (0x3e8)
---
- created by pid:   0
- original size:x=400, y=480
- destination region:   x=0, y=0, w=400, h=480
- source region:x=0, y=0, w=400, h=480
- orientation:  0 (up is top)
- opacity:  1
- visibility:   1
- type: 0 (unknown)
^C

root@linux-a1:~# LayerManagerControl get layer 1000
layer 1000 (0x3e8)
---
- created by pid:   0
- original size:x=400, y=480
- destination region:   x=0, y=0, w=400, h=480
- source region:x=0, y=0, w=400, h=480
- orientation:  0 (up is top)
- opacity:  1
- visibility:   1
- type: 0 (unknown)
^C

root@orinoco-9939-a1:~# LayerManagerControl get surface 10
surface 10 (0xa)
---
- created by pid:   821
- original size:  x=800, y=480
- destination region: x=0, y=0, w=400, h=480
- source region:  x=0, y=0, w=800, h=480
- orientation:0 (up is top)
- opacity:1
- visibility: 1
- pixel format:   0 (R-8)
- native surface: 0
- counters:   frame=0, draw=0, update=0
^C


Also following commands worked successfully.


LayerManagerControl get screen 0
LayerManagerControl get layer 2000
LayerManagerControl get layers
LayerManagerControl get surfaces

I used following commands to setup  and test

export XDG_RUNTIME_DIR=/var/run/root/1000

LayerManagerControl create layer 1000 400 480
LayerManagerControl set layer 1000 visibility 1
LayerManagerControl set layer 1000 destination region 0 0 400 480

LayerManagerControl create layer 2000 400 480
LayerManagerControl set layer 2000 visibility 1
LayerManagerControl set layer 2000 destination region 400 0 400 480

LayerManagerControl set screen 0 render order 1000,2000

EGLWLMockNavigation &
LayerManagerControl add surface 10 to layer 1000
LayerManagerControl add surface 10 to layer 2000
LayerManagerControl set surface 10 visibility 1
LayerManagerControl set surface 10 source region 0 0 800 480
LayerManagerControl set surface 10 destination region 0 0 400 480

Best Regards,
Vikash

On Tue, Apr 10, 2018 at 7:43 PM, Ucan, Emre (ADITG/ESB) <
eu...@de.adit-jv.com> wrote:

> Hi Vikas,
>
>
>
> This patch “5e8d55da698e58”  enabled the feature. It is part of weston
> 1.12 release.
>
>
>
> Best regards
>
> *Emre Ucan*
> Engineering Software Base (ADITG/ESB)
>
> Tel. +49 5121 49 6937
>
> *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
> *On Behalf Of *Vikas Patil
> *Sent:* Dienstag, 10. April 2018 14:58
> *To:* genivi-ivi-layer-managem...@lists.genivi.org; Mizuno, Wataru
> (ADITJ/SWG); wayland mailing list
> *Subject:* Same ilm surface on multiple layer support
>
>
>
> +Subject
>
> Dear All,
>
> We are facing issue when we are trying to add same surface to multiple
> layers. When we try to attach surface to another layer, it is getting
> detached from the earlier layer.
>
> We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
> on TI's Soc.
>
> Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
> in newer version and can it be ported to 1.11.0 ? or Is there any other way
> to show same surface on multiple layers?
>
> I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].
>
>
>
> *"Currently 1 layer can be only on 1 screen, and 1 surface can be only on 1 
> layer, we are planning to relax this limitation And allow 1 surface to be on 
> many layers but we would need to break the ABI and change the  ivi-controller 
> protocol."*
>
> [1] https://lists.genivi.org/pipermail/genivi-ivi-layer-
> management/2016-October/005416.html
>
>
>
> Thanking you in advance.
>
>
>
> Best Regards,
>
> Vikash
>


0001-ivi-shell-introduce-ivi_layout_view.patch
Description: Binary data


0001-ivi-shell-remove-ivi_layout_get_weston_view.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel