Our case is when the view is the same as output being disabled/disconnected.
There's not need to check the views' output with the output being disabled
because weston_view_assign_output() already changes the output of the view when
the output has been disabled/disconnected hence the check is not ne
On Thu, 8 Feb 2018 13:53:54 +
"Ucan, Emre (ADITG/ESB)" wrote:
> Hi Pekka,
>
> Yes I saw a similar problem when I tested previous ivi patches.
> I run make clean & make & make check. Then it worked.
>
> Maybe it is releated to weston-tests-env changes from this commit:
> https://cgit.freede
Hi Peter,
I'm trying to reproduce said choppy movement now and I can't. It might
just be that I imagined that it improved.
Sorry for wasting your time :/
Best Regards,
Tomas Vestelind
On 01/11/2018 11:02 PM, Peter Hutterer wrote:
> On Tue, Jan 09, 2018 at 10:41:54AM +0100, Tomas Vestelind wrote
Hi Pekka,
Yes I saw a similar problem when I tested previous ivi patches.
I run make clean & make & make check. Then it worked.
Maybe it is releated to weston-tests-env changes from this commit:
https://cgit.freedesktop.org/wayland/weston/commit/?id=0707b0e5d48fa6f1ac41ea60c2adc2e6430c7425
?
B
On Wed, 7 Feb 2018 16:54:30 +0100
Emre Ucan wrote:
> it is assigned in weston_view_assign_outputs
>
> Signed-off-by: Emre Ucan
> ---
> ivi-shell/ivi-layout.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index 3c52ce1..ea31dea 100644
Add a test to check that we can destroy and create the test seat. Since
after test seat destruction the test client releases any associated
input resources, this test also checks that libweston properly handles
release requests for inert input resources.
Signed-off-by: Alexandros Frantzis
---
Cha
The current test client code waits for all wl_seat globals to arrive
before checking them and deciding which one is the test seat global to
use for the input object. Test code that needs to add/remove test seats
would have to call the client_set_input() function for any seat changes
to take effect.
The current test client code completely ignores removal of globals.
This commit updates the code to properly handle removal of globals in
general, and of seat globals in particular. This ensures that the test
client objects are in sync with the server and any relevant resources
are released accordi
Properly clean up all sub-objects (e.g., weston_pointer_client objects)
when a weston_pointer object is destroyed. The clean-up ensures that the
server is able to safely handle client requests to any associated
pointer resources, which, as a consenquence of a weston_pointer
destruction, have now be
When a weston seat or input object is destroyed, any associated client
resources should become inert and put in a state in which they can
safely handle client requests. Currently, client requests to such
resources may lead to crashes and/or memory errors in the server.
This patchset aims to fix (o
Fix init_pointer_constraint so that it creates a valid, but inert,
resource if a NULL weston_pointer value is passed in. In that case no
constraint object is associated with the resource, but this is not an
issue since affected code can already handle NULL constraint objects.
Signed-off-by: Alexan
Use the weston-test-desktop-shell to run the devices tests, instead of
the currently used desktop-shell. The test desktop shell doesn't
interact with temporary globals (e.g. wl_seat), thus avoiding an
inherent race in the current wayland protocol when removing globals.
This will allow us to safely
Ensure the server can safely handle client requests for wl_seat resource
that have become inert due to weston_seat object release and subsequent
destruction.
The clean-up involves, among other things, unsetting the destroyed
weston_seat object from the user data of wl_seat resources, and handling
On Thu, 8 Feb 2018 14:45:06 +0200
Pekka Paalanen wrote:
> On Wed, 7 Feb 2018 12:36:18 +0200
> Pekka Paalanen wrote:
>
> > On Wed, 7 Feb 2018 10:19:39 +
> > "Ucan, Emre (ADITG/ESB)" wrote:
> >
> > > Hi Pekka,
> > >
> > > Yes, I know that it is an ABI breakage. But there is already anoth
On Wed, 7 Feb 2018 12:36:18 +0200
Pekka Paalanen wrote:
> On Wed, 7 Feb 2018 10:19:39 +
> "Ucan, Emre (ADITG/ESB)" wrote:
>
> > Hi Pekka,
> >
> > Yes, I know that it is an ABI breakage. But there is already another
> > ABI breakage in compositor.h:
> > fbf165f5e89576730eed4a7e3979100311c4f
15 matches
Mail list logo
