Actually, there is a value in clients that need 2 shells at the same time.
Think about an SDK or a development environment for a phone OS. The
development environment would work in a desktop shell because it is more
convenient for developers to write code in an IDE on a desktop/laptop. At
the same
---
src/launcher-util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/launcher-util.c b/src/launcher-util.c
index b4b82f1..9196e4f 100644
--- a/src/launcher-util.c
+++ b/src/launcher-util.c
@@ -96,7 +96,7 @@ weston_launcher_open(struct weston_compositor *compositor,
On Tue, Feb 12, 2013 at 06:38:27PM +0100, Rafal Mielniczuk wrote:
> In fullscreen mode we need to adjust output dimensions to match x11
> window size. In other case, if there is no output section in weston.ini,
> weston output will have default 1024x640 size, while rest of the screen
> remains blac
On Tue, 12 Feb 2013 09:13:16 -0600
Jason Ekstrand wrote:
> On Tue, Feb 12, 2013 at 2:52 AM, Pekka Paalanen wrote:
> > On Tue, 12 Feb 2013 08:51:26 +0100
> > Kai-Uwe Behrmann wrote:
> >
> >> On 11.02.2013 11:06, Pekka Paalanen wrote:
> >> > I want to make sure again, that when we talk about shel
On 12 February 2013 15:52, Ander Conselvan de Oliveira
wrote:
> Input device initialization takes several microseconds to complete. Two
> things causes this: compiling the XKB keymap and reading the properties
> database from the udev daemon. The user can't really interact with
> anything on the s
In fullscreen mode we need to adjust output dimensions to match x11
window size. In other case, if there is no output section in weston.ini,
weston output will have default 1024x640 size, while rest of the screen
remains black and unusable.
This should fix
https://bugs.freedesktop.org/show_bug.cgi
Tested-by: Joe Konno
On 02/12/2013 03:53 AM, Rob Bradford wrote:
> From: Rob Bradford
>
> If our surface has width and height set to the same dimensions as the output
> then we can bypassing the scale factor calculation and addition of the
> transformation.
>
> The use case that led to this opti
Input device initialization takes several microseconds to complete. Two
things causes this: compiling the XKB keymap and reading the properties
database from the udev daemon. The user can't really interact with
anything on the screen until something is displayed, so this can be
delayed.
On my syst
This patch adds a signal to the compositor that is fired after the
first frame is displayed. The intent of this signal is to let non
critical initialization to be done after something is displayed.
---
src/compositor.c | 22 +++---
src/compositor.h |3 +++
2 files changed, 22
On Tue, Feb 12, 2013 at 2:52 AM, Pekka Paalanen wrote:
> On Tue, 12 Feb 2013 08:51:26 +0100
> Kai-Uwe Behrmann wrote:
>
>> On 11.02.2013 11:06, Pekka Paalanen wrote:
>> > I want to make sure again, that when we talk about shells in Wayland,
>> > we usually talk about public shell interfaces in th
From: Rob Bradford
If our surface has width and height set to the same dimensions as the output
then we can bypassing the scale factor calculation and addition of the
transformation.
The use case that led to this optimisation is the playback of video using
gstreamer-vaapi with the "scale" method
On Tue, 12 Feb 2013 08:51:26 +0100
Kai-Uwe Behrmann wrote:
> On 11.02.2013 11:06, Pekka Paalanen wrote:
> > I want to make sure again, that when we talk about shells in Wayland,
> > we usually talk about public shell interfaces in the protocol. Therefore
> > all of Linux desktop, regardless of DE
12 matches
Mail list logo
