Re: libweston program segfaults on weston_compositor_load_backend

[adlo]

On Thu, 2018-05-03 at 14:12 +0300, Pekka Paalanen wrote:
> 
> what's the backtrace from gdb for that?
> 

Is this any help?

#0  0x in  ()
#1  0x7799c88c in weston_log (fmt=fmt@entry=0x779b6a7e
"Loading module '%s'\n") at libweston/log.c:75
#2  0x779a603c in weston_load_module (name=name@entry=0x779
b6b24 "wayland-backend.so", entrypoint=entrypoint@entry=0x779b6aae
"weston_backend_init") at libweston/compositor.c:6375
#3  0x779a6264 in weston_compositor_load_backend
(compositor=0x611090, backend=backend@entry=
WESTON_BACKEND_WAYLAND, config_base=config_base@entry=0x7fffdc5
0)
at libweston/compositor.c:6485
#4  0x00400704 in main (argc=, argv=)
at ../main.c:42
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

pointer-constraints protocol: Removing lifetimes and persistency

[Las]

I propose removing the concept of persistent pointer constraints and lifetimes 
in the pointer constraints protocol.

This would vastly simplify the implementation of the protocol in the 
compositor, but slightly increase the complexity in the client.

Benefits:

The compositor wouldn't have to keep track of pointer constraints for each 
valid surface,
since only one pointer constraint could then exist per seat.

The compositor would also not have to actively check the position of the 
pointer on the surface, since if it is inactive, it does not exist, and can 
therefore not be reactivated, so it is not needed to check if the pointer is in 
the region of a pointer constraint.

This would also allow the removal of regions for locked pointers, since then 
only confined pointers would make use of them.

Detriments:

The client would have to recreate the pointer constraint each time the pointer 
enters the valid region, instead of just making a persistent pointer constraint.
This is very simple for previously NULL regions, since you can just recreate it 
on each pointer enter event, although it's a bit more complex for complex 
regions, since the client will have to handle that itself now.___
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

[Dorota Czaplejewicz]

On Thu, 3 May 2018 21:55:40 +0200
Silvan Jegen  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  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.

> 
> > 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.
> 
> Of course the Unicode code points will have to be parsed at some point
> if you want to render them. Using byte-offsets just lets you do that at
> a later stage if your libraries support UTF-8.
> 
> 
Doesn't that chiefly depend on what kind of the text rendering library though? 
As far as I understand, passing text to rendering is necessary to calculate the 
cursor position. At the same time, it doesn't matter much for the calculations 
whether the cursor offset is in bytes or code points - the library does the 
parsing in the last step anyway.

I think you mean that if the rendering library accepts byte offsets as the only 
format, the application would have to parse the UTF-8 unnecessarily. I agree 
with this, but I'm not sure we should optimize for this case. Other libraries 
may support only code points instead.

Did I understand you correctly?

Cheers,
Dorota


pgpRcIk5PzRW4.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

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

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

[Dorota Czaplejewicz]

On Thu, 3 May 2018 20:47:27 +0200
Silvan Jegen  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 
> > 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 

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 

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

[Dorota Czaplejewicz]

From: Carlos Garnacho 

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 enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the 

Re: libweston program segfaults on weston_compositor_load_backend

[Pekka Paalanen]

On Wed, 02 May 2018 22:19:21 +0100
adlo  wrote:

> I am trying to write a simple test compositor using libweston, but it
> segfaults on weston_compositor_load_backend.

Hi,

what's the backtrace from gdb for that?


Thanks,
pq


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

[PATCH libinput] udev: copy the trackpoint sensitivity directly from sysfs

[Peter Hutterer]

Rather than going the roundabout way of having systemd set the sensitivity
followed by us reading that udev property and hoping, just take the
sensitivity directly from sysfs. This makes us basically independent of what
systemd does (or the lack of systemd, where that is a problem).

It does remove the chance of users to trick libinput by manually adjusting the
sensitivity after the udev rules kicked in, but seriously, we should work on
fixing acceleration properly in that case.

Signed-off-by: Peter Hutterer 
---
 src/evdev.c| 4 ++--
 udev/90-libinput-model-quirks.rules.in | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 4f69d8e0..5537408c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1220,7 +1220,7 @@ evdev_get_trackpoint_range(struct evdev_device *device)
   HTTP_DOC_LINK);
 
prop = udev_device_get_property_value(device->udev_device,
- "POINTINGSTICK_SENSITIVITY");
+ 
"LIBINPUT_ATTR_TRACKPOINT_SENSITIVITY");
if (prop) {
int sensitivity;
 
@@ -1236,7 +1236,7 @@ evdev_get_trackpoint_range(struct evdev_device *device)
sensitivity/DEFAULT_TRACKPOINT_SENSITIVITY;
 
evdev_log_debug(device,
-   "trackpoint udev sensitivity is %d\n",
+   "trackpoint sensitivity is %d\n",
sensitivity);
}
 
diff --git a/udev/90-libinput-model-quirks.rules.in 
b/udev/90-libinput-model-quirks.rules.in
index 5ddc0ba4..7c73f0a6 100644
--- a/udev/90-libinput-model-quirks.rules.in
+++ b/udev/90-libinput-model-quirks.rules.in
@@ -48,4 +48,8 @@ KERNELS=="input*", \
 KERNELS=="input*", \
   IMPORT{builtin}="hwdb 
'libinput:name:$attr{name}:dt:$attr{[devicetree/base]model}'"
 
+ENV{ID_INPUT_POINTINGSTICK}=="1", \
+  ATTRS{sensitivity}=="?*", \
+  ENV{LIBINPUT_ATTR_TRACKPOINT_SENSITIVITY}="$attr{sensitivity}"
+
 LABEL="libinput_model_quirks_end"
-- 
2.14.3

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