[PATCH weston.ini.man v2] Improvement of weston.ini.man. Add key:shell and remove tablet-shell

2014-02-08 Thread Nobuhiko Tanibata
Add key:shell to CORE SECTION and move a example of desktop-shell from key:modules to key:shell. Add cms-colord.so to key:modules of CORE SECTION. Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp --- man/weston.ini.man | 17 ++--- 1 file changed, 14 insertions(+),

Is there any way to let compositor set the data in client space and then return back to client?

2014-02-08 Thread Wang, Quanxian
Hi, All I want to allocate some space in client, and let compositor set some data in this space and then return back to client. It seems like user data mechanism. Any way to implement that? Thanks Regards Quanxian Wang ___ wayland-devel mailing

Re: Help compiling mesa/gallium from git!

2014-02-08 Thread Pekka Paalanen
On Fri, 07 Feb 2014 09:54:36 -0800 Bill Spitzak spit...@gmail.com wrote: Okay, removing everything with gallium in it's name from the install worked. But make install in mesa puts it all back! Would clean fix this? What I am really interested in is the proper configure line for mesa. I am

[PATCH libinput] Make it possible to have persistent libinput_seat instances

2014-02-08 Thread Jonas Ådahl
With this patch, a user can keep a reference to a libinput_seat instance, which will cause the seat to never be unlinked from the libinput context nor destroyed. Previously, a when the last device of a seat was removed, the seat was unlinked and if a new device was discovered with a previously

Re: Is there any way to let compositor set the data in client space and then return back to client?

2014-02-08 Thread Pekka Paalanen
On Sat, 8 Feb 2014 08:19:06 + Wang, Quanxian quanxian.w...@intel.com wrote: Hi, All I want to allocate some space in client, and let compositor set some data in this space and then return back to client. It seems like user data mechanism. Any way to implement that? Not really,

Re: Is there any way to let compositor set the data in client space and then return back to client?

2014-02-08 Thread Jasper St. Pierre
Well, there's not really anything that allows process A to arbitrarily modify process B's memory. The only thing that's close is memory-mapped files, and that's already what we use to share image data between the client and the compositor. There's also memfd, which is more secure than a

Re: [PATCH wayland 3/3] Add a debug handler and use it to print out protocol debug messages

2014-02-08 Thread Jason Ekstrand
On Wed, Feb 5, 2014 at 11:04 PM, Kristian Høgsberg hoegsb...@gmail.comwrote: On Wed, Dec 18, 2013 at 08:56:20PM -0600, Jason Ekstrand wrote: In order to keep from overloading the debug handler, we first squash the entire message into a string and call wl_debug once. Signed-off-by: Jason

Re: [PATCH weston.ini.man v2] Improvement of weston.ini.man. Add key:shell and remove tablet-shell

2014-02-08 Thread Jason Ekstrand
Nobuhiko, These look pretty good assuming they properly compile (I can't compile the man format in my head). One comment, is that we should probably remove tablet-shell from the list of shells while we're at it. It might also be worth noting that this can be used to load other shell plugins than

[PATCH] [weston] Don't crash when eglCreateContext fails

2014-02-08 Thread Mariusz Ceier
eglCreateContext fails with every EGLConfig that nvidia blob 334.16 provides causing NULL pointer dereference in gl_renderer_destroy when destroying fragment and fan bindings. This should fix #74699. Signed-off-by: Mariusz Ceier mceier+wayl...@gmail.com --- src/gl-renderer.c | 6 -- 1 file

Re: [RFC v2] Wayland presentation extension (video protocol)

2014-02-08 Thread Jason Ekstrand
More comments! On Fri, Jan 31, 2014 at 7:29 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 30 Jan 2014 17:35:17 +0200 Pekka Paalanen ppaala...@gmail.com wrote: The v1 proposal is here: http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html In v2 the

Re: [RFC v2] Wayland presentation extension (video protocol)

2014-02-08 Thread Jason Ekstrand
On Wed, Feb 5, 2014 at 1:32 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 30 Jan 2014 17:35:17 +0200 Pekka Paalanen ppaala...@gmail.com wrote: Hi, it's time for a take two on the Wayland presentation extension. 1. Introduction The v1 proposal is here:

Re: [RFC v2] Wayland presentation extension (video protocol)

2014-02-08 Thread Axel Davy
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 presentation time. The

Re: [RFC v2] Wayland presentation extension (video protocol)

2014-02-08 Thread Jason Ekstrand
OK, that makes more sense. Thank you for stating it in terms of intervals. I still need to think about it a bit more. On Feb 8, 2014 4:14 PM, Axel Davy axel.d...@ens.fr wrote: On 08/02/2014, Axel Davy wrote : Hi, On 08/02/2014, Jason Ekstrand wrote : For each surface with queued

Re: [RFC] libinput configuration interface

2014-02-08 Thread Peter Hutterer
On Thu, Feb 06, 2014 at 11:28:49PM +0100, Eugen Friedrich wrote: Hi together, i would like to put some input from the embedded/ automotive perspective. you can think about huge amount of different configurations for different device types. A lot of configuration in the initial post deals