Re: Floating windows in input-method

[Silvan Jegen]

Hi

Simon Ser  wrote:
> Hi Dorota,
> 
> On Sunday, December 15, 2019 7:55 PM, Dorota Czaplejewicz 
>  wrote:
> 
> > Hi all,
> >
> > in order to give this change more traction, I've been thinking about
> > slimming down the protocol, and removing floating windows from this
> > revision.
> >
> > This would make the protocol easier to implement, and since we
> > already have an implementation missing this feature in wlroots, also
> > effectively verified. We've been successfully using the protocol on
> > the Librem 5, and completion windows seem like something possible to
> > mimic using a protocol like layer-shell, and in the phone case, this
> > would be the desirable way to do it.
> >
> > Since floating windows are usually used for CJK languages on the
> > desktop, can I get some opinions? Do you think the protocol would be
> > useful and an improvement over the v1 even if it didn't initially
> > include floating windows?
> 
> I think this is a good idea.
> 
> Doing this would ease protocol review and make it so the implementation
> matches the protocol. The extra floating window bits can be added
> later anyway, and we'll be able to discuss what's the best way to
> implement them.

Would the floating windows be added in a new version of the input-method
protocol or do you think a new protocol would be used for that?

As Dorota mentioned, for CJK languages those are very
important. Unfortunately I didn't get very far trying to implement a
version of the input_popup [0][1] but I would like to know where their
protocol should be added in your opinion.


Cheers,

Silvan


[0] https://github.com/Shugyousha/wlroots/commits/popupsurface
[1] 
https://lists.sr.ht/~sircmpwn/public-inbox/%3C2DLX6MQ13DS0R.25O72Q0XN9BGC%40homearch.localdomain%3E


> Btw, we are now using GitLab for wayland-protocols development: feel
> free to submit your patch there (and potentially your earlier pending
> patches too!).
> 
> Thanks,
> 
> Simon
> 
> > Thanks,
> > Dorota Czaplejewicz
> >
> > On Thu, 4 Oct 2018 20:00:13 +
> > Dorota Czaplejewicz dorota.czaplejew...@puri.sm wrote:
> >
> > > This protocol is based on v1, current text-input-v3, and wl_keyboard 
> > > version 6.
> > > The pieces passing data relevant to the application on the other side of 
> > > the compositor are a mirror copy of text-input-v3 events and requests.
> > > Compared to input-method-v1:
> > >
> > > -   assumes that once preedit is displayed, no selection can be active, 
> > > removing some selection handling
> > > -   follow text-input and removes language indicators
> > > -   explicitly attaches to seats
> > > -   removes "commit" text which would replace the preedit string 
> > > automatically in case it wasn't "confirmed" (whatever it means)
> > > -   adds double-buffering in the same places as text-input-v3
> > > -   drops input_method_context and places its functionality directly in 
> > > input_method
> > > -   removes the ability to move the cursor position outside of preedit. 
> > > It still allows to delete a larger chunk of text and replace it with a 
> > > preedit
> > > -   doesn't allow for sending of keyboard events to the compositor
> > > -   doesn't define any surfaces except for a special 
> > > compositor-positioned popup
> > >
> > > Hi,
> > > continuing the RFC, I think this protocol is actually workable now, and 
> > > I'm sending this with the PATCH qualifier.
> > > The practical verification came in the form of a partial wlroots 
> > > implementation [0]. The formal issues (chiefly stemming from copy-pasting 
> > > things at night) have been pointed out to me by Simon, and corrected.
> > > The major unverified parts are keyboard grabs and popup surfaces, which I 
> > > will verify next.
> > > Changes compared to the RFC:
> > >
> > > -   fixed so many confusing typos
> > > -   renamed preedit_text request to set_preedit_text
> > > -   described what happens when things get destroyed
> > > -   defined the role of input_popup sorface and forbade it from being 
> > > deleted
> > > -   copied wl_keyboard to serve as the keyboard grab interface
> > >
> > > I hope you can help me find the remaining issues and turn this interface 
> > > into reality!
> > > Cheers,
> > > Dorota Czaplejewicz
> > > Makefile.am | 1 +
> > > unstable/input-method/input-method-unstable-v2.xml | 490 
> > > +
> > > 2 files changed, 491 insertions(+)
> > > create mode 100644 unstable/input-method/input-method-unstable-v2.xml
> > > diff --git a/Makefile.am b/Makefile.am
> > > index 6394e26..f3b9f80 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -7,6 +7,7 @@ unstable_protocols = \
> > > 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/input-method/input-method-unstable-v2.xml \
> > > unstable/xdg-shell/xdg-shell-unstable-v5.xml \
> > > unstable/xdg-shell/xdg-shell-unstable-v6.xml \
> > >

Re: [RFC wayland-protocols] input-method: Add zwp-input-method-v2

[Silvan Jegen]

Hi

Just some typos I found (for now):

On Mon, Aug 06, 2018 at 03:00:21PM +0200, Dorota Czaplejewicz wrote:
> This protocol is based on v1, and current text-input-v3.
> 
> The pieces passing data relevant to the application on the other side of the 
> compositor are a mirror copy of text-input-v3 events and requests.
> 
> Compared to input-method-v1:
> - assumes that once preedit is displayed, no selection can be active, 
> removing some selection handling
> - follow text-input and removes language indicators
> - explicitly attaches to seats
> - removes "commit" text which would replace the preedit string automatically 
> in case it wasn't "confirmed" (whatever it means)
> - adds double-buffering in the same places as text-input-v3
> - drops input_method_context and places its functionality directly in 
> input_method
> - removes the ability to move the cursor position outside of preedit. It 
> still allows to delete a larger chunk of text and replace it with a preedit
> - doesn't allow for sending of keyboard events to the compositor
> - Doesn't define any surfaces except for a special compositor-positioned popup
> ---
> Hi,
> 
> the third item on the path to well-supported virtual keyboard experience 
> under Wayland comes from Purism. This one allows the compositor to delegate 
> text input and composition duties to an application instead of handling it 
> itself. Input-method-delegating compositor would typically become only a 
> broker between the input method client and other applications.
> 
> I took the existing input-method protocol, and after dissecting it with the 
> help of wlroots developers, I came up with an improved version, which is 
> attached for your (re)viewing pleasure.
> 
> A large part of this protocol was taken from recent text-input-v3, and some 
> description text was improved. Still, the protocol has a couple of rough 
> edges, which is why it's titled RFC and not a patch.
> 
> The issues I have had most trouble with are related to the handling of 
> keyboard grabs. These are meant to allow traditional, keyboard-based input 
> methods, to take over keyboard input in order to compose text in a different 
> way.
> 
> First, keyboard grabs are defined as unreliable. I'm not sure whether this is 
> the right choice, but given that making them more reliable seems rather 
> complicated, this is the default one.
> 
> In addition, handling the keyboard events themselves is troublesome, because 
> an input method, even if it has a surface, is not meant to have keyboard 
> focus while it's in operation. Returning wl_keyboard as new_id seems not to 
> be possible due to versioning. Should the request make an existing 
> wl_keyboard instance change behaviour? Or perhaps there should be a new 
> zwp_input_method_keyboard mimicking the wl_keyboard interface?
> 
> I'm interested in your opinions.
> 
> Thank you,
> Dorota Czaplejewicz 
> 
>  Makefile.am|   1 +
>  unstable/input-method/input-method-unstable-v2.xml | 403 
> +
>  2 files changed, 404 insertions(+)
>  create mode 100644 unstable/input-method/input-method-unstable-v2.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 6394e26..f3b9f80 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -7,6 +7,7 @@ unstable_protocols =  
> \
>   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/input-method/input-method-unstable-v2.xml  
> \
>   unstable/xdg-shell/xdg-shell-unstable-v5.xml
> \
>   unstable/xdg-shell/xdg-shell-unstable-v6.xml
> \
>   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> \
> diff --git a/unstable/input-method/input-method-unstable-v2.xml 
> b/unstable/input-method/input-method-unstable-v2.xml
> new file mode 100644
> index 000..8cf8e29
> --- /dev/null
> +++ b/unstable/input-method/input-method-unstable-v2.xml
> @@ -0,0 +1,403 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +Copyright © 2017, 2018 Red Hat, Inc.
> +Copyright © 2018   Purism SPC
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including 

Re: [PATCH] scanner: allow referencing foreign enums

[Silvan Jegen]

Hi

On Fri, May 25, 2018 at 05:24:41PM -0400, Simon Ser wrote:
> It's already possible to reference foreign interfaces, so it
> should also be possible to reference foreign enums.
> 
> Signed-off-by: Simon Ser <cont...@emersion.fr>
> ---
>  src/scanner.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)

It looks good to me and I can confirm that this works as intended. If
no solution allowing for the passing of reference protocols is desired,
this should be applied.

Reviewed-by: Silvan Jegen <s.je...@gmail.com>


Cheers,

Silvan

> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 1737911..205c28a 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -894,14 +894,9 @@ verify_arguments(struct parse_context *ctx,
>   e = find_enumeration(ctx->protocol, interface,
>a->enumeration_name);
>  
> - if (e == NULL)
> - fail(>loc,
> -  "could not find enumeration %s",
> -  a->enumeration_name);
> -
>   switch (a->type) {
>   case INT:
> - if (e->bitfield)
> + if (e && e->bitfield)
>   fail(>loc,
>"bitfield-style enum must only be 
> referenced by uint");
>   break;
> -- 
> 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

Re: [PATCH] virtual-keyboard: Add new virtual keyboard protocol

[Silvan Jegen]

Hi

Just a typo I found below.

On Thu, May 17, 2018 at 06:53:10PM +0200, Dorota Czaplejewicz wrote:
> Provides the ability to emulate keyboards by
> applications. Complementary to input-method protocol.
> 
> The interface is a mirror copy of wl_keyboard, with removed serials,
> and added seat binding.
> ---
> 
> This proposal is another one needed by Purism to support on screen
> keyboards on a phone screen.
> 
> Virtual-keyboard is a protocol to let applications send arbitrary
> keyboard events. The need for this protocol comes from the fact
> that the input-method protocol combines two separate input
> responsibilities. It currently deals both with text input and raw
> keyboard events. I hope to split input-method along this line into
> virtual-keyboard and the rest of input-method. I'm going to submit the
> updated input-method for review soon.
> 
> Applications should be able to control both interfaces at the same
> time. A screen keyboard supporting autocorrect (input-method) still
> wants to send arrow keys (vityual-keyboard) correctly. Because of
> this, both kinds of events at minimum must be sent to the same seat. I
> made the seat binding explicitly done by the application, taking
> inspiration from text-input protocol, which assumes per-seat binding
> as well.
> 
> Input welcome.
> 
> Cheers,
> Dorota
> 
>  Makefile.am|  1 +
>  .../virtual-keyboard-unstable-v1.xml   | 97 
> ++
>  2 files changed, 98 insertions(+)
>  create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..51a47a2 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  \
> + nstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml   \

There is a 'u' missing in the beginning of the file location.


Cheers,

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

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

[Silvan Jegen]

On Thu, May 10, 2018 at 11:46:32AM +0200, Dorota Czaplejewicz wrote:
> On Thu, 10 May 2018 11:43:12 +0200
> Dorota Czaplejewicz <dorota.czaplejew...@puri.sm> wrote:
> 
> > On Tue, 08 May 2018 07:07:24 +
> > Silvan Jegen <s.je...@gmail.com> wrote:
> > 
> > > On Mon, May 7, 2018 at 5:11 AM Joshua Watt <jpewhac...@gmail.com> wrote:  
> > > > IMHO, if you are doing UTF-8 (which you should), you should *always*
> > > > specify any offset in the string as a byte offset. I have a few
> > > > reasons for this justification:
> > > 
> > > I agree with this as well. I thought some more about how to spell out my
> > > gut feeling on this matter in more technical terms.
> > > 
> > > UTF-8 is a byte (sequence) representation of Unicode code points. This
> > > indicates to me that an offset within an UTF-8-encoded string should also
> > > be given in bytes. Specifying the offset in Unicode points mixes the
> > > abstraction of the Unicode code point with (one of) its representations as
> > > a byte sequence. This is reflected in the fact that an offset in Unicode
> > > code points is not applicable to the UTF-8 string without first processing
> > > the string.
> > > 
> > > Unicode code points do not give us that much either since what we most
> > > likely want are grapheme clusters anyway (which, like any more advanced
> > > Unicode processing, should be handled by a specialised library):
> > > http://utf8everywhere.org/#myth.strlen
> > > 
> > > 
> > > Cheers,
> > > 
> > > Silvan  
> > 
> > This message made me feel obliged to turn my own gut feeling into
> > words. This is not to be construed as an argument, but more of an
> > explanation.
> > 
> > I view wayland protocols as rather high level: their responsibility
> > is to specify the type and the purpose of the data they are
> > transporting. In this case, the data is a Unicode string, and the
> > purpose is display. Or, the data is a number and the purpose is
> > indexing.
> > 
> > I think that when a protocol starts to specify the type and purpose,
> > it can no longer be thought as high level. In this view, indexing a
> > Unicode string in terms of bytes would be akin to indexing any other
> > vector of Foo in bytes. (I didn't actually check if there is any
> > other vector, or bytes type available in wayland).
> > 
> > As you noted, there is some mixing between abstraction levels in
> > the protocol. Hardcoding that it's not *just* Unicode, but also the
> > particular encoding (UTF-8) eliminates problems with byte indexing
> > we would have encountered if we decided to use things like Punycode
> > (München => Mnchen-3ya). Knowing that it's always UTF-8 allows the
> > protocol to use a tailoring indexing scheme. While I consider this a
> > layer-breaking hack, nevertheless, this property partially counters
> > the above reasoning.
> > 
> > * * *
> > 
> > To be honest, neither Unicode code points nor graphemes nor clusters
> > are what we're truly looking for here. To understand what I mean, I
> > recommend to play with this grapheme cluster:
> > 
> > नमस्ते
> > 
> > According to the Rust book [0], it's composed of 6 code points:
> > ['न', 'म', 'स', '्', 'त', 'े'], but moving the cursor
> > around, I would be led to believe it's 4 "pieces" long only.
> > 
> > Cheers,
> > Dorota
> > 
> > [0] https://doc.rust-lang.org/book/second-edition/ch08-02-strings.html
> 
> On a second thought, perhaps graphemes are actually the relevant thing here...

Yes, that's also mentioned in the rust book:

https://doc.rust-lang.org/book/second-edition/ch08-02-strings.html#bytes-and-scalar-values-and-grapheme-clusters-oh-my

and what I mentioned in my mail.

I agree with what is mentioned in http://utf8everywhere.org/#myth.strlen
which is that Unicode code points are almost never what people making
use of the protocol would want:

"Yet, the number of code points in it is irrelevant to almost any software
engineering task, with perhaps the only exception of converting the
string to UTF-32"

So instead just specifying a byte offset (thus not mixing layers of
abstraction) and leaving more specialized Unicode handling (if desired by
the client) to specialized libraries seems like the best way to go.


Cheers,

Silvan


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

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

[Silvan Jegen]

On Mon, May 7, 2018 at 5:11 AM Joshua Watt  wrote:
> IMHO, if you are doing UTF-8 (which you should), you should *always*
> specify any offset in the string as a byte offset. I have a few
> reasons for this justification:

I agree with this as well. I thought some more about how to spell out my
gut feeling on this matter in more technical terms.

UTF-8 is a byte (sequence) representation of Unicode code points. This
indicates to me that an offset within an UTF-8-encoded string should also
be given in bytes. Specifying the offset in Unicode points mixes the
abstraction of the Unicode code point with (one of) its representations as
a byte sequence. This is reflected in the fact that an offset in Unicode
code points is not applicable to the UTF-8 string without first processing
the string.

Unicode code points do not give us that much either since what we most
likely want are grapheme clusters anyway (which, like any more advanced
Unicode processing, should be handled by a specialised library):
http://utf8everywhere.org/#myth.strlen


Cheers,

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

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

[Silvan Jegen]

On Sun, May 06, 2018 at 10:37:57PM +0200, Dorota Czaplejewicz wrote:
> On Sat, 5 May 2018 13:37:44 +0200
> Silvan Jegen <s.je...@gmail.com> wrote:
> 
> > On Sat, May 05, 2018 at 11:09:10AM +0200, Dorota Czaplejewicz wrote:
> > > On Fri, 4 May 2018 22:32:15 +0200
> > > Silvan Jegen <s.je...@gmail.com> wrote:
> > >   
> > > > On Thu, May 03, 2018 at 10:46:47PM +0200, Dorota Czaplejewicz wrote:  
> > > > > On Thu, 3 May 2018 21:55:40 +0200
> > > > > Silvan Jegen <s.je...@gmail.com> wrote:
> > >
> > > [...]
> > >
> > > In the end, I'm not an expert in that area either - perhaps treating
> > > client side strings as UTF-8 buffers makes sense, but at the moment
> > > I'm still leaning towards the code point abstraction.  
> > 
> > Someone (™) should probably implement a client making use of the protocol
> > to see what the real world impact of this protocol change would be.
> > 
> > The editor in the weston project uses pango for its text layout:
> > 
> > https://cgit.freedesktop.org/wayland/weston/tree/clients/editor.c#n824
> > 
> > so it would have to parse the UTF-8 string twice. The same is most likely
> > true for all programs using GTK...
> > 
> > 
> 
> I made an attempt to dig deeper, and while I stopped short of becoming
> this Someone for now, I gathered what I think are some important
> results.
> 
> First, the state of the libraries. There's a lot of data I gathered,
> so I'll keep this section rather dense. First, another contender
> for the title of text layout library, and that one uses code points
> exclusively:
> 
> https://github.com/silnrsi/graphite/blob/master/include/graphite2/Segment.h 
> `gr_make_seg`
> 
> https://github.com/silnrsi/graphite/blob/master/tests/examples/simple.c
> 
> Afterwards, I focused on GTK and Qt. As an input method plugin
> developer, I looked at the IM interfaces and internal data structures
> they expose. The results were not that clear - no mention of "code
> points", some references to "bytes", many to "characters" (not
> "chars"). What is certain is that there's a lot of converting going on

Yes, it's very unfortunate that a lot of developers do not strife for
more clarity and precision in terminology when processing text.


> behind the scenes anyway. First off, GTK seems to be moving away from
> bytes, judging by the comments:
> 
> gtk 3.22 (`gtkimcontext.c`)
> 
> `gtk_im_context_delete_surrounding`
> 
> > * Asks the widget that the input context is attached to to delete
> > * characters around the cursor position by emitting the
> > * GtkIMContext::delete_surrounding signal. Note that @offset and @n_chars
> > * are in characters not in bytes which differs from the usage other
> > * places in #GtkIMContext.
> 
> `gtk_im_context_get_preedit_string`
> 
> > * @cursor_pos: (out): location to store position of cursor (in characters)
> > *  within the preedit string.  
> 
> `gtk_im_context_get_surrounding`
> 
> > * @cursor_index: (out): location to store byte index of the insertion
> > *cursor within @text.
> 
> gtkEntry seems to store things internally as characters.

They mention "characters" but what they most likely mean are Unicode
code points.

One would think they would try to keep their APIs consistent but that
doesn't seem to be the case.


> While GTK using code points internally is not a proof of anything,
> it's a suggestion that there is a reason not to use bytes.
> 
> Then, Qt, from https://doc.qt.io/qt-5/qinputmethodevent.html#setCommitString
> 
> > replaceLength specifies the number of characters to be replaced
> 
> a confirmation that "characters" means "code points" comes from
> https://doc.qt.io/qt-5/qlineedit.html#cursorPosition-prop . The value
> reported when "æþ|" is displayed is 2.

https://doc.qt.io/qt-5/qstring.html

Qt uses UTF-16 internally so they *could* also be counting "QChars"
which are 16-bit (assuming the position is 0 indexed):

Python 3.6.5 (default, Apr 14 2018, 13:17:30)
[GCC 7.3.1 20180406] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> "æþ"
'æþ'
>>> "æþ".encode("utf-16")
b'\xff\xfe\xe6\x00\xfe\x00'

If they are really doing that you would only notice it with characters
outside of the BMP because:

"(Unicode characters with code values above 65535 are stored using
surrogate pairs, i.e., two consecutive QChars.)"

I think everybody agrees that (Unicode) text handling is a

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

[Silvan Jegen]

On Sat, May 05, 2018 at 11:09:10AM +0200, Dorota Czaplejewicz wrote:
> On Fri, 4 May 2018 22:32:15 +0200
> Silvan Jegen <s.je...@gmail.com> wrote:
> 
> > On Thu, May 03, 2018 at 10:46:47PM +0200, Dorota Czaplejewicz wrote:
> > > On Thu, 3 May 2018 21:55:40 +0200
> > > Silvan Jegen <s.je...@gmail.com> wrote:
> > >   
> > > > On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz wrote:  
> > > > > On Thu, 3 May 2018 20:47:27 +0200
> > > > > Silvan Jegen <s.je...@gmail.com> wrote:
> > > > > 
> > > > > > Hi Dorota
> > > > > > 
> > > > > > Some comments and typo fixes below.
> > > > > > 
> > > > > > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz 
> > > > > > wrote:
> > > > > > > +  Text is valid UTF-8 encoded, indices and lengths are in 
> > > > > > > code points. If a
> > > > > > > +  grapheme is made up of multiple code points, an index 
> > > > > > > pointing to any of
> > > > > > > +  them should be interpreted as pointing to the first one.   
> > > > > > >
> > > > > > 
> > > > > > That way we make sure we don't put the cursor/anchor between bytes 
> > > > > > that
> > > > > > belong to the same UTF-8 encoded Unicode code point which is nice. 
> > > > > > It
> > > > > > also means that the client has to parse all the UTF-8 encoded 
> > > > > > strings
> > > > > > into Unicode code points up to the desired cursor/anchor position
> > > > > > on each "preedit_string" event. For each "delete_surrounding_text" 
> > > > > > event
> > > > > > the client has to parse the UTF-8 sequences before and after the 
> > > > > > cursor
> > > > > > position up to the requested Unicode code point.
> > > > > > 
> > > > > > I feel like we are processing the UTF-8 string already in the
> > > > > > input-method. So I am not sure that we should parse it again on the
> > > > > > client side. Parsing it again would also mean that the client would 
> > > > > > need
> > > > > > to know about UTF-8 which would be nice to avoid.
> > > > > > 
> > > > > > Thoughts?
> > > > > 
> > > > > The client needs to know about Unicode, but not necessarily about
> > > > > UTF-8. Specifying code points is actually an advantage here, because
> > > > > byte offsets are inherently expressed relative to UTF-8. By counting
> > > > > with code points, client's internal representation can be UTF-16 or
> > > > > maybe even something else.
> > > > 
> > > > Maybe I am misunderstanding something but the protocol specifies that
> > > > the strings are valid UTF-8 encoded and the cursor/anchor offsets into
> > > > the strings are specified in Unicode points. To me that indicates that
> > > > the application *has to parse* the UTF-8 string into Unicode points
> > > > when receiving the event otherwise it doesn't know after which Unicode
> > > > point to draw the cursor. Of course the application can then decide to
> > > > convert the UTF-8 string into another encoding like UTF-16 for internal
> > > > processing (for whatever reason) but that doesn't change the fact that
> > > > it still would have to parse the incoming UTF-8 (and thus know about
> > > > UTF-8).
> > > >   
> > > Can you see any way to avoid parsing UTF-8 in order to draw the
> > > cursor? I tried to come up with a way to do that, but even with
> > > specifying byte strings, I believe that calculating the position of
> > > the cursor - either in pixels or in glyphs - requires full parsing of
> > > the input string.  
> > 
> > Yes, I don't think it's avoidable either. You just don't have to do
> > it twice if your text rendering library consumes UTF-8 strings with
> > byte-offsets though. See my response below.
> > 
> > 
> > > > > There's no avoiding the parsing either. What the application cares
> > > > > about is that the cursor falls between glyphs. The application cannot
> > > > > know that in all cases. Unicode allows the same sequence to be
> &g

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

[Silvan Jegen]

On Thu, May 03, 2018 at 10:46:47PM +0200, Dorota Czaplejewicz wrote:
> On Thu, 3 May 2018 21:55:40 +0200
> Silvan Jegen <s.je...@gmail.com> wrote:
> 
> > On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz wrote:
> > > On Thu, 3 May 2018 20:47:27 +0200
> > > Silvan Jegen <s.je...@gmail.com> wrote:
> > >   
> > > > Hi Dorota
> > > > 
> > > > Some comments and typo fixes below.
> > > > 
> > > > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:  
> > > > > +  Text is valid UTF-8 encoded, indices and lengths are in code 
> > > > > points. If a
> > > > > +  grapheme is made up of multiple code points, an index pointing 
> > > > > to any of
> > > > > +  them should be interpreted as pointing to the first one.
> > > > 
> > > > That way we make sure we don't put the cursor/anchor between bytes that
> > > > belong to the same UTF-8 encoded Unicode code point which is nice. It
> > > > also means that the client has to parse all the UTF-8 encoded strings
> > > > into Unicode code points up to the desired cursor/anchor position
> > > > on each "preedit_string" event. For each "delete_surrounding_text" event
> > > > the client has to parse the UTF-8 sequences before and after the cursor
> > > > position up to the requested Unicode code point.
> > > > 
> > > > I feel like we are processing the UTF-8 string already in the
> > > > input-method. So I am not sure that we should parse it again on the
> > > > client side. Parsing it again would also mean that the client would need
> > > > to know about UTF-8 which would be nice to avoid.
> > > > 
> > > > Thoughts?  
> > > 
> > > The client needs to know about Unicode, but not necessarily about
> > > UTF-8. Specifying code points is actually an advantage here, because
> > > byte offsets are inherently expressed relative to UTF-8. By counting
> > > with code points, client's internal representation can be UTF-16 or
> > > maybe even something else.  
> > 
> > Maybe I am misunderstanding something but the protocol specifies that
> > the strings are valid UTF-8 encoded and the cursor/anchor offsets into
> > the strings are specified in Unicode points. To me that indicates that
> > the application *has to parse* the UTF-8 string into Unicode points
> > when receiving the event otherwise it doesn't know after which Unicode
> > point to draw the cursor. Of course the application can then decide to
> > convert the UTF-8 string into another encoding like UTF-16 for internal
> > processing (for whatever reason) but that doesn't change the fact that
> > it still would have to parse the incoming UTF-8 (and thus know about
> > UTF-8).
> > 
> Can you see any way to avoid parsing UTF-8 in order to draw the
> cursor? I tried to come up with a way to do that, but even with
> specifying byte strings, I believe that calculating the position of
> the cursor - either in pixels or in glyphs - requires full parsing of
> the input string.

Yes, I don't think it's avoidable either. You just don't have to do
it twice if your text rendering library consumes UTF-8 strings with
byte-offsets though. See my response below.


> > > There's no avoiding the parsing either. What the application cares
> > > about is that the cursor falls between glyphs. The application cannot
> > > know that in all cases. Unicode allows the same sequence to be
> > > displayed in multiple ways (fallback):
> > > 
> > > https://unicode.org/emoji/charts/emoji-zwj-sequences.html
> > > 
> > > One could make an argument that byte offsets should never be close
> > > to ZWJ characters, but I think this decision is better left to the
> > > application, which knows what exactly it is presenting to the user.  
> > 
> > The idea of the previous version of the protocol (from my understanding)
> > was to make sure that only valid UTF-8 and valid byte-offsets (== not
> > falling between bytes of a Unicode code point) into the string will be
> > sent to the client. If you just get a byte-offset into a UTF-8 encoded
> > string you trust the sender to honor the protocol and thus you can just
> > pass the UTF-8 encoded string unprocessed to your text rendering library
> > (provided that the library supports UTF-8 strings which is what I am
> > assuming) without having to parse the UTF-8 string into Unicode code
> > points.
> > 

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

[Silvan Jegen]

On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz wrote:
> On Thu, 3 May 2018 20:47:27 +0200
> Silvan Jegen <s.je...@gmail.com> wrote:
> 
> > Hi Dorota
> > 
> > Some comments and typo fixes below.
> > 
> > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:
> > > 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.
> > > - All state is double-buffered, with specified state.
> > > - Use Unicode codepoints to measure strings.
> > > 
> > > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejew...@puri.sm>
> > > Signed-off-by: Carlos Garnacho <carl...@gnome.org>
> > > ---
> > > This is the next update coming from Purism to perfect the text input 
> > > protocol.
> > > 
> > > The following changes added on top of PATCHv3:
> > > 
> > > - Fixed whitespaces.
> > > - Removed enable flags - the same information can be gathered from
> > > the first requests after enter.
> > > - Changed offsets inside UTF-8 strings to use Unicode character
> > > counts in order to remove the possibility of communicating invalid
> > > state.
> > > - Specified the exact lifetime of double-buffered state, and initial 
> > > values.
> > > - Made changes requested by the IM double-buffered.
> > > 
> > > Some questions remain open. One is: how to specify how much text
> > > to capture in set_surrounding_text, and how often to update?
> > > 
> > > A possible change that I decided against for now is to replace
> > > enable/disable events by create/destroy of a new object, which
> > > would make more state lifetimes encoded in the protocol.
> > > 
> > > After reading a blog post on fcitx [0], I got the impression that
> > > letting the compositor know some persistent ID of a text edit
> > > instance could be useful, however I'm not sure what the use cases
> > > are.
> > > 
> > > As always, I'm happy to hear feedback.
> > > 
> > > Cheers,
> > > Dorota Czaplejewicz
> > > 
> > > [0] 
> > > https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/
> > > 
> > >  Makefile.am|   1 +
> > >  unstable/text-input/text-input-unstable-v3.xml | 362 
> > > +
> > >  2 files changed, 363 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..ed5204f
> > > --- /dev/null
> > > +++ b/unstable/text-input/text-input-unstable-v3.xml
> > > @@ -0,0 +1,362 @@
> > > +
> > > +
> > > +
> > > +  
> > > +Copyright © 2012, 2013 Intel Corporation
> > > +Copyright © 2015, 2016 Jan Arne Petersen
> > > +Copyright © 2017, 2018 Red Hat, Inc.
> > > +Copyrigh

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

[Silvan Jegen]

Hi Dorota

Some comments and typo fixes below.

On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:
> 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.
> - All state is double-buffered, with specified state.
> - Use Unicode codepoints to measure strings.
> 
> Signed-off-by: Dorota Czaplejewicz 
> Signed-off-by: Carlos Garnacho 
> ---
> This is the next update coming from Purism to perfect the text input protocol.
> 
> The following changes added on top of PATCHv3:
> 
> - Fixed whitespaces.
> - Removed enable flags - the same information can be gathered from the first 
> requests after enter.
> - Changed offsets inside UTF-8 strings to use Unicode character counts in 
> order to remove the possibility of communicating invalid state.
> - Specified the exact lifetime of double-buffered state, and initial values.
> - Made changes requested by the IM double-buffered.
> 
> Some questions remain open. One is: how to specify how much text to capture 
> in set_surrounding_text, and how often to update?
> 
> A possible change that I decided against for now is to replace enable/disable 
> events by create/destroy of a new object, which would make more state 
> lifetimes encoded in the protocol.
> 
> After reading a blog post on fcitx [0], I got the impression that letting the 
> compositor know some persistent ID of a text edit instance could be useful, 
> however I'm not sure what the use cases are.
> 
> As always, I'm happy to hear feedback.
> 
> Cheers,
> Dorota Czaplejewicz
> 
> [0] 
> https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/
> 
>  Makefile.am|   1 +
>  unstable/text-input/text-input-unstable-v3.xml | 362 
> +
>  2 files changed, 363 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..ed5204f
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v3.xml
> @@ -0,0 +1,362 @@
> +
> +
> +
> +  
> +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 

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

[Silvan Jegen]

On Thu, Apr 12, 2018 at 09:53:17PM +0200, Dorota Czaplejewicz wrote:
> On Thu, 12 Apr 2018 21:26:08 +0200
> Silvan Jegen <s.je...@gmail.com> wrote:
> 
> > Hi Dorota
> > 
> > On Wed, Apr 11, 2018 at 03:03:58PM +0200, Dorota Czaplejewicz wrote:
> > > 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.

Can confirm that the compilation has been fixed now. Thanks!


Cheers,

Silvan


signature.asc
Description: PGP signature
___
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

[Silvan Jegen]

On Thu, Apr 12, 2018 at 9:53 PM, Dorota Czaplejewicz
<dorota.czaplejew...@puri.sm> wrote:
> On Thu, 12 Apr 2018 21:26:08 +0200
> Silvan Jegen <s.je...@gmail.com> 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 <s...@cmpwn.com>
>> > ---
>> >
>> > 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

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

[Silvan Jegen]

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 <s...@cmpwn.com>
> ---
> 
> 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


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

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

[Silvan Jegen]

Hi

Please find some comments and questions below.

On Sun, Mar 11, 2018 at 08:30:14PM +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.
> - 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.
> 
> Signed-off-by: Carlos Garnacho 
> ---
> 
> Hey,
> 
> Belatedly, here's my proposed v3 of the text-input protocol, a rename of
> what is implemented on gnome-shell/gtk+. It basically is a
> (over?)simplification compared to v2, the main difference besides the
> punted functionality is the simplified messaging flow, state is considered
> reset after enter/leave, or on .disable requests from the client, all
> new state must be submitted afterwards.

Is v3 of the text-input protocol compatible with v1 of the input-method
protocol? I would assume so but I am wondering if that should be pointed
out somewhere.


> Some of the removed things are maybe debatable (eg. the keysym event,
> or language preference request/signal, although I don't see that working
> out of the box widely, highly toolkit specific at best). For stuff like
> the old input_panel_state request to do client-side UI magic to keep
> keyboard focus visible I'm personally more opinionated though :).
> 
> Comments?
>
> Cheers,
>   Carlos
> 
>  Makefile.am|   2 +
>  unstable/text-input/text-input-unstable-v3.xml | 293 
> +
>  2 files changed, 295 insertions(+)
>  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..31a36fe 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,6 +3,8 @@ 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-v2.xml  
> \

v2 has never been commited to the repo so it probably has to be added
there at one point?


> + 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..f8369b0
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v3.xml
> @@ -0,0 +1,293 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +Copyright © 2017, 2018 Red Hat, Inc.
> +
> +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, 

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

[Silvan Jegen]

Hi

One typo corrected below.

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

s/drawy/draw/


Cheers,

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

Re: Wayland talk at FOSDEM

[Silvan Jegen]

On Thu, Dec 7, 2017 at 10:32 PM, Philipp Kerling <pkerl...@casix.org> wrote:
> Hi,
>
> 2017-12-06 (水) の 08:56 +0100 に Silvan Jegen さんは書きました:
>> I see that you left out the text-input/input-method protocols in your
>> topics. Is it because those are unstable or because you don't
>> consider
>> them to be important enough?
> I just hadn't seen them in practice yet personally, to be honest.
> Having taken a closer look, I think it would be best to focus on
> protocols that have or are expected to have good cross-compositor
> support and are useful for general-purpose desktop applications. Is

Yeah, that makes sense.


> text-input implemented in a mainstream compositor besides weston?

IIRC, Gnome doesn't use it but uses dbus for communication with the
IME and KDE implemented their own new version of the text-input
protocol. I don't know about Sway though. Apparently the current
version of the text-input/input-method protocols have some
shortcomings and that's why they are not being used.

The new KDE version of the text-input protocol was posted on this
mailing list early last year but their revisions have not made it into
a new official unstable protocol yet. I am just wondering if there is
a chicken and egg problem here with noone using the protocol because
it doesn't suit their needs and then people not caring about it since
noone is using it...


Cheers,

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

Re: Wayland talk at FOSDEM

[Silvan Jegen]

Hi

On Tue, Dec 5, 2017 at 3:46 PM, Philipp Kerling  wrote:
> I've been thinking about submitting a Wayland-themed talk to the FOSDEM
> graphics devroom [1] and wanted to check with the community if anyone
> else has considered this or another Wayland topic and whether you think
> it would be a good idea™.
>
> What I would want to talk about is a beginner's introduction to Wayland
> from the client perspective. I think that resources on this (and on
> Wayland in general to be honest) are quite scarce and that I could pass
> on some of the knowledge I have gained by implementing native Wayland
> support in Kodi this way.
>
> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)
> * Difference between core and extension protocols
> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)
>  * Relevant compositors to test on and how to use nested mode
>  * Basic client programming
> * Protocols needed to get a surface on screen (wl_compositor,
>   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> * Seats and input
>* Keyboard: wl_keyboard and libxkbcommon
>* Mouse: wl_pointer and libwayland-cursor for cursor handling
> * xdg_wm_base
> * Window decorations
> * EGL

I would be very interested in an overview like that and think it's a
very good idea™ indeed!

I see that you left out the text-input/input-method protocols in your
topics. Is it because those are unstable or because you don't consider
them to be important enough?


Cheers,

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

Re: [PATCH weston 1/2] text-backend: Allow client hiding of input panel

[Silvan Jegen]

Hi Joshua

On Wed, Jul 05, 2017 at 08:58:51AM -0500, Joshua Watt wrote:
> On Sat, 2017-06-24 at 16:03 -0500, Joshua Watt wrote:
> > Previously, the hide_input_panel and show_input_panel messages for
> > the text
> > input protocol were limited to specific cases, such as showing the
> > panel on
> > activation, or making the panel visible after activation. Now,
> > clients are
> > allowed to toggle the panel visiblity at will as long as they are the
> > currently
> > active client
> > 
> > Signed-off-by: Joshua Watt 
> > ---
> >  compositor/text-backend.c | 22 --
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> Ping?

I have tested your two patches locally and can confirm that they compile
and run.

Letting the user toggle the visibility of the input panel with a click
(in the --click-to-show case) seems like a good change to me. I doubt
that there are any strong opinions on this though...


Cheers,

Silvan

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

Re: Wayland Virtual Keyboard

[Silvan Jegen]

Hi

On Wed, May 17, 2017 at 9:49 PM, Joshua Watt  wrote:
> I'm working on an embedded device where we are writing our own custom
> Wayland compositor, and we have need of a virtual keyboard (something
> implementing one of the text-input protocols). Does anyone know of
> such a project? My searches turned up maliit
> (https://github.com/maliit), but I was wondering if anyone knew of
> other options we could investigate?

You may already be aware of it but there is a very basic virtual
keyboard already included in the Weston project:

https://cgit.freedesktop.org/wayland/weston/tree/clients/keyboard.c

Maybe this could serve as an example at least.

Other than the maliit project I am not sure there exists one.
SailfishOS seems to be using the maliit project for their
implementation of a virtual keyboard. I am not sure their
implementation is Open Source though.


Cheers,

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

Re: [RFC PATCH 0/8] Meson build system

[Silvan Jegen]

On Wed, Nov 30, 2016 at 11:58 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi Silvan,
>
> On 30 November 2016 at 10:51, Silvan Jegen <s.je...@gmail.com> wrote:
>> On Wed, Nov 30, 2016 at 11:00 AM, Daniel Stone <dan...@fooishbar.org> wrote:
>>> Ha, this isn't Skylake laptop vs. Broadwell laptop, this is my 14-core
>>> Xeon vs. your Broadwell laptop! That they're so different suggests
>>> that our configuration is pretty wildly different - are you perhaps
>>> not building a load of stuff which configure autodetects? That's the
>>> only way I can imagine how your laptop would outpace a £4000
>>> workstation. :\
>>
>> I wonder how much of the difference is due to the speed of the
>> NVME/PCI-E SSD Emil is using.
>>
>> In my limited experience, the Xeons on my server did not perform as
>> well as the (higher tacted) i5 CPU on my desktop for some simple XML
>> processing task (provided the degree of parallelism is the same of
>> course).
>
> Apparently I need more coffee, because I was reading the wrong table,
> and this is about Wayland rather than Weston builds. Oops. Either way,
> the Xeon also has a NVME/PCI-E SSD, which seems pretty zippy; it also
> has 128GB of RAM, so it shouldn't be touching the SSD anyway.

Ah, I must have missed that in your description. I thought your Xeon
would use a regular SSD and that you are only measuring the first run
(cold page cache). Benchmarks are always tricky.


Cheers,

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

Re: [RFC PATCH 0/8] Meson build system

[Silvan Jegen]

Hi

On Wed, Nov 30, 2016 at 11:00 AM, Daniel Stone  wrote:
> Hey Emil,
> Thanks for the detailed reply! :) It's really interesting to hear your
> perspective, especially with Mesa also using SCons.
>
> On 30 November 2016 at 01:02, Emil Velikov  wrote:
>> On 29 November 2016 at 20:50, Daniel Stone  wrote:
 As you know better than me the actual speed increase isn't in using
 Meson, it's due to ninja.

 If one is to use (write?) make backend for Meson the results wouldn't
 be that different.
>>>
>>> I disagree. Using Ninja is nice, and a huge win, but there is already
>>> a massive, massive, massive, win before you invoke either Make or
>>> Ninja; just generating the configuration (autoreconf + ./configure vs.
>>> meson) is 16.75 seconds on my laptop (again, current-generation Intel
>>> with 16GB of RAM) for autotools, vs. 1.24 seconds for Meson. If
>>> they're equal, we'd have 53.96s vs. 28.0sec for the total build,
>>> rather than 53.96 vs. 12.47.
>>>
>> Thanks for the reminder how much configure sucks and how much faster
>> non-recursive makefiles are.
>
> Heh, Wayland and Weston both (apart from docs) use non-recursive
> Makefiles! We took the readability hit of flattening everything into
> one Makefile so we could get a speed/parallelism boost.
>
>> Numbers seems far better over here...
>>
>> $ git clean -fXd -- .. && rm -rf * && time (../autogen.sh
>> --prefix=/tmp/wayland-autotools --disable-documentation)
>> ~10 real
>>
>> The rest of the number also seems to vary noticeably, despite having a
>> lower spec machine.
>> Using stock Arch here, should distro of choice matter that much ?
>>
>> System 3 ('Laptop'): Dell XPS 13 9350, 2.5GHz dual-core Intel Skylake
>> i7-6500U, 4MB cache, 16GB RAM, storage on NVME/PCI-E, make -j8
>>
>> System X ('Laptop 2'): Lenovo X1C3, 245GHz dual-core Intel Broadwell
>> i7-5500U, 4MB cache, 8GB RAM, storage on NVME/PCI-E, make -j8
>>
>>
>> NB: Everything but the Install test, varies ±0.2s across 3 consecutive
>> runs, thus it's been rounded to the closest 0.5s on average.
>>
>>  |  Laptop |   Laptop 2 |
>> -+-++
>> Full | 27.78s / 11.24s |   ~21s /  ~10s |
>> Rebuild  | 13.80s /  9.63s | ~12.5s / ~8.5s |
>> Check| 13.22s /  8.80s |  ~7.5s / ~5.5s |
>> Install  |  0.47s /  0.14s |  0.47s / 0.14s |
>> -+-++
>
> Ha, this isn't Skylake laptop vs. Broadwell laptop, this is my 14-core
> Xeon vs. your Broadwell laptop! That they're so different suggests
> that our configuration is pretty wildly different - are you perhaps
> not building a load of stuff which configure autodetects? That's the
> only way I can imagine how your laptop would outpace a £4000
> workstation. :\

I wonder how much of the difference is due to the speed of the
NVME/PCI-E SSD Emil is using.

In my limited experience, the Xeons on my server did not perform as
well as the (higher tacted) i5 CPU on my desktop for some simple XML
processing task (provided the degree of parallelism is the same of
course).


Cheers,

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

Re: [PATCH wayland-protocols v7] text: Create second version of text input protocol

[Silvan Jegen]

On Wed, Oct 12, 2016 at 03:50:33PM -0700, Bryce Harrington wrote:
> On Wed, Jul 06, 2016 at 12:26:28AM +0200, Jan Arne Petersen wrote:
> > On Thu, Jun 9, 2016 at 1:01 PM Carlos Garnacho  wrote:
> > 
> > Hi Carlos,
> > 
> > Thanks for the feedback.
> > 
> > >
> > > Chiming in, and kinda late at that... hopefully we'll get this moving :).
> > 
> > I do not think we want to change text_input_unstable_v2 version 1 anymore
> > (since it already got shipped in Qt 5.7.0 and Plasma 5.7.0). Sorry for that.
> > But I already started to  work on text_input_unstable_v2 version 2 and also
> > text_input_unstable_v3 where I like to include the feedback.
> >
> > > First of all, I'm aware that some of my comments are directed towards
> > > stuff that's unchanged between v1 and v2, so please bear with me, I
> > > hope the feedback is useful.
> > 
> > Sure that is perfectly fine, I think that is the idea of the unstable 
> > protocols
> > anyways that we can still change everything and adapt them with real
> > world experience.
> 
> > > On Mon, May 30, 2016 at 11:41 AM, Jan Arne Petersen  
> > > wrote:
> > > > There were some shortcomings in the first version of the protocol which
> > > > makes it not really useful in real world applications. It is not really
> > > > possible to fix them in a compatible way so introduce a new v2 of the
> > > > protocol.
> > > >
> > > > Fixes some shortcomings of the first version:
> > > >
> > > > * Use only one wp_text_input per wl_seat (client side should be
> > > >   handled by client toolkit)
> > > > * Allow focus tracking without wl_keyboard present
> > > > * Improve update state handling and better define state handling
> 
> I'd love to see a re-rev of this patch.  Looking at a diff between v1
> and v2, those three changes seem quite suitable, although I'd like to
> see an exact minimal diff of the changes so holding off on detailed
> review.  But worth an acked by at least:

I share this sentiment!


>
> Acked-by: Bryce Harrington 
>
> The input-method and text-input protocols both deal with similar
> functionality (text input).  I'm not sure if we already have a high
> level description somewhere that describes their relationship, but at a
> minimum I think the protocols ought to cross-reference each other.  (For
> instance, something like, "See also the input-method protocol, which
> provides ...")  When I first looked at the two protocols, just reading
> their descriptions it wasn't obvious at all how they related; it only
> clicked after studying the weston code.

I spent quite a long time looking at those protocols and their
client/compositor implementations (in Weston as well as in QTWayland). By
now I think I have at least a basic understanding of how they should
work together.

I was wondering where a high-level documentation describing how text
input is handled (with the help of an input method) should live. Since
those are unstable protocols, maybe adding an .md file somewhere in
wayland-protocols/unstable/ would be appropriate?

I have one question regarding the following request (I hope this is
the right place to ask): 

>
>  
>   Sets the cursor outline as a x, y, width, height rectangle in surface
>   local coordinates.
>
>   Allows the compositor to put a window with word suggestions near the
>   cursor.
>  
>  
>  
>  
>  
>

I assume that the "window with word suggestions" that this request
enables the compositor to draw will be supplied by the input method
(though the current version of the input-method protocol does not seem
to provide an event/request for this yet). Is this assumption correct?


Cheers,

Silvan

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

Re: [PATCH weston v2 1/2] editor: Use parse_options() from shared for command line options

[Silvan Jegen]

Hi

One comment below.

On Mon, Nov 21, 2016 at 10:34:33AM -0800, Bryce Harrington wrote:
> Also add a basic --help option
> 
> Signed-off-by: Bryce Harrington 
> ---
>  clients/editor.c | 78 
> +---
>  1 file changed, 57 insertions(+), 21 deletions(-)
> 
> diff --git a/clients/editor.c b/clients/editor.c
> index 30bf555..33b43d2 100644
> --- a/clients/editor.c
> +++ b/clients/editor.c
> @@ -37,6 +37,7 @@
>  
>  #include 
>  
> +#include "shared/config-parser.h"
>  #include "shared/helpers.h"
>  #include "shared/xalloc.h"
>  #include "window.h"
> @@ -1489,28 +1490,63 @@ global_handler(struct display *display, uint32_t name,
>   }
>  }
>  
> +/** Display help for command line options, and exit */
> +static uint32_t opt_help = 0;
> +
> +/** Require a distinct click to show the input panel (virtual keyboard) */
> +static uint32_t opt_click_to_show = 0;
> +
> +/** Set a specific (RFC-3066) language.  Used for the virtual keyboard, etc. 
> */
> +static const char *opt_preferred_language = NULL;
> +
> +/**
> + * \brief command line options for editor
> + */
> +static const struct weston_option editor_options[] = {
> + { WESTON_OPTION_BOOLEAN, "help", 'h', _help },
> + { WESTON_OPTION_BOOLEAN, "click-to-show", 'C', _click_to_show },
> + { WESTON_OPTION_STRING, "preferred-language", 'L', 
> _preferred_language },
> +};
> +
> +static void
> +usage(const char *program_name, int exit_code)
> +{
> + unsigned k;
> +
> + fprintf(stderr, "Usage: %s [OPTIONS]\n\n", program_name);
> + for (k = 0; k < ARRAY_LENGTH(editor_options); k++) {
> + const struct weston_option *p = _options[k];
> + if (p->name) {
> + fprintf(stderr, "  --%s", p->name);
> + if (p->type != WESTON_OPTION_BOOLEAN)
> + fprintf(stderr, "=VALUE");
> + fprintf(stderr, "\n");
> + }
> + if (p->short_name) {
> + fprintf(stderr, "  -%c", p->short_name);
> + if (p->type != WESTON_OPTION_BOOLEAN)
> + fprintf(stderr, "VALUE");
> + fprintf(stderr, "\n");
> + }
> + }
> + exit(exit_code);
> +}
> +
>  int
>  main(int argc, char *argv[])
>  {
>   struct editor editor;
>   int i;

This is still unused (as pointed out by Daniel) and should be removed.


Cheers,

Silvan

> - uint32_t click_to_show = 0;
> - const char *preferred_language = NULL;
> -
> - for (i = 1; i < argc; i++) {
> - if (strcmp("--click-to-show", argv[i]) == 0)
> - click_to_show = 1;
> - else if (strcmp("--preferred-language", argv[i]) == 0 &&
> -  i + 1 < argc) {
> - preferred_language = argv[i + 1];
> - i++;
> - } else {
> - printf("Usage: %s [OPTIONS]\n"
> -"  --click-to-show\n"
> -"  --preferred-language LANGUAGE\n",
> -argv[0]);
> - return 1;
> - }
> +
> + parse_options(editor_options, ARRAY_LENGTH(editor_options),
> +   , argv);
> + if (opt_help)
> + usage(argv[0], EXIT_SUCCESS);
> +
> + if (argc > 1) {
> + usage(argv[0], EXIT_FAILURE);
> + /* FIXME: Use remaining arguments as a path/filename to load */
> + return 0;
>   }
>  
>   memset(, 0, sizeof editor);
> @@ -1537,12 +1573,12 @@ main(int argc, char *argv[])
>   editor.widget = window_frame_create(editor.window, );
>  
>   editor.entry = text_entry_create(, "Entry");
> - editor.entry->click_to_show = click_to_show;
> - if (preferred_language)
> - editor.entry->preferred_language = strdup(preferred_language);
> + editor.entry->click_to_show = opt_click_to_show;
> + if (opt_preferred_language)
> + editor.entry->preferred_language = 
> strdup(opt_preferred_language);
>   editor.editor = text_entry_create(, "Numeric");
>   editor.editor->content_purpose = 
> ZWP_TEXT_INPUT_V1_CONTENT_PURPOSE_NUMBER;
> - editor.editor->click_to_show = click_to_show;
> + editor.editor->click_to_show = opt_click_to_show;
>   editor.selection = NULL;
>   editor.selected_text = NULL;
>  
> -- 
> 1.9.1
> 
> ___
> 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] weston-editor: Don't copy the preedit string before inserting it

[Silvan Jegen]

Hi Bryce

And thanks for the review!

On Fri, Nov 18, 2016 at 1:20 AM, Bryce Harrington <br...@osg.samsung.com> wrote:
> On Thu, Nov 17, 2016 at 09:43:05PM +0100, Silvan Jegen wrote:
>> Signed-off-by: Silvan Jegen <s.je...@gmail.com>
>> ---
>>  clients/editor.c | 8 +---
>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/clients/editor.c b/clients/editor.c
>> index 6805d8a..1ed3eec 100644
>> --- a/clients/editor.c
>> +++ b/clients/editor.c
>> @@ -944,16 +944,10 @@ text_entry_reset_preedit(struct text_entry *entry)
>>  static void
>>  text_entry_commit_and_reset(struct text_entry *entry)
>>  {
>> - char *commit = NULL;
>> -
>>   if (entry->preedit.commit)
>> - commit = strdup(entry->preedit.commit);
>> + text_entry_insert_at_cursor(entry, entry->preedit.commit, 0, 
>> 0);
>>
>>   text_entry_reset_preedit(entry);
>> - if (commit) {
>> - text_entry_insert_at_cursor(entry, commit, 0, 0);
>> - free(commit);
>> - }
>
> This essentially swaps the order of text_entry_reset_preedit() and
> text_entry_insert_at_cursor().  Does this cause any side effects?
>
> text_entry_insert_at_cursor() calls text_entry_update_layout(), which
> will behave differently if there is a preedit in effect with and without
> this patch.  I'm not super familiar with this code, but on a quick skim
> it looks like with this patch applied, any existing pre-edits will be
> applied and finalized before the reset, whereas previously the pre-edits
> would be discarded?  Am I interpreting this correctly?  If this is the

You are right. I missed that text_entry_reset_preedit() also resets
entry->preedit.text (not only preedit.commit). When I change the
function call order like this, text_entry_update_layout() will
concatenate the entry->text and the preedit.text and commit it which
results in the not-yet-committed pre-edit string being applied.


> case, and if that change of behavior is desireable, make sure the
> behavioral change (and rationale for why it's being done) is documented
> in the changelog.  If I'm not interpreting it correctly, accept my
> apologies and I look forward to your elucidation (which probably also
> would be worth referencing in the changelog entry).

I tested the change and did not notice any regression (i. e. was not
tripped up by any strange/unexpected behavior). Looking at the code
now however, text_input_leave() calls text_entry_commit_and_reset()
which would mean that the not-committed pre-edit text would get
applied when the text entry area loses focus which is almost
definitely not what one would want.

Please ignore this patch because it would result in undesirable behaviour.


Cheers,

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

[PATCH] weston-editor: Don't copy the preedit string before inserting it

[Silvan Jegen]

Signed-off-by: Silvan Jegen <s.je...@gmail.com>
---
 clients/editor.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/clients/editor.c b/clients/editor.c
index 6805d8a..1ed3eec 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -944,16 +944,10 @@ text_entry_reset_preedit(struct text_entry *entry)
 static void
 text_entry_commit_and_reset(struct text_entry *entry)
 {
-   char *commit = NULL;
-
if (entry->preedit.commit)
-   commit = strdup(entry->preedit.commit);
+   text_entry_insert_at_cursor(entry, entry->preedit.commit, 0, 0);
 
text_entry_reset_preedit(entry);
-   if (commit) {
-   text_entry_insert_at_cursor(entry, commit, 0, 0);
-   free(commit);
-   }
 
zwp_text_input_v1_reset(entry->text_input);
text_entry_update(entry);
-- 
2.10.2

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

[PATCH] weston-editor: Free preferred_language in text_entry_destroy

[Silvan Jegen]

Signed-off-by: Silvan Jegen <s.je...@gmail.com>
---
 clients/editor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/clients/editor.c b/clients/editor.c
index 1ed3eec..a0d66d1 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -719,6 +719,7 @@ text_entry_destroy(struct text_entry *entry)
zwp_text_input_v1_destroy(entry->text_input);
g_clear_object(>layout);
free(entry->text);
+   free(entry->preferred_language);
free(entry);
 }
 
-- 
2.10.2

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

Re: Kinetic scroll in libinput Xorg driver

[Silvan Jegen]

On Wed, Oct 26, 2016 at 8:57 AM, Alexis BRENON @Wayland
 wrote:
> Finally, do you know some tiling DE/WM Wayland compliant ?

The two that come to mind are:

https://github.com/michaelforney/velox Velox: a Wayland port of dwm
with minimal dependencies

http://swaywm.org/ Sway: which is a port of i3 to Wayland IIRC


Cheers,

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

Re: [PATCH weston 04/14 v3] weston: Port DRM backend to new output handling API

[Silvan Jegen]

Hi

Found a few typos mentioned below.

On Thu, Aug 18, 2016 at 6:42 PM, Armin Krezović
 wrote:
> This is a complete port of the DRM backend that uses
> recently added output handling API for output

*the* recently added [...]

> configuration.
>
> Output can be configured at runtime by passing the
> necessary configuration parameters, which can be
> filled in manually or obtained from the configuration
> file using previously added functionality. It is
> required that the scale and transform values are set
> using the previously added functionality.
>
> After everything has been set, output needs to be
> enabled manually using weston_output_enable().
>
> [...]
>
> +/**
> + * Create and configure a Weston output structure
> + *
> + * Given a DRM connector, create a matching drm_output structure and add it
> + * to Weston's output list.
> + *
> + * @param b Weston backend structure structure

Weston backend structure

(only one "structure")


Cheers,

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

Re: [RFC wayland-web] docs, web site, logo

[Silvan Jegen]

Hi

On Mon, Aug 22, 2016 at 11:37 AM, Pekka Paalanen  wrote:
> On Sat, 20 Aug 2016 11:54:29 +0100
> Daniel Stone  wrote:
>
> [...]
>
>> I think this is easily the lowest-priority issue here. It's not the
>> best, but it certainly works, and it's not really holding us back from
>> progress. It's also something that's relatively well recognised atm.
>
> I agree with Daniel on all points.
>
> I recall there is a good chunk of generated documentation that does
> not get published in the web yet. I think it's the generated
> protocol C API. Yes, it mostly just duplicate of the protocol docs
> generated directly from XML, but there would be differences: the C
> API is different on server vs. client side, and also a little
> different from the language-agnostic protocol spec.
>
> Getting also wayland-protocols docs generated and published with
> appropriate structure would be good. This I would consider the
> first priority of the four points. It should be almost just a
> matter of hooking up Doxygen to run somehow and making a place to
> upload the docs to.

I agree that this should be the highest priority.

Looking at https://cgit.freedesktop.org/wayland/wayland-web/tree/ the
easiest way to do that should be to add a script that generates the
Doxygen docs and then copies them to a subdirectory of the website.
Then the only thing left is to put a link to it into index.html.

I wrote a wiki entry for a simple doxygen config that could be used.
It can be found here:
https://github.com/neovim/neovim/wiki/Generate-callgraphs-with-Doxygen


> I'm curious on what you consider low quality on the logo. There is
> an SVG original of it, too. What would we tangibly gain from having
> a new logo made? Is it too easy to confuse with something else?

For what it's worth, I really like the simplicity of the site's design
as it is now and the logo and I don't see any need to change it at
all.


Cheers,

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

Re: [PATCH v3 wayland-protocols] text: Create second version of text input protocol

[Silvan Jegen]

Hi

Please find some comments and spelling corrections below.


> There were some shortcomings in the first version of the protocol which
> makes it not really useful in real world applications. It is not really
> possible to fix them in a compatible way so introduce a new v2 of the
> protocol.
>
> Fixes some shortcomings of the first version:
>
> * Use only one wp_text_input per wl_seat (client side should be
>   handled by client toolkit)
> * Allow focus tracking without wl_keyboard present
> * Improve update state handling
> * Allow state requests
> ---
>  unstable/text-input/text-input-unstable-v2.xml | 481 
> +
>  1 file changed, 481 insertions(+)
>  create mode 100644 unstable/text-input/text-input-unstable-v2.xml
>
> diff --git a/unstable/text-input/text-input-unstable-v2.xml 
> b/unstable/text-input/text-input-unstable-v2.xml
> new file mode 100644
> index 000..2fc5e7d
> --- /dev/null
> +++ b/unstable/text-input/text-input-unstable-v2.xml
> @@ -0,0 +1,481 @@
> +
> +
> +
> +  
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +
> +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_v2 interface represents text input and input methods

s/repesents/represents/


> +  associated with a seat. It provides enter/leave event to follow the

s/event/events/


> +  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 entered text is sent to the text-input object via

"about the entered text" may sound more natural.

> +  the pre-edit and commit events. Using this interface removes the need
> +  for applications to directly process hardware key events and compose 
> text
> +  out of them.
> +
> +  Text is UTF-8 encoded, indices and lengths are in bytes.

This seems problematic to me when dealing with multi-byte encoded
Unicode points. The behavior should be better defined in that case.
Please see comments further below.


> +  Serials are used to synchronize the state between the text input and
> +  an input method. New serials are sent by the text input in the
> +  update_state request and are used by the input method to indicate
> +  the known text input state in evsents like preedit_string, 
> commit_string,

s/evsents/events/

> +  and keysym. The text input can then ignore events from the input method
> +  which are based on an outdated state (for example after a reset).
> +
> +
> +
> +  
> +   Destroy the wp_text_input object. Also disables all surfaces enabled
> +   through this wp_text_input object
> +  
> +
> +
> +
> +  
> +   Enable text input in a surface (usually when a text entry inside of it
> +   has focus).
> +
> +   This can be called before or after a surface gets text (or keyboard)
> +   focus via the enter event. Text input to a surface is only active
> +   when it has the current text (or keyboard) focus and is enabled.
> +  
> +  
> +
> +
> +
> +  
> +   Disable text input in a surface (typically when there is no focus on 
> any
> +   text entry inside the surface).
> +  
> +  
> +
> +
> +
> +  
> +   Requests input panels (virtual keyboard) to show.
> +
> +   This should be used for example to show a virtual keyboard again
> +   (with a tap) after it was closed by pressing on a close button on the
> +   keyboard.
> +  
> +
> +
> +
> +  
> +   Requests input panels (virtual keyboard) to hide.
> +  
> +
> +
> +
> +  

There is a description 

Re: [PATCH v1] rephrasing the index.html to match the current shape of the project

[Silvan Jegen]

Hi

Found a few typos that I point out below.

On Fri, Nov 27, 2015 at 03:35:11PM +0100, Benoit Gschwind wrote:
> I added bryce comments, my comments and my favorite capitalization.
> 
> Best regards
> 
> ---
>  index.html | 39 ---
>  1 file changed, 24 insertions(+), 15 deletions(-)
> 
> diff --git a/index.html b/index.html
> index a9ebcaa..0788cef 100644
> --- a/index.html
> +++ b/index.html
> @@ -12,21 +12,30 @@
>  
>  Wayland
>  
> -Wayland is intended as a simpler replacement for X, easier to develop
> -and maintain.  GNOME and KDE are expected to be ported to it.
> -
> -Wayland is a protocol for a compositor to talk to its clients as
> -well as a C library implementation of that protocol.  The compositor
> -can be a standalone display server running on Linux kernel modesetting
> -and evdev input devices, an X application, or a wayland client itself.
> -The clients can be traditional applications, X servers (rootless or
> -fullscreen) or other display servers.
> -
> -Part of the Wayland project is also the Weston reference
> -implementation of a Wayland compositor.  Weston can run as an X client
> -or under Linux KMS and ships with a few demo clients.  The Weston
> -compositor is a minimal and fast compositor and is suitable for many
> -embedded and mobile use cases.  
> +Wayland intends to replace the X11 protocol. The aim is to be easier
> +to use, improve on the X11 protocol, and perform better.  GNOME and KDE
> +are expected to implement this protocol in their own servers.  The
> +Wayland project produces 3 components: wayland, libwayland and
> +weston.
> +
> +wayland is a protocol for sharing screens and input devices between
> +concurent clients.  It defines the way servers and clients talks to each

s/talks/talk/

> +other.  The server is reponsible for setting up screens and input
> +devices, and for displaying the final images that the user sees on the
> +screen.  We term this server a 'compositor'.
> +
> +libwayland is a reference library that implements the Wayland
> +protocol.  This library is intended to help developers implement
> +compositors and clients.  This library is split into a client-side part
> +and a server-side part.
> +
> +weston is a reference compositor that use libwayland to talk

s/use/uses/

> +with its clients.  It can run under Linux's Kernel Mode Setting (KMS) as a
> +stand-alone compositor, or it can run as X client.  In the later case,

More common is "In the latter case",


Cheers,

Silvan

> +weston creates a virtual screen that is drawn in an X window and 
> creates
> +virtual input devices taken from the X server; this works similarly to
> +Xnest or Xephyr.  weston also includes a few proof-of-concept clients
> +such as weston-flower, weston-gears, and weston-terminal.
>  
>  Information:
>  
> -- 
> 2.4.10
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland 2/2] Add a wayland protocol dumper wayland-tracer

[Silvan Jegen]

Hi

and thanks for this! I hope to learn more about the protocol by using
this tool.

I encountered two simple issues when applying your patches (see below).

On Sun, Jul 20, 2014 at 10:18:03AM +0800, Boyan Ding wrote:
 Signed-off-by: Boyan Ding stu_...@126.com
 ---
  .gitignore   |   1 +
  Makefile.am  |  10 ++
  configure.ac |   7 ++
  src/tracer.c | 351 
 +++
  4 files changed, 369 insertions(+)
  create mode 100644 src/tracer.c
 
 diff --git a/.gitignore b/.gitignore
 index c146bac..510b7ae 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -54,4 +54,5 @@ sanity-test
  signal-test
  socket-test
  wayland-scanner
 +wayland-tracer
  protocol/*.[ch]
 diff --git a/Makefile.am b/Makefile.am
 index c15d8b8..f234599 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -70,6 +70,16 @@ $(BUILT_SOURCES) : wayland-scanner
  pkgconfig_DATA += src/wayland-scanner.pc
  else
  wayland_scanner = wayland-scanner
 +bin_PROGRAMS =
 +endif
 +
 +if ENABLE_TRACER
 +wayland_tracer = $(top_builddir)/wayland-tracer
 +bin_PROGRAMS += wayland-tracer
 +wayland_tracer_SOURCES = src/tracer.c
 +wayland_tracer_LDADD = libwayland-util.la $(FFI_LIBS)

wayland-tracer wouldn't compile without including the -lrt switch (for
the time.h functions) like this.

wayland_tracer_LDADD = libwayland-util.la $(FFI_LIBS) -lrt

I am not sure whether this issue is specific to my setup or if this is
the best way to fix it.


 +else
 +wayland_tracer = wayland-tracer
  endif
  
  protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
 diff --git a/configure.ac b/configure.ac
 index e16c5b5..b3e81a7 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -64,7 +64,14 @@ AC_ARG_ENABLE([documentation],
 [],
 [enable_documentation=yes])
  
 +AC_ARG_ENABLE([tracer],
 +  [AC_HELP_STRING([--disable-tracer],
 +  [Disable compilation of wayland-tracer])],
 +  [],
 +  [enable_tracer=yes])
 +
  AM_CONDITIONAL(ENABLE_SCANNER, test x$enable_scanner = xyes)
 +AM_CONDITIONAL(ENABLE_TRACER, test x$enable_tracer = xyes)
  
  AC_ARG_WITH(icondir, [  --with-icondir=dirLook for cursor icons here],
[  ICONDIR=$withval],
 diff --git a/src/tracer.c b/src/tracer.c
 new file mode 100644
 index 000..23de75d
 --- /dev/null
 +++ b/src/tracer.c
 @@ -0,0 +1,351 @@
 +/*
 + * Copyright © 2014 Boyan Ding
 + *
 + * 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.
 + */
 +
 +#include stdio.h
 +#include stdlib.h
 +#include stddef.h
 +#include string.h
 +#include unistd.h
 +#include fcntl.h
 +#include sys/epoll.h
 +#include sys/types.h
 +#include sys/socket.h
 +#include sys/un.h
 +#include stdint.h
 +#include errno.h
 +#include assert.h
 +
 +#include wayland-os.h
 +#include wayland-private.h
 +#include wayland-util.h
 +
 +#define TRACER_SERVER_SIDE 0
 +#define TRACER_CLIENT_SIDE 1
 +
 +struct tracer_connection {
 + struct wl_connection *wl_conn;
 + struct tracer_connection *peer;
 + int side;
 +};
 +
 +struct tracer {
 + struct tracer_connection *client_conn;
 + struct tracer_connection *server_conn;
 + int32_t epollfd;
 +};
 +
 +static int
 +tracer_dump_bin(struct tracer_connection *connection)
 +{
 + int i, len, fdlen, fd;
 + char buf[4096];
 + struct wl_connection *wl_conn= connection-wl_conn;
 + struct tracer_connection *peer = connection-peer;
 +
 + len = wl_buffer_size(wl_conn-in);
 + if (len == 0) 

There is a trailing space here (git complained when applying the patch).


 + return 0;
 +
 + wl_connection_copy(wl_conn, buf, len);
 +
 + printf(%s Data dumped: %d bytes:\n,
 +connection-side == TRACER_SERVER_SIDE ? = : =, len);
 + for (i = 0; i  len; i++) {
 + printf(%02x , (unsigned char)buf[i]);
 + }
 + printf(\n);

Re: [ANNOUNCE] libinput 0.4.0

[Silvan Jegen]

On Wed, Jun 25, 2014 at 9:02 AM, Lyude thatsly...@gmail.com wrote:
 Ah, something else I forgot to mention:

 git-am requires that the patches be in .mbox format, otherwise it won't
 work properly. I don't think there's a way to do this in gmail since the
 last time I checked, it can't save e-mails in that format. To actually
 take advantage of this sort of thing you'd need to use a client of some
 sort instead of the web interface.

I *think* you can get a mbox-compatible format that can be used with
git am from Gmail by clicking on the Show Original option in the
More menu that is shown as a triangle in the upper right corner of
mail message.

Using a mail client that let's you save (multiple) mails quickly to a
.mbox-formatted file (like mutt for example) is preferable though.


Cheers,

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

[PATCH] protocol: remove redundant 'the' in description

[Silvan Jegen]

Signed-off-by: Silvan Jegen s.je...@gmail.com
---
 protocol/wayland.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 22eb6e7..113c7b7 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -550,8 +550,8 @@
The current and pending input regions of the icon wl_surface are
cleared, and wl_surface.set_input_region is ignored until the
wl_surface is no longer used as the icon surface. When the use
-   as an icon ends, the the current and pending input regions
-   become undefined, and the wl_surface is unmapped.
+   as an icon ends, the current and pending input regions become
+   undefined, and the wl_surface is unmapped.
   /description
   arg name=source type=object interface=wl_data_source 
allow-null=true/
   arg name=origin type=object interface=wl_surface/
-- 
1.9.1

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

Re: weston-1.4.0: rpi-backend is broken

[Silvan Jegen]

Hi everyone

On Sun, Jan 26, 2014 at 09:15:50PM +0100, Yann E. MORIN wrote:
 [...]
 Here's the complete log of 'weston weston.log 21' :
 
 ---8---
 Date: 2014-01-26 UTC
 [20:03:09.606] weston 1.4.0
http://wayland.freedesktop.org/
Bug reports to:
 
 https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.4.0
Build:  
 [20:03:09.607] OS: Linux, 3.12.7, #1 PREEMPT Sat Jan 25 14:09:48 CET
 2014, armv6l
 [20:03:09.608] Starting with no config file.
 [20:03:09.611] Loading module '/usr/lib/weston/rpi-backend.so'
 [20:03:09.648] initializing Raspberry Pi backend
 [20:03:09.652] Dispmanx planes are double buffered.
 [20:03:09.656] launching '/usr/libexec/weston-keyboard'
 [20:03:09.909] input device HID 046a:0023, /dev/input/event0 is a
 keyboard
 Failed to process Wayland connection: Connection reset by peer
 failed to create display: Connection reset by peer
 Segmentation fault
 ---8---

I am getting a very similar error output on my RP:


Date: 2014-01-31 UTC
[18:35:41.645] weston 1.4.0
   http://wayland.freedesktop.org/
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.4.0
   Build: 1.4.0-3-g1afb238-dirty input: Unlink saved kbd focus 
listener when releasing seat (2014-01-27 21:14:25 -0800)
[18:35:41.647] OS: Linux, 3.10.25+, #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014, 
armv6l
[18:35:41.652] Using config file '/home/pi/local/etc/weston.ini'
[18:35:41.653] Loading module '/home/pi/local/lib/weston/rpi-backend.so'
[18:35:41.680] initializing Raspberry Pi backend
[18:35:41.721] Dispmanx planes are double buffered.
[18:35:41.727] launching '/home/pi/local/libexec/weston-keyboard'
[18:35:41.730] input device Logitech USB-PS/2 Optical Mouse, /dev/input/event0 
is a pointer caps = relative-motion button
Segmentation fault
Failed to process Wayland connection: Broken pipe
failed to create display: Broken pipe


I am using Raspbian as user 'pi' starting weston using the (setuid-root)
weston-launch binary.

Weston is not starting at all though I am quite positive that the screen
flickers briefly before I am being dropped back to the shell.

Do you think it would make sense for me to debug it? If so, how do I get
a useful backtrace using (c)gdb when weston-launch starts a different
binary? I can try to bisect the problem if you think it would be helpful.


Cheers,

Silvan

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

Re: Problems building Weston/demo applications on the Raspberry Pi

[Silvan Jegen]

 thanks for the patch! :-)

You are very welcome!


 One minor correction: it is not exactly the flag, but removing
 wayland-egl.pc that makes sure that toytoolkit does not use cairo-egl.
 Otherwise looks good, and the patch is an improvement even as is.

You see, I TOLD you the text is confusing! :-)

When I get home from work (in 8 hours...) I will resend a corrected
version of the patch.


Cheers,

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

[PATCH v2] Building: update the Raspberry Pi weston section

[Silvan Jegen]

Update the Weston autogen.sh flags and make the accompanying text less
confusing.
---
 raspberrypi.html | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/raspberrypi.html b/raspberrypi.html
index 44d9ce4..153b8a2 100644
--- a/raspberrypi.html
+++ b/raspberrypi.html
@@ -146,24 +146,25 @@ contains similar files for Android, and will not work./p
 pre$ git clone git://anongit.freedesktop.org/wayland/weston
 $ cd weston
 
-$ ./autogen.sh --prefix=$WLD \
---disable-setuid-install --with-cairo-glesv2 \
+$ ./autogen.sh --prefix=$WLD --disable-setuid-install \
 --disable-x11-compositor --disable-drm-compositor \
 --disable-fbdev-compositor --disable-wayland-compositor \
---disable-weston-launch --disable-simple-egl-clients \
---disable-egl --disable-libunwind --disable-colord \
---disable-resize-optimization --disable-xwayland-test \
+--disable-weston-launch --disable-simple-egl-clients --disable-egl \
+--disable-libunwind --disable-colord --disable-resize-optimization \
+--disable-xwayland-test \
 WESTON_NATIVE_BACKEND=rpi-backend.so
 
 $ make
 $ make install
 /pre
 
-pWhen adding tt--disable-wayland-compositor/tt you can remove the
-dummy ttwayland-egl.pc/tt pkg-config file, if you installed it before.
-This makes sure, that toytoolkit (Weston demo programs) does not use Cairo
-EGL. EGL does not work for clients due to EGL Wayland platform being
-unimplemented on Raspberry Pi./p
+pIf you decide to use the tt--disable-wayland-compositor/tt
+flag supplied above you can remove the dummy ttwayland-egl.pc/tt
+pkg-config file which you may have installed from following an older
+version of this guide. Removing this file makes sure, that toytoolkit
+(Weston demo programs) does not use Cairo EGL. EGL does not work for
+clients due to the EGL Wayland platform being unimplemented on the
+Raspberry Pi./p
 
 pWeston should work by running ttweston/tt. Remember to have the
 environment set up, and it is useful to have an ssh session open to your
-- 
1.8.4

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

Re: Problems building Weston/demo applications on the Raspberry Pi

[Silvan Jegen]

 the When adding refers to the old version of the guide. This
 is about migrating from a old build where the configure flags
 were different.  That's what the if you installed it before
 meant. Granted, is not too clearly written. I guess we could now
 remove these leftovers.

That's what I suspected but I wasn't sure.


 I see we also need to fix that build guide. Your problem comes
 from --with-cairo-glesv2, which before just silently fell back to
 cairo-image, but now triggers an error.

 --with-cairo-glesv2 should simply be removed from the configure line.

Sadly, that fix was not obvious to me. Removing the flag solved the
problem, thanks a lot!

In the attached patch I removed the flag and tried to make the text less
confusing.


Kind regards,

Silvan

From 72a2436d1876267d8516a40b3e7efb2f158695e6 Mon Sep 17 00:00:00 2001
From: Silvan Jegen s.je...@gmail.com
Date: Mon, 16 Sep 2013 18:00:49 +0200
Subject: [PATCH] Building: update the Raspberry Pi weston section

Update the Weston autogen.sh flags and make the accompanying text less
confusing.
---
 raspberrypi.html | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/raspberrypi.html b/raspberrypi.html
index 44d9ce4..c65d918 100644
--- a/raspberrypi.html
+++ b/raspberrypi.html
@@ -146,24 +146,24 @@ contains similar files for Android, and will not work./p
 pre$ git clone git://anongit.freedesktop.org/wayland/weston
 $ cd weston
 
-$ ./autogen.sh --prefix=$WLD \
---disable-setuid-install --with-cairo-glesv2 \
+$ ./autogen.sh --prefix=$WLD --disable-setuid-install \
 --disable-x11-compositor --disable-drm-compositor \
 --disable-fbdev-compositor --disable-wayland-compositor \
---disable-weston-launch --disable-simple-egl-clients \
---disable-egl --disable-libunwind --disable-colord \
---disable-resize-optimization --disable-xwayland-test \
+--disable-weston-launch --disable-simple-egl-clients --disable-egl \
+--disable-libunwind --disable-colord --disable-resize-optimization \
+--disable-xwayland-test \
 WESTON_NATIVE_BACKEND=rpi-backend.so
 
 $ make
 $ make install
 /pre
 
-pWhen adding tt--disable-wayland-compositor/tt you can remove the
-dummy ttwayland-egl.pc/tt pkg-config file, if you installed it before.
-This makes sure, that toytoolkit (Weston demo programs) does not use Cairo
-EGL. EGL does not work for clients due to EGL Wayland platform being
-unimplemented on Raspberry Pi./p
+pIf you decide to use the tt--disable-wayland-compositor/tt
+flag supplied above you can remove the dummy ttwayland-egl.pc/tt
+pkg-config file which you may have installed from following an older
+version of this guide. This flag makes sure, that toytoolkit (Weston
+demo programs) does not use Cairo EGL. EGL does not work for clients due
+to the EGL Wayland platform being unimplemented on the Raspberry Pi./p
 
 pWeston should work by running ttweston/tt. Remember to have the
 environment set up, and it is useful to have an ssh session open to your
-- 
1.8.4

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

Problems building Weston/demo applications on the Raspberry Pi

[Silvan Jegen]

Hi everyone

I am trying to build libwayland, Weston and the demo programs on my
Raspberry Pi following the guide at

http://wayland.freedesktop.org/raspberrypi.html

When compiling Weston and the demo programs however, I get the attached
error and no Makefile is being created.

What confuses me is that the guide says that When adding
--disable-wayland-compositor you can remove the dummy wayland-egl.pc
pkg-config file, except that the --disable-wayland-compositor-flag is
present by default in the build guide and the wayland-egl.pc file has
not been mentioned before at all (i. e. does not seem to belong to the
group of pkg-conf files that the guide mentions earlier).

Is there something obvious I am missing?

Thanks for your support!


Kind regards,

Silvan

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I /home/pi/local/share/aclocal --force 
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether make supports nested variables... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for a sed that does not truncate output... /bin/sed
checking build system type... armv6l-unknown-linux-gnueabihf
checking host system type... armv6l-unknown-linux-gnueabihf
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands +=... yes
checking how to convert armv6l-unknown-linux-gnueabihf file names to 
armv6l-unknown-linux-gnueabihf format... func_convert_file_noop
checking how to convert armv6l-unknown-linux-gnueabihf file names to toolchain 
format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC