Re: Implementing show_window_menu in Weston

[Dima Ryazanov]

Got it, thanks Jonas!

On Wed, Nov 9, 2016 at 8:56 PM, Jonas Ådahl  wrote:

> On Wed, Nov 09, 2016 at 03:21:30PM -0800, Dima Ryazanov wrote:
> > Hi,
> >
> > I'd like to take a shot at implementing window menus (from xdg-shell) in
> > Weston - but I don't have a good understanding of how the compositor,
> > shell, etc. interact, so wanted to ask about it first.
> >
> > Looks like the entry point for it would be the "show_window_menu" member
> of
> > "shell_desktop_api" in desktop-shell/shell.c. Now, this may be a stupid
> > question, but should the menu be implemented in the compositor or in the
> > shell client?
>
> The drawing should be done by the shell client. In the reference shell
> implementation in weston, the compositor never does any drawing (well,
> except for Xwayland window frame I suppose), and that should continue to
> be the case.
>
> >
> > I feel like it's the compositor's job, but I can't find any examples of
> > drawing things or handling input in the compositor itself. If I do it in
> > the desktop shell, then I could use the existing popup menu code in
> > clients/window.c - but would have to add a bunch of requests to the
> desktop
> > shell protocol just to display the menu and handle the menu items. What's
> > the correct approach?
>
> Yes, add new requests/events to the weston desktop shell protocol.
> It's a private protocol so there is no need to care about any backward
> compatibility.
>
>
> Jonas
>
> >
> > Thanks!
>
> > ___
> > 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: Re:RE: Can't register bind ivi-application

[Ucan, Emre (ADITG/SW1)]

Hi Anthenony,

You can put it under /etc/xdg/weston/ directory

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

