Kristian Høgsberg wrote:
This patch introduces new API to solve both problems. We add
int wl_display_acquire_fd(struct wl_display *display);
I'm a little confused, some sample source code showing where the acquire
call goes would help. My guess is each thread should do this:
The current thread model assumes that the application or toolkit will have
a thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only the main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
thread t
On Wed, Apr 10, 2013 at 2:29 PM, Uli Schlachter wrote:
> On 10.04.2013 17:16, Kristian Høgsberg wrote:
> [...]
>> +WL_EXPORT int
>> +wl_display_acquire_fd(struct wl_display *display)
>> +{
>> + char c = 0;
>> + int old_state;
>> +
>> + pthread_mutex_lock(&display->mutex);
>> +
>> +
On 10.04.2013 17:16, Kristian Høgsberg wrote:
[...]
> +WL_EXPORT int
> +wl_display_acquire_fd(struct wl_display *display)
> +{
> + char c = 0;
> + int old_state;
> +
> + pthread_mutex_lock(&display->mutex);
> +
> + if (display->reader_state == LOCKED_READER &&
> + !pthread_
Hi Kristian,
Your patch calls like 3 times "pthread_cond_wait(..)", shouldn't each of
these calls be in a loop?
>From a book on pthreads:
"You should always wait for a condition variable in a loop, to protect
against errors,
multiprocessor races, and spurious wakeups."
Kind Regards
_
Can wl_display_acquire_fd be merged into wl_display_dispatch_pending()?
It looks like you never want to call one without the other, and it also
appears that wl_display_dispatch releases it so this would be symmetric.
On 04/10/2013 08:16 AM, Kristian Høgsberg wrote:
wl_display_dispatch
The current thread model assumes that the application or toolkit will have
a thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only the main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
thread t
On Wed, Apr 10, 2013 at 6:51 AM, Pekka Paalanen wrote:
> On Sun, 07 Apr 2013 21:51:44 -0400
> Weng Xuetian wrote:
>
> > can't this be extended in a way that in a more key value like favor?
> >
> > Input method annouce what value it's interested first, and text_model
> > set the corresponding val
On Sun, 07 Apr 2013 21:51:44 -0400
Weng Xuetian wrote:
> can't this be extended in a way that in a more key value like favor?
>
> Input method annouce what value it's interested first, and text_model
> set the corresponding value upon change. Now, for every field you
> want to set, will introduc
From: Rob Bradford
Following the addition of the EGL_WIDTH and EGL_HEIGHT this function should
return EGL_TRUE for those requested attributes too.
---
src/egl/drivers/dri2/egl_dri2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl
10 matches
Mail list logo
