On dt, 2013-10-01 at 13:50 +0100, Neil Roberts wrote:
Hi
José Bollo jo...@nonadev.net 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
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
Hello,
I agree with you Bill
Otherwise it's impossible to update plugins when the API will change.
Marc.
2013/9/30 Bill Spitzak spit...@gmail.com
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,
Hi,
On 1 October 2013 18:50, Kristian Høgsberg hoegsb...@gmail.com 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
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
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
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
Hi Peter
On Fri, Sep 20, 2013 at 12:35 PM, Peter Hutterer
peter.hutte...@who-t.net 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
From: Alexandru DAMIAN alexandru.dam...@intel.com
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 alexandru.dam...@intel.com
---
src/compositor-drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Alexandru DAMIAN alexandru.dam...@intel.com
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
On Oct 2, 2013 10:06 AM, Neil Roberts n...@linux.intel.com 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
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
peter.hutte...@who-t.net 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
12 matches
Mail list logo