> -Original Message-
> From: wayland-devel [mailto:wayland-devel-
> boun...@lists.freedesktop.org] On Behalf Of ???
> Sent: Mittwoch, 9. November 2016 21:06
> To: Ucan, Emre (ADITG/SW1)
> Cc: wayland-devel
> Subject: Re:RE: Can't register bind ivi-application
> 
> Hi Ucan:
> 
> I have another question that what path the weston.ini and 
> ivi-controller.so
> should be put in ARM(Navigation machine), usr/lib or other?
> I used i.mx6 chip provided by NXP, and build kenerl and uBoot from Yocto.
> 
> 
> 
> 在 2016-07-05 16:05:17，"Ucan, Emre (ADITG/SW1)"  jv.com> 写道：
> 
> 
>   Hi Anthenony,
> 
> 
> 
>   You have to configure weston to use ivi-shell. The default shell is
> desktop shell.
> 
> 
> 
>   You can find an example weston.ini under ivi-shell/weston.ini.in,
> which uses hmi-controller.
> 
> 
> 
>   If you want to use ivi-controller. You can use this weston.ini:
> 
> 
> 
>   [core]
> 
>   shell=ivi-shell.so
> 
> 
> 
>   [ivi-shell]
> 
>   ivi-module=ivi-controller.so
> 
>   ivi-input-module=ivi-input-controller.so
> 
> 
> 
>   Best regards
> 
>   Emre Ucan
>   Software Group I (ADITG/SW1)
> 
>   Tel. +49 5121 49 6937
> 
>   From: wayland-devel [mailto:wayland-devel-
> boun...@lists.freedesktop.org] On Behalf Of ???
>   Sent: Dienstag, 5. Juli 2016 08:18
>   To: wayland-devel
>   Subject: Can't register bind ivi-application
> 
> 
> 
>   Hi,all:
> 
> 
> 
>   static void
> 
>   registry_handle_global(void *data, struct wl_registry *registry,
> 
>uint32_t name, const char *interface, 
> uint32_t version)
> 
>   {
> 
> struct display *d = data;
> 
> 
> 
> if (strcmp(interface, "wl_compositor") == 0) {
> 
> d->compositor =
> 
> wl_registry_bind(registry, name,
> 
>  
> _compositor_interface, 1);
> 
> } else if (strcmp(interface, "xdg_shell") == 0) {
> 
> d->shell = wl_registry_bind(registry, name,
> 
> 
> _shell_interface, 1);
> 
> xdg_shell_add_listener(d->shell, 
> _shell_listener, d);
> 
> xdg_shell_use_unstable_version(d->shell,
> XDG_VERSION);
> 
> } else if (strcmp(interface, "wl_seat") == 0) {
> 
> d->seat = wl_registry_bind(registry, name,
> 
>
> _seat_interface, 1);
> 
> wl_seat_add_listener(d->seat, _listener, d);
> 
> } else if (strcmp(interface, "wl_shm") == 0) {
> 
> d->shm = wl_registry_bind(registry, name,
> 
>   
> _shm_interface, 1);
> 
> d->cursor_theme = wl_cursor_theme_load(NULL, 32, 
> d-
> >shm);
> 
> if (!d->cursor_theme) {
> 
> fprintf(stderr, "unable to load 
> default theme\n");
> 
> return;
> 
> }
> 
> d->default_cursor =
> 
> 
> wl_cursor_theme_get_cursor(d->cursor_theme,
> "left_ptr");
> 
> if (!d->default_cursor) {
> 
> fprintf(stderr, "unable to load 
> default left
> pointer\n");
> 
> // TODO: abort ?
> 
> }
> 
> } else if (strcmp(interface, "ivi_application") == 0) {
> 
> d->ivi_application =
> 
> wl_registry_bind(registry, name,
> 
>  
> _application_interface, 1);
> 
> }
> 
>   }
> 
> 
> 
>   In sample code simple-egl, when I registered global handle, the d-
> >ivi_application was alwasys NULL.
> 
>   So I printed some log to see the value of 'interface'.
> 
>   wl_compositor
> 
>   wl_subcompositor
> 
>   wl_scaler
> 
>   presentation
> 
>   wl_data_device_manager
> 
>   wl_shm
> 
>   wl_viv
> 
>   wl_viv
> 
>   wl_output
> 
>   wl_input_panel
> 
>   wl_text_input_manager
> 
>   wl_shell
> 
>   xdg_shell
> 
>   desktop_shell
> 
>   workspace_manager
> 
>   screenshooter
> 
> 
> 
>   I found there is no ivi_application. I don't know the reason for this.
> 
>   Does anyone have the same problem as me？
> 
> 
> 

Re: Shell surface positioning

[Jonas Ådahl]

On Wed, Nov 09, 2016 at 10:30:45AM +0100, Jan Synacek wrote:
> Hello,
> 
> I'm playing around with libwayland-client, implementing a simple
> application. I made the middle mouse button move the "window" using
> wl_shell_surface_move() when the button is pressed, which works. What
> I don't understand, though, is how do I make the compositor position
> the "window" when it's created? I would like to position it somewhere
> else than 0,0 in monitor coordinates.

There is currently no protocol for hinting about how a surface should be
positioned. There most likely will not be a protocol that has "place me
at (x, y)" but rather more like "center me", "restore previous position"
or something more high level like that.

> 
> Additionally, are clients expected to draw their decorations? If yes,
> does that mean creating subsurfaces that respond to pointer events?

With wl_shell and xdg_shell, then yes. You can do it however you want,
either like Qt and GTK+ by simply drawing both the frame and the content
one single surface, or by using multiple surfaces, combining them using
wl_subcompositor to form a single "window".


Jonas

> 
> Cheers,
> -- 
> Jan Synacek
> Software Engineer, Red Hat
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes

[Peter Hutterer]

Because we already rely on it for xkb anyway. This is a retrofit, which is not
ideal but I'm not sure any compositor out there uses anything else. Might as
well define it.

Signed-off-by: Peter Hutterer 
---
A side-note here: my first version sent to Jonas privately had a reserved
range for any key with the highest bit set. The idea here was to have a
range defined that we'll never touch during protocol updates so that vendors
who need some custom key code have a place to escape to.

Note that by custom key code I don't mean "gaming mouse sends custom key X"
but rather "this is an integrated compositor + client stack solution and the
key only makes sense in this context".

I took it out of this version now, maybe it makes sense to add this though.

Also, I think the DTD needs a  tag :)

 protocol/wayland.xml | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 6c6d078..dcc29fe 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1893,6 +1893,14 @@
enter event.
 The time argument is a timestamp with millisecond
 granularity, with an undefined base.
+
+   The button is a button code as defined in the Linux kernel's
+   linux/input-event-codes.h header file, e.g. BTN_LEFT.
+
+   Any 16-bit button code value is reserved for future additions to the
+   kernel's event code list. All other button codes above 0x are
+   currently undefined but may be used in future versions of this
+   protocol.
   
 
   
@@ -2154,6 +2162,16 @@
A key was pressed or released.
 The time argument is a timestamp with millisecond
 granularity, with an undefined base.
+
+   The key is a key code as defined in the Linux kernel's
+   linux/input-event-codes.h header file, e.g. KEY_A. The key
+   represents a physical key on the keyboard and is unaffected by the
+   keyboard layout applied.
+
+   Any 16-bit key code value is reserved for future additions to the
+   kernel's event code list. All other key codes above 0x are
+   currently undefined but may be used in future versions of this
+   protocol.
   
 
   
-- 
2.9.3

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

[PATCH wayland] protocol: indentation fixes

[Peter Hutterer]

8 spaces changed to one tab

Signed-off-by: Peter Hutterer 
---
 protocol/wayland.xml | 100 +--
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 6c6d078..bcc228f 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -129,7 +129,7 @@
 
   
Binds a new, client-created object to the server using the
-specified name as the identifier.
+   specified name as the identifier.
   
   
   
@@ -139,9 +139,9 @@
   
Notify the client of global objects.
 
-The event notifies the client that a global object with
-the given name is now available, and it implements the
-given version of the given interface.
+   The event notifies the client that a global object with
+   the given name is now available, and it implements the
+   given version of the given interface.
   
   
   
@@ -152,10 +152,10 @@
   
Notify the client of removed global objects.
 
-This event notifies the client that the global identified
-by name is no longer available.  If the client bound to
-the global using the bind request, the client should now
-destroy that object.
+   This event notifies the client that the global identified
+   by name is no longer available.  If the client bound to
+   the global using the bind request, the client should now
+   destroy that object.
 
The object remains valid and requests to the object will be
ignored until the client destroys it, to avoid races between
@@ -357,7 +357,7 @@
 
The pool can be used to create shared memory based buffer
objects.  The server will mmap size bytes of the passed file
-descriptor, to use as backing memory for the pool.
+   descriptor, to use as backing memory for the pool.
   
 
   
@@ -924,14 +924,14 @@
 
 
   
-Create a new data source.
+   Create a new data source.
   
   
 
 
 
   
-Create a new data device for a given seat.
+   Create a new data device for a given seat.
   
   
   
@@ -1320,7 +1320,7 @@
 
 
   
-These errors can be emitted in response to wl_surface requests.
+   These errors can be emitted in response to wl_surface requests.
   
   
   
@@ -1679,8 +1679,8 @@
 
 
   
-This is a bitmask of capabilities this seat has; if a member is
-set, then it is present on the seat.
+   This is a bitmask of capabilities this seat has; if a member is
+   set, then it is present on the seat.
   
   
   
@@ -1878,7 +1878,7 @@
 
 
   
-Describes the physical state of a button that produced the button
+   Describes the physical state of a button that produced the button
event.
   
   
@@ -1891,8 +1891,8 @@
 
The location of the click is given by the last motion or
enter event.
-The time argument is a timestamp with millisecond
-granularity, with an undefined base.
+   The time argument is a timestamp with millisecond
+   granularity, with an undefined base.
   
 
   
@@ -2106,7 +2106,7 @@
   
   
+summary="libxkbcommon compatible; to determine the xkb keycode, 
clients must add 8 to the key event keycode"/>
 
 
 
@@ -2152,8 +2152,8 @@
 
   
A key was pressed or released.
-The time argument is a timestamp with millisecond
-granularity, with an undefined base.
+   The time argument is a timestamp with millisecond
+   granularity, with an undefined base.
   
 
   
@@ -2185,24 +2185,24 @@
 
 
   
-Informs the client about the keyboard's repeat rate and delay.
+   Informs the client about the keyboard's repeat rate and delay.
 
-This event is sent as soon as the wl_keyboard object has been created,
-and is guaranteed to be received by the client before any key press
-event.
+   This event is sent as soon as the wl_keyboard object has been created,
+   and is guaranteed to be received by the client before any key press
+   event.
 
-Negative values for either rate or delay are illegal. A rate of zero
-will disable any repeating (regardless of the value of delay).
+   Negative values for either rate or delay are illegal. A rate of zero
+   will disable any repeating (regardless of the value of delay).
 
-This event can be sent later on as well with a new value if necessary,
-so clients should continue listening for the event past the creation
-of wl_keyboard.
+   This event can be sent later on as well with a new value if necessary,
+   so clients should continue listening for the event past the creation
+   of wl_keyboard.
  

Re: Implementing show_window_menu in Weston

[Jonas Ådahl]

On Wed, Nov 09, 2016 at 03:21:30PM -0800, Dima Ryazanov wrote:
> Hi,
> 
> I'd like to take a shot at implementing window menus (from xdg-shell) in
> Weston - but I don't have a good understanding of how the compositor,
> shell, etc. interact, so wanted to ask about it first.
> 
> Looks like the entry point for it would be the "show_window_menu" member of
> "shell_desktop_api" in desktop-shell/shell.c. Now, this may be a stupid
> question, but should the menu be implemented in the compositor or in the
> shell client?

The drawing should be done by the shell client. In the reference shell
implementation in weston, the compositor never does any drawing (well,
except for Xwayland window frame I suppose), and that should continue to
be the case.

> 
> I feel like it's the compositor's job, but I can't find any examples of
> drawing things or handling input in the compositor itself. If I do it in
> the desktop shell, then I could use the existing popup menu code in
> clients/window.c - but would have to add a bunch of requests to the desktop
> shell protocol just to display the menu and handle the menu items. What's
> the correct approach?

Yes, add new requests/events to the weston desktop shell protocol.
It's a private protocol so there is no need to care about any backward
compatibility.


Jonas

> 
> Thanks!

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

Implementing show_window_menu in Weston

[Dima Ryazanov]

Hi,

I'd like to take a shot at implementing window menus (from xdg-shell) in
Weston - but I don't have a good understanding of how the compositor,
shell, etc. interact, so wanted to ask about it first.

Looks like the entry point for it would be the "show_window_menu" member of
"shell_desktop_api" in desktop-shell/shell.c. Now, this may be a stupid
question, but should the menu be implemented in the compositor or in the
shell client?

I feel like it's the compositor's job, but I can't find any examples of
drawing things or handling input in the compositor itself. If I do it in
the desktop shell, then I could use the existing popup menu code in
clients/window.c - but would have to add a bunch of requests to the desktop
shell protocol just to display the menu and handle the menu items. What's
the correct approach?

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

[PATCH] doc: Fix a typo in the client documentation

[Moritz Kiefer]

Signed-off-by: Moritz Kiefer 
---
 doc/publican/sources/Client.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/publican/sources/Client.xml b/doc/publican/sources/Client.xml
index fcdd2f2..19bf3e9 100644
--- a/doc/publican/sources/Client.xml
+++ b/doc/publican/sources/Client.xml
@@ -30,7 +30,7 @@
 object created.
   
   
-Though some conveinence functions are provided, libwayland-client
+Though some convenience functions are provided, libwayland-client
 is designed to allow the calling code to wait for events, so that
 different polling mechanisms can be used. A file descriptor is
 provided, when it becomes ready for reading the calling code can
-- 
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

[Bill Spitzak]

On Tue, Oct 25, 2016 at 3:06 PM, Peter Hutterer
 wrote:

>> @Bill: What Peter says is that there could be some applications that
>> implement special behaviors when you scroll while at the end of the
>> file/context/whatever.

I don't see

>> Scroll events are sends to the window below the
>> mouse whatever the focus, and so moving the mouse over another window while
>> a kinetic scroll is pending will send scroll events to this new window...
>> Bad behavior...

Actually this seems bad even for normal scroll events. I am using a
trackball with a scroll ring, and it mechanically has some "kinetic"
behavior, and in fact I just tried it and quickly scrolling then
moving the mouse across a border causes both applications to scroll
some. My impression is that this is not desirable, I want all the
scrolling to go to the first program. The compositor could use a
timeout to do this.

My trackball is a good example of why I worry about clients doing
gestures. I probably need to disable kinetic scroll and I am worried
that some clients will not do it. It would be nice if this could
easily be disabled in every app by doing something to the compositor.

I would also look into how kinetic scrolling is being done on other
platforms. If they send events then we are really going to be stuck
trying to make RDP work on those platforms. You would at least have to
turn off the kinetic scrolling in the clients.

>> Well, maybe using a new scroll source
>> like LIBINPUT_POINTER_AXIS_SOURCE_KINETIC could be a solution. I'm very new
>> to wayland and co. and I'm probably not legitimate to make this kind of
>> choices.
>
> I don't think this would help much. Adding a new source means we need it
> supported on the client side by toolkits. And at that point you might
> as well get proper kinetic scrolling implemented there.

The extra field added to the scroll events would be in a new api
version. Old clients would still get all the events but could not tell
if they were kinetic scroll events or not.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re:RE: Can't register bind ivi-application

[袁嘉伟]

Hi Ucan:


I have another question that what path the weston.ini and ivi-controller.so 
should be put in ARM(Navigation machine), usr/lib or other?
I used i.mx6 chip provided by NXP, and build kenerl and uBoot from Yocto.




在 2016-07-05 16:05:17，"Ucan, Emre (ADITG/SW1)"  写道：


Hi Anthenony,

 

You have to configure weston to use ivi-shell. The default shell is desktop 
shell.

 

You can find an example weston.ini under ivi-shell/weston.ini.in, which uses 
hmi-controller.

 

If you want to use ivi-controller. You can use this weston.ini:

 

[core]

shell=ivi-shell.so

 

[ivi-shell]

ivi-module=ivi-controller.so

ivi-input-module=ivi-input-controller.so

 

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of ???
Sent: Dienstag, 5. Juli 2016 08:18
To: wayland-devel
Subject: Can't register bind ivi-application

 

Hi,all:

 

static void

registry_handle_global(void *data, struct wl_registry *registry,

 uint32_t name, const char *interface, uint32_t 
version)

{

  struct display *d = data;

 

  if (strcmp(interface, "wl_compositor") == 0) {

  d->compositor =

  wl_registry_bind(registry, name,

   
_compositor_interface, 1);

  } else if (strcmp(interface, "xdg_shell") == 0) {

  d->shell = wl_registry_bind(registry, name,

  
_shell_interface, 1);

  xdg_shell_add_listener(d->shell, _shell_listener, d);

  xdg_shell_use_unstable_version(d->shell, XDG_VERSION);

  } else if (strcmp(interface, "wl_seat") == 0) {

  d->seat = wl_registry_bind(registry, name,

 
_seat_interface, 1);

  wl_seat_add_listener(d->seat, _listener, d);

  } else if (strcmp(interface, "wl_shm") == 0) {

  d->shm = wl_registry_bind(registry, name,

_shm_interface, 
1);

  d->cursor_theme = wl_cursor_theme_load(NULL, 32, d->shm);

  if (!d->cursor_theme) {

  fprintf(stderr, "unable to load default 
theme\n");

  return;

  }

  d->default_cursor =

  wl_cursor_theme_get_cursor(d->cursor_theme, 
"left_ptr");

  if (!d->default_cursor) {

  fprintf(stderr, "unable to load default left 
pointer\n");

  // TODO: abort ?

  }

  } else if (strcmp(interface, "ivi_application") == 0) {

  d->ivi_application =

  wl_registry_bind(registry, name,

   
_application_interface, 1);

  }

}



In sample code simple-egl, when I registered global handle, the 
d->ivi_application was alwasys NULL.

So I printed some log to see the value of 'interface'.   

wl_compositor 

wl_subcompositor 

wl_scaler 

presentation 

wl_data_device_manager 

wl_shm 

wl_viv 

wl_viv 

wl_output 

wl_input_panel 

wl_text_input_manager 

wl_shell 

xdg_shell 

desktop_shell 

workspace_manager 

screenshooter 

 

I found there is no ivi_application. I don't know the reason for this.

Does anyone have the same problem as me？

 

 

Best regards,

Anthenony

 

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

Weston

[Nikola Popovic]

Greetings.

I have installed yocto on my board. Im planing to run weston just after 
boot finish and to run chromium inside weston. Is it possible to write 
some script or something in weston.ini to run chromium inside weston 
without my interaction.


Tnx!

--
Nikola Popovic
Software Engineer
Tel: +381 21 4801 1304
E-mail : nikola.popo...@rt-rk.com

RT-RK LLC
Narodnog fronta 23a
21000 Novi Sad
Serbia
www.rt-rk.com

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

Re: Kinetic scroll in libinput Xorg driver

[Bill Spitzak]

On Mon, Oct 24, 2016 at 5:31 PM, Peter Hutterer
 wrote:
> On Mon, Oct 24, 2016 at 06:42:31PM +, Alexis BRENON @Wayland wrote:
>> Hello everyone,
>>
>> I would like to implement kinetic scroll in the libinput driver for Xorg.
>>
>> I know that it's probably not the intended use of libinput ; as explained
>> in the documentation, it's the client that have to manage that.
>>
>> However, as an Xorg user not happy with the synaptics driver, I would like
>> to add a similar feature (fixing small disagreements encountered with
>> synaptics) to libinput, allowing Xorg users to easily move to libinput
>> without losing this feature.
>>
>> My first idea is to implement the kinetic scroll using a thread that sends
>> axis events as long as there is no button event, key event or motion event
>> higher than a threshold.
>>
>> It makes some time since the last time I developed in C, and maybe it's not
>> the better way to do it. I would be happy to hear your advices.
>>
>> One thing I'm thinking of is then to add some options in the Xorg
>> configuration file to enable/disable this feature, choose the events
>> stopping the kinetic scroll and change some thresholds. This will allow to
>> easily disable this feature in the future in case the clients manage the
>> kinetic scroll on their own.
>>
>> What do you think of this? Is there someone already working on it? Is my
>> proposition a good way to implement it?
>
> simple answer - "no". sorry :)
>
> there are two reasons we didn't implement kinetic scrolling in libinput. one
> is the series of bugs we have in synaptics with stopping scrolling at the
> right time (leading to inadvertent zooms, etc.). that's easier in libinput
> because we know about all devices but the fundamental problem remains - a
> driver cannot know when kinetic scrolling is appropriate. e.g. sending
> scroll events when the document is already at the bottom?

What? How about *normal* scroll events. Seems to be no problem with
sending them "when the document is at the bottom". Amazingly the
client apps have logic and are able to ignore these events! Will
wonders never cease!

> What's the
> threshold going to be? A single pixel movement may land you in another
> window that you don't want to send scroll events to.

What? Can you give an example of an api where scrolling that is
accepted by a client can also cause the focus to change? Also it sure
seems like if scrolling can change the focus then the compositor
better be well aware of the events. Of course if "kinetic scrolling"
should not change the focus, but "normal scrolling" does, this is
trivially solved by making these be different events.

? A two-pixel movement
> may be considered acceptable to not stop scroll events.
> A shift+scroll may be acceptable in one application but not in another.

All of these are good reasons for libinput to do it. Then there is
consistent behavior between clients, rather than every toolkit and
client doing it's own thing.

> Pushing this to the toolkits and applications is the only sane long-term
> solution. Anything else gives us a short-term solution that in two-three
> years time we'll just waste time having to working around.

The solution to all your objections is trivial: make the kinetic
scroll events distinguishable from the normal scroll events. Then if a
client really can't deal with the kinetic scrolling supplied by
libinput, it can ignore these events and do it itself.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] compositor-drm: Restore use-current-mode functionality

[Daniel Stone]

Hi Armin,

On 9 October 2016 at 22:48, Armin Krezović  wrote:
> diff --git a/compositor/main.c b/compositor/main.c
> index 320305c..ffeadfb 100644
> --- a/compositor/main.c
> +++ b/compositor/main.c
> @@ -78,6 +78,7 @@ struct wet_compositor {
> struct weston_config *config;
> struct wet_output_config *parsed_options;
> struct wl_listener pending_output_listener;
> +   bool drm_use_current_mode;
>  };

I'm fairly confused about this one, though I freely admit I didn't
track the libweston config work, so may have missed something.

What makes --use-current-mode special enough that it should be the
only such option inside struct wet_compositor? What makes it different
to, say, use_pixman, which lives in the DRM backend?

> @@ -1138,7 +1140,7 @@ drm_backend_output_configure(struct wl_listener 
> *listener, void *data)
> weston_output_disable(output);
> free(s);
> return;
> -   } else if (strcmp(s, "current") == 0) {
> +   } else if (wet->drm_use_current_mode || strcmp(s, "current") == 0) {
> mode = WESTON_DRM_BACKEND_OUTPUT_CURRENT;
> } else if (strcmp(s, "preferred") != 0) {
> modeline = s;

What would the difference be to making this check be 'else if
(b->use_current_mode || strcmp(s, "current") == 0)'?

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

Re: [PATCH weston 2/3] ivi-shell: describe members of type wl_list

[Pekka Paalanen]

On Fri, 1 Jul 2016 09:34:50 +
"Ucan, Emre (ADITG/SW1)"  wrote:

> I wrote comments on which list they are used with
> 
> Signed-off-by: Emre Ucan 
> ---
>  ivi-shell/ivi-layout-private.h|   16 
>  ivi-shell/ivi-layout-transition.c |2 +-
>  ivi-shell/ivi-layout.c|6 +++---
>  3 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/ivi-shell/ivi-layout-private.h b/ivi-shell/ivi-layout-private.h
> index c1b52f1..f7b2de9 100644
> --- a/ivi-shell/ivi-layout-private.h
> +++ b/ivi-shell/ivi-layout-private.h
> @@ -43,7 +43,7 @@ struct ivi_layout_view {
>  };
>  
>  struct ivi_layout_surface {
> - struct wl_list link;
> + struct wl_list link;/* ivi_layout::surface_list */
>   struct wl_signal property_changed;
>   int32_t update_count;
>   uint32_t id_surface;
> @@ -61,7 +61,7 @@ struct ivi_layout_surface {
>  };
>  
>  struct ivi_layout_layer {
> - struct wl_list link;
> + struct wl_list link;/* ivi_layout::surface_list */

Hi,

I fixed this one to say "layer_list" instead.

>   struct wl_signal property_changed;
>   uint32_t id_layer;
>  
> @@ -73,13 +73,13 @@ struct ivi_layout_layer {
>   struct {
>   struct ivi_layout_layer_properties prop;
>   struct wl_list view_list;   /* 
> ivi_layout_view::pending_link */
> - struct wl_list link;
> + struct wl_list link;/* 
> ivi_layout_screen::pending.layer_list */
>   } pending;
>  
>   struct {
>   int dirty;
>   struct wl_list view_list;   /* ivi_layout_view::order_link 
> */
> - struct wl_list link;
> + struct wl_list link;/* ivi_layout_screen::order.layer_list 
> */
>   } order;
>  
>   int32_t ref_count;
> @@ -88,9 +88,9 @@ struct ivi_layout_layer {
>  struct ivi_layout {
>   struct weston_compositor *compositor;
>  
> - struct wl_list surface_list;
> - struct wl_list layer_list;
> - struct wl_list screen_list;
> + struct wl_list surface_list;/* ivi_layout_surface::link */
> + struct wl_list layer_list;  /* ivi_layout_layer::link */
> + struct wl_list screen_list; /* ivi_layout_screen::link */
>   struct wl_list view_list;   /* ivi_layout_view::link */
>  
>   struct {
> @@ -107,7 +107,7 @@ struct ivi_layout {
>   struct weston_layer layout_layer;
>  
>   struct ivi_layout_transition_set *transitions;
> - struct wl_list pending_transition_list;
> + struct wl_list pending_transition_list; /* transition_node::link */
>  };
>  
>  struct ivi_layout *get_instance(void);
> diff --git a/ivi-shell/ivi-layout-transition.c 
> b/ivi-shell/ivi-layout-transition.c
> index 04b62a5..989ba71 100644
> --- a/ivi-shell/ivi-layout-transition.c
> +++ b/ivi-shell/ivi-layout-transition.c
> @@ -59,7 +59,7 @@ struct ivi_layout_transition {
>  
>  struct transition_node {
>   struct ivi_layout_transition *transition;
> - struct wl_list link;
> + struct wl_list link;/* ivi_layout::pending_transition_list */

I added a note about ivi_layout_transition_set::transition_list to this.

>  };
>  
>  static void layout_transition_destroy(struct ivi_layout_transition 
> *transition);
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index f8533f9..4e56ace 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -74,18 +74,18 @@
>  struct ivi_layout;
>  
>  struct ivi_layout_screen {
> - struct wl_list link;
> + struct wl_list link;/* ivi_layout::screen_list */
>  
>   struct ivi_layout *layout;
>   struct weston_output *output;
>  
>   struct {
> - struct wl_list layer_list;
> + struct wl_list layer_list;  /* 
> ivi_layout_layer::pending.link */
>   } pending;
>  
>   struct {
>   int dirty;
> - struct wl_list layer_list;
> + struct wl_list layer_list;  /* ivi_layout_layer::order.link 
> */
>   } order;
>  };
>  

Both patches pushed:
   967b6bc..7da3823  master -> master


Thanks,
pq


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

RE: [PATCH weston v2 3/3] ivi-shell: use zalloc instead of calloc

[Ucan, Emre (ADITG/SW1)]

Hi Pekka,

Thank you for your comment. You are right with your findings.

I will send a new patch to fix this issue.

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

> -Original Message-
> From: Pekka Paalanen [mailto:ppaala...@gmail.com]
> Sent: Mittwoch, 9. November 2016 11:32
> To: Yong Bakos; Ucan, Emre (ADITG/SW1)
> Cc: wayland-devel
> Subject: Re: [PATCH weston v2 3/3] ivi-shell: use zalloc instead of calloc
> 
> On Thu, 28 Jul 2016 10:23:00 -0700
> Yong Bakos  wrote:
> 
> > Hi Emre,
> >
> > > On Jul 28, 2016, at 7:14 AM, Ucan, Emre (ADITG/SW1)  jv.com> wrote:
> > >
> > > v2 changes:
> > > - use xzalloc
> > > - add an explicit include of xalloc.h in any .c file
> > >  that uses xzalloc.
> > >
> > > Signed-off-by: Emre Ucan 
> >
> > Is the intent of this patch to cause an exit() when memory allocation fails?
> > See my comments inline below.
> 
> Hi,
> 
> thanks for the comments, my replies below.
> 
> > > ---
> > > ivi-shell/hmi-controller.c|   35 
> > > ivi-shell/input-panel-ivi.c   |6 ++--
> > > ivi-shell/ivi-layout-transition.c |   62 
> > > +++
> > > ivi-shell/ivi-layout.c|   65 
> > > +++--
> > > 4 files changed, 38 insertions(+), 130 deletions(-)
> 
> > > diff --git a/ivi-shell/input-panel-ivi.c b/ivi-shell/input-panel-ivi.c
> > > index 581b56b..a563e31 100644
> > > --- a/ivi-shell/input-panel-ivi.c
> > > +++ b/ivi-shell/input-panel-ivi.c
> > > @@ -35,6 +35,7 @@
> > > #include "input-method-unstable-v1-server-protocol.h"
> > > #include "ivi-layout-private.h"
> > > #include "shared/helpers.h"
> > > +#include "shared/xalloc.h"
> > >
> > > struct input_panel_surface {
> > >   struct wl_resource *resource;
> > > @@ -236,10 +237,7 @@ create_input_panel_surface(struct ivi_shell
> *shell,
> > > {
> > >   struct input_panel_surface *input_panel_surface;
> > >
> > > - input_panel_surface = calloc(1, sizeof *input_panel_surface);
> > > - if (!input_panel_surface)
> > > - return NULL;
> > > -
> > > + input_panel_surface = xzalloc(sizeof *input_panel_surface);
> >
> > This seems like a change in behavior. When calloc fails, this function
> > will return NULL, triggering wl_resource_post_error at all call sites.
> > After this change, when xzalloc fails, fail_on_null will call exit().
> >
> > Just pointing this out in case it's not what you intended. (And if it is
> > intentional, it should be explained in the commit message.)
> 
> That's an excellent notice. However, I'll let is pass, since ivi-shell
> is full of exit-on-OOM cases and I don't think it has been seriously
> looked at. If it's important, it can be fixed in a follow-up. It's just
> a fixed-size struct alloc here.
> 
> > >   surface->configure = input_panel_configure;
> > >   surface->configure_private = input_panel_surface;
> > >   weston_surface_set_label_func(surface, input_panel_get_label);
> > > diff --git a/ivi-shell/ivi-layout-transition.c 
> > > b/ivi-shell/ivi-layout-transition.c
> > > index 989ba71..1175743 100644
> > > --- a/ivi-shell/ivi-layout-transition.c
> > > +++ b/ivi-shell/ivi-layout-transition.c
> > > @@ -35,6 +35,8 @@
> > > #include "ivi-layout-export.h"
> > > #include "ivi-layout-private.h"
> > >
> > > +#include "shared/xalloc.h"
> > > +
> > > struct ivi_layout_transition;
> > >
> > > typedef void (*ivi_layout_transition_frame_func)(
> > > @@ -185,12 +187,7 @@ ivi_layout_transition_set_create(struct
> weston_compositor *ec)
> > >   struct ivi_layout_transition_set *transitions;
> > >   struct wl_event_loop *loop;
> > >
> > > - transitions = malloc(sizeof(*transitions));
> > > - if (transitions == NULL) {
> > > - weston_log("%s: memory allocation fails\n", __func__);
> > > - return NULL;
> > > - }
> > > -
> > > + transitions = xzalloc(sizeof *transitions);
> >
> > Same per my comment above. Although, in this case, the
> > ivi_layout_transition_set_create call in ivi_layout_init_with_compositor
> > doesn't check for a NULL return anyway (!).
> 
> Heh, so exchanging a crash to an exit. I'm fine with that in this case.
> 
> > And, same for the remaining occurrences in this patch.
> 
> Right.
> 
> I would have let this patch pass otherwise, except there are actually
> quite a lot of these occurrences. The deal breaker is the following:
> 
> > > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> > > index 646eb05..48bec9d 100644
> > > --- a/ivi-shell/ivi-layout.c
> > > +++ b/ivi-shell/ivi-layout.c
> 
> > > @@ -1112,12 +1104,7 @@ ivi_layout_get_screens_under_layer(struct
> ivi_layout_layer *ivilayer,
> > >
> > >   if (length != 0) {
> > >   /* the Array must be free by module which called this
> function */
> > > - *ppArray = calloc(length, sizeof(struct weston_output *));
> > > - if (*ppArray == NULL) {
> > > - weston_log("fails to allocate 

Re: [PATCH weston v2 3/3] ivi-shell: use zalloc instead of calloc

[Pekka Paalanen]

On Thu, 28 Jul 2016 10:23:00 -0700
Yong Bakos  wrote:

> Hi Emre,
> 
> > On Jul 28, 2016, at 7:14 AM, Ucan, Emre (ADITG/SW1)  
> > wrote:
> > 
> > v2 changes:
> > - use xzalloc
> > - add an explicit include of xalloc.h in any .c file
> >  that uses xzalloc.
> > 
> > Signed-off-by: Emre Ucan   
> 
> Is the intent of this patch to cause an exit() when memory allocation fails?
> See my comments inline below.

Hi,

thanks for the comments, my replies below.

> > ---
> > ivi-shell/hmi-controller.c|   35 
> > ivi-shell/input-panel-ivi.c   |6 ++--
> > ivi-shell/ivi-layout-transition.c |   62 +++
> > ivi-shell/ivi-layout.c|   65 
> > +++--
> > 4 files changed, 38 insertions(+), 130 deletions(-)

> > diff --git a/ivi-shell/input-panel-ivi.c b/ivi-shell/input-panel-ivi.c
> > index 581b56b..a563e31 100644
> > --- a/ivi-shell/input-panel-ivi.c
> > +++ b/ivi-shell/input-panel-ivi.c
> > @@ -35,6 +35,7 @@
> > #include "input-method-unstable-v1-server-protocol.h"
> > #include "ivi-layout-private.h"
> > #include "shared/helpers.h"
> > +#include "shared/xalloc.h"
> > 
> > struct input_panel_surface {
> > struct wl_resource *resource;
> > @@ -236,10 +237,7 @@ create_input_panel_surface(struct ivi_shell *shell,
> > {
> > struct input_panel_surface *input_panel_surface;
> > 
> > -   input_panel_surface = calloc(1, sizeof *input_panel_surface);
> > -   if (!input_panel_surface)
> > -   return NULL;
> > -
> > +   input_panel_surface = xzalloc(sizeof *input_panel_surface);  
> 
> This seems like a change in behavior. When calloc fails, this function
> will return NULL, triggering wl_resource_post_error at all call sites.
> After this change, when xzalloc fails, fail_on_null will call exit().
> 
> Just pointing this out in case it's not what you intended. (And if it is
> intentional, it should be explained in the commit message.)

That's an excellent notice. However, I'll let is pass, since ivi-shell
is full of exit-on-OOM cases and I don't think it has been seriously
looked at. If it's important, it can be fixed in a follow-up. It's just
a fixed-size struct alloc here.

> > surface->configure = input_panel_configure;
> > surface->configure_private = input_panel_surface;
> > weston_surface_set_label_func(surface, input_panel_get_label);
> > diff --git a/ivi-shell/ivi-layout-transition.c 
> > b/ivi-shell/ivi-layout-transition.c
> > index 989ba71..1175743 100644
> > --- a/ivi-shell/ivi-layout-transition.c
> > +++ b/ivi-shell/ivi-layout-transition.c
> > @@ -35,6 +35,8 @@
> > #include "ivi-layout-export.h"
> > #include "ivi-layout-private.h"
> > 
> > +#include "shared/xalloc.h"
> > +
> > struct ivi_layout_transition;
> > 
> > typedef void (*ivi_layout_transition_frame_func)(
> > @@ -185,12 +187,7 @@ ivi_layout_transition_set_create(struct 
> > weston_compositor *ec)
> > struct ivi_layout_transition_set *transitions;
> > struct wl_event_loop *loop;
> > 
> > -   transitions = malloc(sizeof(*transitions));
> > -   if (transitions == NULL) {
> > -   weston_log("%s: memory allocation fails\n", __func__);
> > -   return NULL;
> > -   }
> > -
> > +   transitions = xzalloc(sizeof *transitions);  
> 
> Same per my comment above. Although, in this case, the
> ivi_layout_transition_set_create call in ivi_layout_init_with_compositor
> doesn't check for a NULL return anyway (!).

Heh, so exchanging a crash to an exit. I'm fine with that in this case.

> And, same for the remaining occurrences in this patch.

Right.

I would have let this patch pass otherwise, except there are actually
quite a lot of these occurrences. The deal breaker is the following:

> > diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> > index 646eb05..48bec9d 100644
> > --- a/ivi-shell/ivi-layout.c
> > +++ b/ivi-shell/ivi-layout.c

> > @@ -1112,12 +1104,7 @@ ivi_layout_get_screens_under_layer(struct 
> > ivi_layout_layer *ivilayer,
> > 
> > if (length != 0) {
> > /* the Array must be free by module which called this function 
> > */
> > -   *ppArray = calloc(length, sizeof(struct weston_output *));
> > -   if (*ppArray == NULL) {
> > -   weston_log("fails to allocate memory\n");
> > -   return IVI_FAILED;
> > -   }
> > -
> > +   *ppArray = xzalloc(sizeof(struct weston_output *) * length);

This is where I would not use xzalloc(), but calloc() is actually the
right one. Calloc will check for multiplication overflows, this here
does not.

It's probably not meaningful in this particular patch, but it's a habit
well learnt, so that's why I don't like this change.

There are many occurrences of this.


Thanks,
pq


pgp8Yw1XLQ08m.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list