On Wed, 13 May 2015 21:43:39 -0400
nerdopolis wrote:
> Resolving https://bugs.freedesktop.org/show_bug.cgi?id=73782
> udev might be configured to set the permissions on framebuffer devices with
> the UACCESS attribute.
> Weston currently attempts to reconnect to the framebuffer device before ude
On Wed, 13 May 2015 22:25:31 -0400
nerdopolis wrote:
> For some video cards, hardware rendered cursors fail to change properly.
>
> Add a variable that users can use for these cards when starting Weston.
>
> Also document in the man page
>
> This time with all the closing parenthesis, and the
On Thu, 14 May 2015 00:43:53 -0700
"R ." wrote:
> OK, so my test drive hasn't really been "fair", as I only tested Weston and
> not other Wayland implementations. But if you guys could suggest a less buggy
> and faster implementation, then please what is it? It'll save me the time,
> rather th
On Sun, Mar 29, 2015 at 02:20:23PM +0300, Giulio Camuffo wrote:
> When we get a focus in event from an X window which is not the one
> we last set as the active window, reset the focus.
> ---
> xwayland/window-manager.c | 44 +---
> 1 file changed, 33 insert
On Sun, May 10, 2015 at 12:14:40PM +0300, Giulio Camuffo wrote:
> Hi,
>
> This seems to work correctly after a brief test, and the code looks fine.
>
> Reviewed-By: Giulio Camuffo
Thanks, applied:
0c944b0..b0f5a25 master -> master
> 2015-05-04 5:56 GMT+03:00 Dima Ryazanov :
> > Enable al
On Mon, May 11, 2015 at 02:19:03PM -0500, Derek Foreman wrote:
> If the GL implementation doesn't provide an XRGB visual we may still be
> able to proceed with an ARGB one. Since we're not changing the scanout
> buffer format, and our current rendering loop always results in saturated
> alpha in th
On Mon, May 11, 2015 at 02:19:02PM -0500, Derek Foreman wrote:
> Currently we pass either a single format or no formats to the gl renderer
> create and output_create functions. We extend this to any number of
> formats so we can allow fallback formats if we don't get our first pick.
>
> Signed-of
On Thu, May 14, 2015 at 12:26:52PM -0700, Bill Spitzak wrote:
> On 05/13/2015 11:34 PM, Jonas Ådahl wrote:
>
> Okay, looking at the clickdot and resizor examples, it appears you are
> actually responding to events with pointer_lock. This is pretty much what I
> think makes sense but your notes wer
Hi.
I figured that it would make getting this fallback behavior easier to script,
or for a login manager to export the variable, for a 'fallback' session (along
with other variables, such as LIBGL_ALWAYS_SOFTWARE), or just to temporarily
enable the fallback behavior...
Thanks.
On Thursday, Ma
On Thu, May 14, 2015 at 09:36:17AM -0500, Derek Foreman wrote:
> On 13/05/15 09:25 PM, nerdopolis wrote:
> > For some video cards, hardware rendered cursors fail to change properly.
> >
> > Add a variable that users can use for these cards when starting Weston.
>
> Why an env var and not a weston
Hi.
I sent 4 attempts yesterday. The first one was for a fix for the Framebuffer.
That one I meant to review
The second one, I realized until too late that I was missing a closing ), so I
sent the third one.
The third one I reapplied the patch, and recommitted locally with the wrong
commit mes
On 27/03/15 07:29 AM, Bruno Prémont wrote:
> When weston fails to run while being launched by weston-launch it's
> socketpair causes poll() to notify POLLIN|POLLHUP and lets recvmsg()
> return 0.
>
> Properly cleanup and exit in that case instead of poll()ing in a tight
> loop and leaving tty in g
On 05/13/2015 11:34 PM, Jonas Ådahl wrote:
Okay, looking at the clickdot and resizor examples, it appears you are
actually responding to events with pointer_lock. This is pretty much
what I think makes sense but your notes were very misleading.
The primary problem is that you removed the seri
I think you sent the wrong patch here
On 05/13/2015 07:19 PM, nerdopolis wrote:
Resolving https://bugs.freedesktop.org/show_bug.cgi?id=73782
udev might be configured to set the permissions on framebuffer devices with the
UACCESS attribute.
Weston currently attempts to reconnect to the framebuff
On 14/05/15 05:04 AM, Marek Chalupa wrote:
> And also write out a warning when we got some event that
> we cannot handle.
>
> Signed-off-by: Marek Chalupa
> ---
> xwayland/window-manager.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/xwayland/window-manager.c b/
Actually, why not just move "xorg_list_append(&xwl_output->link,
&xwl_screen->output_list);" to xwl_output_create?
I can't tell if there's a reason it's in xwl_output_done, or if it's just
an oversight.
On Thu, May 14, 2015 at 9:37 AM, Dima Ryazanov wrote:
> Oh wow, I was playing around with ou
Oh wow, I was playing around with outputs, and never realized
output_handle_done
was being called after any geometry change, not just after the output was
created.
On Thu, May 14, 2015 at 2:58 AM, Marek Chalupa wrote:
> output.done event can be sent even on some property change, not only
> when
On 13/05/15 09:25 PM, nerdopolis wrote:
> For some video cards, hardware rendered cursors fail to change properly.
>
> Add a variable that users can use for these cards when starting Weston.
Why an env var and not a weston.ini option? I don't think this is a bad
idea, but I think it'd be better
And also write out a warning when we got some event that
we cannot handle.
Signed-off-by: Marek Chalupa
---
xwayland/window-manager.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 039f0cd..b1fd12d 100644
--- a
output.done event can be sent even on some property change, not only
when announcing the output. Therefore we must check if we already have it
otherwise we may corrupt the list by adding it multiple times.
This fixes bug when xwayland looped indefinitely in output.done handler
and that can be repr
On Thu, May 14, 2015 at 12:57 AM, Marek Chalupa wrote:
> On Tue, May 12, 2015 at 7:21 PM, Dima Ryazanov wrote:
>
>> The logic is pretty much copied from weston's clients/window.c.
>>
>> Signed-off-by: Dima Ryazanov
>> ---
>> hw/xwayland/xwayland.c | 25 -
>> hw/xwayland
> Date: Thu, 14 May 2015 00:59:44 -0700
> From: br...@osg.samsung.com
> To: ren_zokuke...@hotmail.com
> CC: wayland-devel@lists.freedesktop.org
> Subject: Re: Can speed of Wayland overtake the toll of emulating X?
>
> On Thu, May 14, 2015 at 12:43:53AM -0700, R . wrote:
> > OK, so my test drive
On Thu, May 14, 2015 at 12:43:53AM -0700, R . wrote:
> OK, so my test drive hasn't really been "fair", as I only tested Weston and
> not other Wayland implementations. But if you guys could suggest a less buggy
> and faster implementation, then please what is it? It'll save me the time,
> rather
On Tue, May 12, 2015 at 7:21 PM, Dima Ryazanov wrote:
> The logic is pretty much copied from weston's clients/window.c.
>
> Signed-off-by: Dima Ryazanov
> ---
> hw/xwayland/xwayland.c | 25 -
> hw/xwayland/xwayland.h | 8
> 2 files changed, 32 insertions(+), 1
OK, so my test drive hasn't really been "fair", as I only tested Weston and not
other Wayland implementations. But if you guys could suggest a less buggy and
faster implementation, then please what is it? It'll save me the time, rather
than trying each and every one.
From: ren_zokuke...@hotma
On Thu, Jan 22, 2015 at 05:40:29PM +0200, Giulio Camuffo wrote:
> When an output is destroyed reassign the output of the views that
> were in it, to be sure not to keep a dangling pointer which could
> be used later on by calling weston_surface_assign_output() on the
> view's surface.
Found this p
Checking for negative return value of snprintf is wrong, but snprintf can
actually "fail". It can truncate the output. However, since sizeof name is
256 and the length of "XWAYLAND%d" is always shorter that this, it is safe
here.
Reviewed-by: Marek Chalupa
On Tue, May 12, 2015 at 7:21 PM, Dima R
So I've been test driving Wayland and it has more lag than LXDE
(understandably), and, of course, will get better... But, I'm more concerned
with backwards compatibility (and speed) with old X clients (until, of course
they eventually, port to Wayland). Since XWayland is another layer, so wil
28 matches
Mail list logo
