g the lock,
and what should be the cursor position when a lock is ended ?
Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
e seeing this?
No:
https://bugs.freedesktop.org/show_bug.cgi?id=81800
I think Axel Davy (Cc'd) tracked down the problem at some point.
Thanks, I need to work on my bug report searching skills... ;-)
Boyan Ding in the bug report tracked it down to commit
45ebc4e3fac7f1a8516
amage) with a frame+commit (even with the old buffer not released), to
be sure to get current behaviour.
I don't think having to do an attach with the old buffer is a good idea,
and I favor Pekka's proposition.
Axel Davy
On 22/02/2014, Jason Ekstrand wrote :
Pekka,
Sorry this e-ma
tation, since
my XWayland Present patches are incompatible with yours.
Axel Davy
On 20/02/2014, Rui Matos wrote :
Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event
hout an attach,
damage, or any other state changes. The frequency at which the frame
callbacks are called by the compositor is not defined,
but the client can expect it to be similar to the refresh rate if the
surface is focused and visible on the screen.
Axel Davy
___
/sprite (and should take into account there could be
several cursors).
Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
-dri3-present
Thanks.
Axel Davy
On 11/02/2014, Rui Matos wrote :
Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.
---
So, I'm not sure why there was this co
; > from the wish to handle resizing better, preferably without
> > clearing the buffer queue.
> >
> > All the changed details are probably too much to describe here,
> > so it is maybe better to look at this as a new proposal. It
> &
On 08/02/2014, Axel Davy wrote :
Hi,
On 08/02/2014, Jason Ekstrand wrote :
For each surface with queued content updates and matching main
output, the compositor picks the update with the highest
timestamp no later than a half frame period after the predicted
y really want to work that way, why not doing this queue client
side? It doesn't need to be done in the compositor.
Hope that helps,
--Jason Ekstrand
Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
The new mesa you built has no egl_gallium.so (since you have
--disable-gallium-egl), but you have not removed the old egl_gallium.so,
and it tries to load it, since it is here.
Axel Davy
Le 07/02/2014 18:30, Bill Spitzak a écrit :
In order to try to compile the new xserver for wayland, I
Your bug is likely to be coming from the combination old XWayland/
recent Weston.
Try with main xwayland branch and xf86-video-wayland (forget about the
outdated things you built)
Xwayland is divided in two parts: the Xwayland window manager (weston)
and ... Xwayland (in the Xserver)
Axel
Signed-off-by: Axel Davy
---
configure.ac| 11 +--
hw/xfree86/xwayland/Makefile.am | 2 +-
present/Makefile.am | 24 +++-
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 052a557
Signed-off-by: Axel Davy
---
present/present.c | 77 +++
present/present_priv.h| 37 +++
present/present_wayland.c | 240 ++
3 files changed, 333 insertions(+), 21 deletions(-)
create mode 100644 present/present_wayland.c
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy
---
hw/xfree86/xwayland/Makefile.am| 1 +
hw/xfree86/xwayland/xwayland-events.c | 220 +
hw/xfree86/xwayland/xwayland-private.h | 9 ++
hw/xfree86/xwayland/xwayland
ile a flip had been done, and it needed a change to the
XWayland API change I proposed, that's why I post a new one
that is more adapted.
Don't hesitate to give comments.
Axel Davy (3):
Add XWayland API with Present support in mind.
Initial Present Wayland support
Update configu
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy
---
v3: remove the reversal of the frame_todo list, but instead fill it it
reverse order. The code has been tested with an experimental XWayland
Present support.
v2: fix indentation + move a call from patch 1
neccessary for dri3
Signed-off-by: Axel Davy
---
v2: fix indentation
hw/xfree86/xwayland/xwayland-drm.c | 56 --
hw/xfree86/xwayland/xwayland.h | 3 ++
2 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/hw/xfree86/xwayland/xwayland-drm.c
b
This change enables to change the window pixmap, and have
xwayland send the correct buffer to the Wayland compositor.
Signed-off-by: Axel Davy
---
v2: fix indentation and remove a call that had to be in patch 4
hw/xfree86/xwayland/xwayland-drm.c | 10 +++-
hw/xfree86/xwayland/xwayland
And allows to create wl_buffers from fds instead of gem names.
Signed-off-by: Axel Davy
---
v2: fix indentation
hw/xfree86/xwayland/drm.xml| 45 +-
hw/xfree86/xwayland/xwayland-drm.c | 108 +
hw/xfree86/xwayland/xwayland-private.h
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy
---
v2: fix indentation + move a call from patch 1 to here + add a missing call
hw/xfree86/xwayland/Makefile.am| 1 +
hw/xfree86/xwayland/xwayland-events.c | 216
And allows to create wl_buffers from fds instead of gem names.
Signed-off-by: Axel Davy
---
hw/xfree86/xwayland/drm.xml| 45 +-
hw/xfree86/xwayland/xwayland-drm.c | 106 +
hw/xfree86/xwayland/xwayland-private.h | 1 +
hw/xfree86
neccessary for dri3
Signed-off-by: Axel Davy
---
hw/xfree86/xwayland/xwayland-drm.c | 56 --
hw/xfree86/xwayland/xwayland.h | 3 ++
2 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/hw/xfree86/xwayland/xwayland-drm.c
b/hw/xfree86/xwayland
This change enables to change the window pixmap, and have
xwayland send the correct buffer to the Wayland compositor.
Signed-off-by: Axel Davy
---
hw/xfree86/xwayland/xwayland-drm.c | 10 +++-
hw/xfree86/xwayland/xwayland-private.h | 10 +++-
hw/xfree86/xwayland/xwayland-window.c | 87
to improve DRI2 support. Now they are designed to work for Present
support.
The code to support Present for XWayland (using this API) is not finished
yet.
Axel Davy (4):
Move the wl_buffer from xwl_window to xwl_pixmap
Add support to render-nodes.
Add function to get new fd of the graphic
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy
---
hw/xfree86/xwayland/Makefile.am| 1 +
hw/xfree86/xwayland/xwayland-events.c | 210 +
hw/xfree86/xwayland/xwayland-private.h | 8 ++
hw/xfree86/xwayland/xwayland
Signed-off-by: Axel Davy
---
xwayland/window-manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index d475e36..1bb9825 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -2214,7 +2214,7
This fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73517
Signed-off-by: Axel Davy
---
xwayland/window-manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 70c8cf7..d475e36 100644
--- a/xwayland/window
urface_schedule_repaint(surface);
+
+ surface->pending.newly_attached = 0;
}
static void
Reviewed-by: Axel Davy
It would probably need similarly to call weston_view_update_transform and
weston_surface_schedule_repaint in weston_view_create in case a buffer is
already attache
to what the server can do.
For example you could advertise if the server supports mmap, etc.
Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
We would like the compositor to receive the commited buffer
as soon as possible, so it has the time to treat it, and
release old ones. We shouldn't rely on the client
to flush the queue for us.
Signed-off-by: Axel Davy
---
We flush the wl_display after we flush the drawable.
src/egl/dr
flush_with_flags, when available, allows the driver to throttle.
Using this suppress input lag issues that can be observed in heavy
rendering situations on non-intel cards.
Signed-off-by: Axel Davy
---
We must fight input lag, since we can have situations where
the sent buffer hasn't
The opaque region is not set when we start the nested
compositor fullscreen. This patch fixes this.
Signed-off-by: Axel Davy
---
Jason Ekstrand prefer we use wayland_output_set_fullscreen,
which will -besides other things- set the opaque region.
src/compositor-wayland.c | 1 +
1 file changed
The opaque region is not set when we start the nested
compositor fullscreen. This patch fixes this.
Signed-off-by: Axel Davy
---
src/compositor-wayland.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index ed3923b..08741d9 100644
r solution: for example poll a first time with
1ms instead of 10ms,
and then if no buffers are free, try again with a poll of 10ms.
Why not doing directly another roundtrip?
Axel Davy
Le 15/11/2013 14:50, Neil Roberts a écrit :
The Wayland EGL platform now respects the eglSwapInterval value. Th
I've posted a patch, which prevents wm->focus_window to be a window
without frame.
This solves the same bug than this patch, but looks better to me.
http://lists.freedesktop.org/archives/wayland-devel/2013-November/012008.html
Axel Davy
Le 15/11/2013 11:25, Axel Davy a écrit :
Th
An unmapped window shouldn't be the input focus.
This solves some remaining Weston crashes with XWayland,
because we assume wm->focus_window has a frame.
Signed-off-by: Axel Davy
---
src/xwayland/window-manager.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/xwaylan
This patch (Again, I had the same), solves the last bugs for XWayland,
but for this one, I'm not sure it is the correct fix.
In fact it would mean than focus_window would be an unmapped windows,
which looks strange to me.
Axel Davy
Le 15/11/2013 11:01, Dima Ryazanov a écrit :
Fixes a cra
ze
and weston_wm_window_get_child_position are called on
an unmapped window.
In these cases, the decorations are not yet drawn,
so we must behave as if there was no decoration.
"
Correct the commit message ("I don't know if this correct" shouldn't be in),
and this is
Reviewed-by: Ax
I've looked deeply in the code to find the remaining xwayland bugs.
I'll publish later a fix for these. The remaining bugs are due to
accessing to the frame field on
unmapped windows.
Your patch solves all the issues with the view field.
Your patch is tested and
Reviewed-by: Axel D
I have tested your patch, but it doesn't solve all the bugs occuring in
XWayland because of views (take vlc, go to the menu, crash).
It appears ok to me to set view to NULL at these locations, but there's
probably something more to do.
Axel Davy
On 15/11/2013, Dima Ryazanov wro
ggest too to be able to change that after creation (ie be able to
send a new request to tell to the compositor the client wants to change
of mode,
and the client would get the back the same event than before, telling
him what the compositor wants him to use).
Axel Davy
Le 07/11/2013 10:32, R
On 11/11/2013, Pekka Paalanen wrote :
Hi Axel
On Fri, 08 Nov 2013 23:49:25 +0100
Axel Davy wrote:
Hello,
I've read carefully your new protocol proposition,
but I think it doesn't meet the requirements to implement
the X Present extension for XWayland.
The problem is that I need
esentation time, I'll have to use a queue
of length one with a requested time of 0. Your spec says it should
behave correctly.
I'm adding a few comments behind.
Axel Davy
On 08/11/2013, Frederic Plourde wrote :
Hi,
The field is already set - correctly - in the backend switch_mode.
setting output->current_mode to mode in compositor.c leads to bugs,
since mode can be freed by the shell.
For example, the shell allocates it on the stack for
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER
---
src/compositor.c | 1 -
1
be the application I tested used
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER, and it seems to be buggy.
Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
The field is already set - correctly - in the backend switch_mode.
setting output->current_mode to mode in compositor.c leads to bugs,
since mode can be freed by the shell.
For example, the shell allocates it on the stack for
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER
Signed-off-by: Axel D
Solve a bug for some fullscreen clients which wouldn't show up.
Signed-off-by: Axel Davy
---
src/compositor-drm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 4f015d1..6a2500b 100644
--- a/src/compositor-drm.c
Thanks for this.
I've just realized that using 32 bits ints won't be sufficient.
Is there a way in the protocol to have requests with 64 bits int args,
and callback with 64 bits int args too?
Axel Davy
Jiergir Ogoerg wrote :
Just a reminder on how clocks differ (on LInux) from o
James Courtier-Dutton wrote :
Just one question. Which clock is being used. Ideally a monotony one,
or even better, a configurable one. We would normally not want these
timestamps affected by the user changing the system time.
James
X calculates ust time with the function GetTickCount.
so if you feel some sentence are incorrect,
please help me to correct them.
Axel Davy (1):
Add presentation_time and hit requests to wl_surface.
protocol/wayland.xml | 70 +---
1 file changed, 67 insertions(+), 3 delet
These two new requests are designed to help video players
to synchronize what is displayed on the screen and the audio,
and to implement the X Present extension in XWayland.
---
protocol/wayland.xml | 70 +---
1 file changed, 67 insertions(+), 3 dele
On 28/10/2013, Daniel Stone wrote :
For programers having to cope with X and Wayland, and to better support the
Present extension, I reiterate my suggestion
to do something similar to the X Present extension.
Anything in particular? I'm well aware of Present, but am not entirely
sure what you'r
On 28/10/2013, Frederic Plourde wrote :
I don't know about current/future driver support for this new GSYNC
technology... but you know what, I definitely agree with Pekka as we
should get this protocol and basic buffer queuing implementation
reviewd and working for the general case for now and
On Mon, 28 Oct 2013, Pekka Paalanen wrote:
The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe how GSYNC affects timings.
I don't under
On 22/10/2013 17:23, David Herrmann wrote :
Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on
the render-node. So if someone else tests this, you might need the
same hacks. I will try to find the code in mesa that requires this.
David
This comes from 'intel_region_alloc_fo
On 22/10/2013 17:23, David Herrmann wrote :
Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on
the render-node. So if someone else tests this, you might need the
same hacks. I will try to find the code in mesa that requires this.
David
This comes from 'intel_region_alloc_for_
On Wed, 23 Oct 2013, Jason Ekstrand wrote:
There may also be a way that we can sidestep the whole issue. (I suggested
this to Axel Davy [mannerov] and it worked for him in his wlglamor DDX.)
The solution is to send a
wl_display.sync request immediately after the commit. This will force
to suspend, and will resume when it gets
the feedbacks.
Axel Davy
Le 21/10/2013 16:33, James Courtier-Dutton a écrit :
Hi,
One last thing to consider, regarding the clock used and the timestamps.
The video frames should pause during system suspend, and continue
a specific time, etc), I think we should start with my new API
proposal, and replace it (and dri2 support in the DDX), when
we have the materials Wayland side to implement the Present
extension.
Axel Davy
Given the recent discussion on the xorg-devel mailing list,
I think this new API shouldn'
> On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote:
>> I've tried benchmarking AsyncSwap with the phoronix-test-suite,
>> and I was surprised to see a regression with Openarena and Xonotic.
>> According to dri devs, it is because, since I do an exchange
, it should always be a
gain.
And since Gnome 3.10 doesn't bypass compositing yet, if I have well
understood, then
for them it'll always be a performance benefit.
Axel Davy
The current XWayland API has no functionality to help the DDXs
implement ScheduleSwap. This new API proposal intro
sts.x.org/archives/xorg-devel/2012-November/034446.html>
http://lists.x.org/archives/xorg-devel/2013-September/037661.html_
Le 17/10/2013 00:16, Axel Davy a écrit :
The patch is a modified version of a Chris Wilson patch of 2011.
It makes the X server call AsyncSwap, defined by the DDX, when
it
The new API:
.Allows to use the frame event.
.Introduces a new object: xwl_buffer, that allow to manipulate
the buffer sent to the Wayland compositor.
.Allows to use the release event.
Signed-off-by: Axel Davy
---
hw/xfree86/xwayland/Makefile.am| 2 +
hw/xfree86/xwayland/xwayland
The patch is a modified version of a Chris Wilson patch of 2011.
It makes the X server call AsyncSwap, defined by the DDX, when
it does a dri2 swap and swap_interval is 0. It allows the DDX
to avoid the copy if possible, and reduce tearings.
Signed-off-by: Axel Davy
---
hw/xfree86/dri2/dri2.c
wl_display used by
XWayland.
The API introduces a new object: xwl_buffer, which is use to manipulate
the buffers linked with Wayland and the buffer exposed by the
windows shown to the Wayland compositor.
Axel Davy (2):
Patch to the Xserver to support AsyncSwap
Add new XWayland API.
hw
ode can be found here:
https://github.com/axeldavy/xf86-video-wlglamor
Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
How does this work if the primary output frequency is more than the
clone output?
I'm afraid the weston log might become very big after a while when
running a such a configuration
Axel Davy
Le 18/09/2013 05:50, Xiong Zhang a écrit :
Only repsone to primary output repaint request; Pr
Yes:
http://cgit.freedesktop.org/wayland/weston/commit/?id=ca43f0942e23356a0a0f3e08e4d20a8a31b4d629
Axel Davy
On Tue, 17 Sep 2013, Tarnyko wrote:
Great ! Do you by chance have the reference of the patch, and know if it's
applied on the Wayland, Weston, Xorg... repository ?
Regards
Axel
After the fade or zoom effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.
This patch add a reset function in weston_surface_animation to reset
some variables the effects affect.
Signed-off-by: Axel Davy
---
src/animation.c | 24
1
Did you test with git master? There has been a patch recently about this.
Axel Davy
Le 17/09/2013 10:37, Tarnyko a écrit :
Hi Giulio, Bill,
We were originally investigating a problem happening when using X/GTK
applications under XWayland ; most of the menus appeared badly
positioned when
oving the mouse at the
same time during a few minutes.
If I remove the two calls to set_title in XWayland (removing only one
doesn't remove the crash), it fixes the crash.
Axel Davy
On Mon, 16 Sep 2013, Giulio Camuffo wrote:
How does it crash? And when doing what?
Giulio
2013/9/15
This patch makes XWayland often crash for me.
Axel Davy
Le 11/09/2013 18:20, Giulio Camuffo a écrit :
add a new function pointer to the weston_shell_interface struct that
shells will set accordingly.
---
src/compositor.h | 2 ++
src/shell.c | 11
better, but I should add too to set
surface->alpha to 1.0 for the shell_fade effect and the FADE_OUT parameter.
Kristian, what do you like better?
Axel Davy
Le 12/09/2013 10:27, Giulio Camuffo a écrit :
Shouldn't this set the alpha to the target alpha instead of 1? What if
i fade fro
After the fade or zoom effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.
Signed-off-by: Axel Davy
---
src/animation.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/animation.c b/src/animation.c
index 0b2fa95..9603115 100644
--- a/src/animation.c
sent is not
released and waits for the next frame. If there is only 3 buffers, the
client will be without free buffers and blocked in eglSwapBuffers.
I may be wrong, but I think the number of back buffers should be set to 4.
Axel Davy
Le 11/09/2013 20:28, Neil Roberts a écrit :
The Wayland
ed
to check it.
Axel Davy
Le 09/09/2013 20:39, Neil Roberts a écrit :
Is this problem specific to the extension or is it a general problem?
Would there not be the same issue if the session compositor wasn't using
the extension but was creating textures from the client surfaces
instead? Presuma
e are on the dedicated card (max performance mode), we need a
copy because the clients use tiling: your extension should fail (or do a
copy).
Axel Davy
System compositor: set up wl_drm to import buffers on card A
Session compositor: Detects it is on card B and not the card of
wl_drm. Crea
tiling mode)
clients in the session compositor: card B. buffer is created on B, when
creating it, tiling was enabled.
In this configuration, your function should fail or do a copy (because A
won't recognize the tiling mode of B)
Axel Davy
> This adds an extensio
After these effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.
Signed-off-by: Axel Davy
---
src/shell.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/shell.c b/src/shell.c
index cd94aa5..d7e2d1e 100644
--- a/src
80 matches
Mail list logo
