Hello,
I just tagged and uploaded 1.3 RC2 (version 1.2.92). The most
critical fixes in this second release candidate are the touch event
fixes from Neil. We also have fixes for the weston-launch rewrite to
work better with the fbdev and rpi backends, a fix for the
sleep/wakeup state machine and
On Wed, Oct 02, 2013 at 05:44:29PM +0200, David Herrmann wrote:
> Hi Peter
>
> On Fri, Sep 20, 2013 at 12:35 PM, Peter Hutterer
> wrote:
> > I've been working on a protocol extension to support graphics tablets such
> > as the Wacom set of tablets, and I'm now at the stage where I'd like a few
>
On Oct 2, 2013 10:06 AM, "Neil Roberts" wrote:
>
> I don't think this function would help in cases where the buffer is
> released after the frame is drawn but the compositor is not drawing
> anything else. Ie, if the events were like this:
>
> 1 - client attaches a buffer and waits for the next re
From: Alexandru DAMIAN
Current behaviour of the tty parameter is to take effect
only if there is a new user starting up.
Since it is useful to start weston-launch with a command line
specified tty, I'm changing the semantics of the tty parameter:
* the argument to the --tty parameter is now man
From: Alexandru DAMIAN
EGLInt is not always uint32_t so we need
to make sure we use the right int size for the format.
Signed-off-by: Alexandru DAMIAN
---
src/compositor-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index
Hi Peter
On Fri, Sep 20, 2013 at 12:35 PM, Peter Hutterer
wrote:
> I've been working on a protocol extension to support graphics tablets such
> as the Wacom set of tablets, and I'm now at the stage where I'd like a few
> comments. I was hoping that I'd get a full implementation before XDC but
> u
This patch fixes a race when a client releases a named buffer before the
server had the time to handle 'wl_drm_create_buffer'. When triggered,
the server would fail to create the buffer since the client already
having destroyed it, throwing out the client in the process with a
protocol error.
To s
I don't think this function would help in cases where the buffer is
released after the frame is drawn but the compositor is not drawing
anything else. Ie, if the events were like this:
1 - client attaches a buffer and waits for the next release
2 - compositor redraws a frame
3 - the redraw complet
All,
Perhaps a simpler approach would be better. We could add a function to
wayland-server called wl_client_post_event_queue which would simply set the
wants_flush flag on the client connection. This function would be fast
,require no I/O, and safe to call multiple times so Weston could simply
cal
Hi,
On 1 October 2013 18:50, Kristian Høgsberg wrote:
> On Tue, Oct 01, 2013 at 12:53:03PM +0200, Tomeu Vizoso wrote:
>> The EGL implementation on the RPi allocates a front and a back
>> DispmanX resources for each EGLSurface, which we composite along
>> the others.
>
> Is this something you want
Hello,
I agree with you Bill
Otherwise it's impossible to update plugins when the API will change.
Marc.
2013/9/30 Bill Spitzak
> On 09/29/2013 02:56 PM, Kristian Høgsberg wrote:
>
> No, we don't guarantee plugin API compatiblity from 1.2 to 1.3. We
>> may remove functions, structure fields,
The EGL implementation on the RPi allocates a front and a back
DispmanX resources for each EGLSurface, which we composite along
the others.
---
v2: Added a stub for vc_dispmanx_get_handle_from_wl_buffer
src/rpi-bcm-stubs.h | 7 ++
src/rpi-renderer.c | 253 +
On dt, 2013-10-01 at 13:50 +0100, Neil Roberts wrote:
> Hi
>
> José Bollo writes:
>
> > That is a really interesting point.
> > I have two questions about it:
> > - Is it normal that the client trucates the buffer? Is your patch
> >designed to allow normal operations? or to allow forbiden u
13 matches
Mail list logo
