On startup enumerate the available framebuffer devices using udev and
setup an output for each device, unless a specific device is passed with
--device in which case just create one for that device.
Signed-off-by: Sjoerd Simons
---
src/compositor-fbdev.c | 80
buffer really isn't needed, so drop
it.
As a side-effect this fixes updating the fbdev hardware for outputs not
starting at 0x0.
Signed-off-by: Sjoerd Simons
---
src/compositor-fbdev.c | 68 +++---
1 file changed, 3 insertions(+), 65 deletions(-)
This patchset add support for driving multiple framebuffers from weston. First
patch drops the intermediate shadow buffer in the fbdev compositor, which
turned out to be both unneeded and buggy with non-0x0 rooted outputs second
patch actually adds multiple output support.
Sjoerd Simons (2
On Tue, 2015-07-07 at 07:21 -0500, Derek Foreman wrote:
> On 06/07/15 03:31 AM, Sjoerd Simons wrote:
> > On startup enumerate the available framebuffer devices using udev
> > and
> > setup an output for each device, unless a specific device is passed
> > with
>
rt it ?
> XDG_RUNTIME_DIR is supposed to free us from other environment
> variables.
Indeed! Even recent dbus can use that these days for its user bus, seem
s rather a shame wayland would go a step backwards here...
> --Ray
> ___
> wayland
On Mon, 2015-08-17 at 16:17 +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d.
Acked-By: Sjoerd Simons
> Developers have been trying to reduce the number of by default
> required
> environment variables,
session one will have
e.g. DISPLAY=:0 the other DISPLAY=:1. Because of that defaulting to :0
on X isn't a great idea on multi-user systems.
However for wayland, the sockets are namespaced per user as they reside
in their respective XDG_RUNTIME_DIR, which means two people can star
When running gtk3-demo under weston opening comboboxes a second time
causes the program to bail due to weston returning an error. The
relevant client trace in this case is:
-> xdg_shell@15.get_xdg_popup(new id xdg_popup@12, wl_surface@28,
-> xdg_popup@12.destroy()
-> xdg_shell@15.get_xdg_po
On Wed, 2014-06-04 at 13:44 +0200, Sjoerd Simons wrote:
> When running gtk3-demo under weston opening comboboxes a second time
> causes the program to bail due to weston returning an error. The
> relevant client trace in this case is:
> -> xdg_shell@15.get_xdg_popup(new
.
Signed-off-by: Sjoerd Simons
---
clients/window.c | 6 --
libweston-desktop/xdg-shell-v6.c | 9 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 216ef96..31bf236 100644
--- a/clients/window.c
+++ b/clients/window.c
3.22.
Signed-off-by: Sjoerd Simons
Reviewed-by: Jonas Ådahl
---
clients/window.c | 7 +--
libweston-desktop/xdg-shell-v6.c | 9 +
2 files changed, 14 insertions(+), 2 deletions(-)
Changes since v1:
* Fix nitpicks by jadahl and add hits reviewed-by
diff --git a
Hey Jasper,
On Thu, 2014-07-17 at 17:57 -0400, Jasper St. Pierre wrote:
> We've gone through enough churn of xdg-shell that we're now feeling
> confident enough to commit to this much. Let's do it.
It would make me much more confident if the somewhat odd life-time rules
of xdg-shell were addresse
} associated with it but where it's also not possible
to re-created one.
This also happens to align the life-time rules of xdg_{surface,popup} to
match those of wl_shell_surface, which is probably good for consistency.
Signed-off-by: Sjoerd Simons
---
desktop-shell/shell.c
On Mon, 2014-07-21 at 10:03 -0700, Jason Ekstrand wrote:
> On Mon, Jul 21, 2014 at 1:47 AM, Sjoerd Simons <
> sjoerd.sim...@collabora.co.uk> wrote:
>
> > Remove the explicit destroy method from xdg_surface and xdg_popup as
> > neither of them can be re-created after be
mpositors (e.g. mutter) as that is likely to just lead to
incompatibilities. If you continue that line of reasoning, it's probably
best to not allow it simply such that the odd clients that do use re-use
don't hit barely tested codepaths on compositors.
--
Sjoerd Simons
Collabora Ltd.
sm
The reason for not having any input devices could actually be that there
are no input devices attached, imagine that. Mention that cause in the
warning and no longer return an error.
This fixes starting weston on boards with no input devices attached.
Signed-off-by: Sjoerd Simons
---
src
On Fri, 2015-01-02 at 13:34 +0200, Pekka Paalanen wrote:
> On Tue, 30 Dec 2014 17:19:45 +
> Daniel Stone wrote:
>
> > Hi,
> >
> > On 29 December 2014 at 00:03, Peter Hutterer
> > wrote:
> >
> > > On Sun, Dec 28, 2014 at 11:25:16PM +0100,
On Fri, 2015-01-02 at 13:07 +, Daniel Stone wrote:
> Hi,
>
> On 2 January 2015 at 12:24, Sjoerd Simons
> wrote:
>
> > Under the assumption that weston-launch is a tool for developers to
> > start weston, then sure fine. If weston-launch gets used to autostart
&
18 matches
Mail list logo
