On Mon, Apr 30, 2012 at 3:58 PM, Kristian Høgsberg wrote:
> On Fri, Apr 27, 2012 at 11:09:55PM +0200, Arnaud Vrac wrote:
>> On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
>> wrote:
>> > On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>> >> Hello everyone,
>> >>
>> >> I am hitti
On Fri, Apr 27, 2012 at 11:09:55PM +0200, Arnaud Vrac wrote:
> On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
> wrote:
> > On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
> >> Hello everyone,
> >>
> >> I am hitting a bug when using Qt5 and wayland on an embedded platform,
> >> f
On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
wrote:
> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backend. The problem is that Qt5
>> (Q
On Wed, 25 Apr 2012 12:58:59 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > There was some talk about an alternative implementation: to let
> > eglSwapBuffers never block, instead block when a rendering operation is
> > about to use a buffer that should have already been made available
Pekka Paalanen wrote:
There was some talk about an alternative implementation: to let
eglSwapBuffers never block, instead block when a rendering operation is
about to use a buffer that should have already been made available by
swapBuffers, but didn't actually happen yet. The DRM architecture
On Tue, 24 Apr 2012 11:03:29 -0700
Bill Spitzak wrote:
> On 04/24/2012 09:15 AM, Arnaud Vrac wrote:
>
> >> Sorry for probably wasting your time, but why does "EGL make this
> >> impossible"?
> >
> > Because eglSwapBuffers is unfortunately a blocking call.
>
> After reading all these emails a bu
On 04/24/2012 09:15 AM, Arnaud Vrac wrote:
Sorry for probably wasting your time, but why does "EGL make this
impossible"?
Because eglSwapBuffers is unfortunately a blocking call.
After reading all these emails a bunch more times, I *think* I
understand the problem.
First of all, this is f
On Tue, Apr 24, 2012 at 6:13 PM, Arnaud Vrac wrote:
> On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
> wrote:
>> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>>> Hello everyone,
>>>
>>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>>> for which I ha
On 04/24/2012 09:13 AM, Arnaud Vrac wrote:
Still keep a single wl_display with proper locking, and add a
wl_connection for each thread. For the wl_display thread, the
connection would still be made through the unix socket, while for the
other thread you would prepare a socketpair on the client s
2012/4/24 Bill Spitzak :
> On 04/20/2012 03:27 PM, Kristian Høgsberg wrote:
>
>> "Initial assumption for wl_display and related objects was that it is
>> not going to be thread safe, and you have to lock access to the wl API
>> yourself if you're going to use it from multiple threads. It's a
>> va
On Fri, Apr 20, 2012 at 10:06 PM, Kristian Hoegsberg
wrote:
> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backend. The problem is that Qt5
>> (Q
On 04/20/2012 03:27 PM, Kristian Høgsberg wrote:
"Initial assumption for wl_display and related objects was that it is
not going to be thread safe, and you have to lock access to the wl API
yourself if you're going to use it from multiple threads. It's a
valid assumption and it avoids fine grai
On Fri, Apr 20, 2012 at 5:56 PM, Bill Spitzak wrote:
> Kristian Høgsberg wrote:
>
>>> 1) Toughen up and add locking around all access to wl_display. It's
>>> not as much code as it sounds, there are actually only a few entry
>>> points that need locking.
>
>
> This could be free if the *caller*
Kristian Høgsberg wrote:
1) Toughen up and add locking around all access to wl_display. It's
not as much code as it sounds, there are actually only a few entry
points that need locking.
This could be free if the *caller* is required to lock/unlock. Ie there
is a wl_lock/unlock call that
Really attached now.
Kristian
On Fri, Apr 20, 2012 at 4:06 PM, Kristian Hoegsberg wrote:
> On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
>> Hello everyone,
>>
>> I am hitting a bug when using Qt5 and wayland on an embedded platform,
>> for which I have written a custom EGL backend
On Thu, Apr 19, 2012 at 03:38:39PM +0200, Arnaud Vrac wrote:
> Hello everyone,
>
> I am hitting a bug when using Qt5 and wayland on an embedded platform,
> for which I have written a custom EGL backend. The problem is that Qt5
> (QtQuick2 actually) renders in a separate thread, when the wayland
>
On 04/20, Arnaud Vrac wrote:
> On Fri, Apr 20, 2012 at 6:33 PM, wrote:
> > I guess you're not going to get a useful response here.
> > That seems really unfortunate to me. Please open a bug
> > here, so we at least have a proper record of the problem:
> > https://bugs.freedesktop.org/enter_bug.c
On Fri, Apr 20, 2012 at 6:33 PM, wrote:
> I guess you're not going to get a useful response here.
> That seems really unfortunate to me. Please open a bug
> here, so we at least have a proper record of the problem:
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland
Thanks darxus, I do
I guess you're not going to get a useful response here.
That seems really unfortunate to me. Please open a bug
here, so we at least have a proper record of the problem:
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland
On 04/19, Arnaud Vrac wrote:
> Hello everyone,
>
> I am hitting a bu
Hello everyone,
I am hitting a bug when using Qt5 and wayland on an embedded platform,
for which I have written a custom EGL backend. The problem is that Qt5
(QtQuick2 actually) renders in a separate thread, when the wayland
display has been created in the main thread. I know there is a patch
for
20 matches
Mail list logo
