2013/4/16 Kristian Høgsberg :
I know the current behavior is a bit problematic for some use cases.
However it works well for the case where you load a plugin in addition
to the shell, like xwayland. I'm not sure what the best way to make
both cases work is, except to make the shell plugin spec
Todd Showalter wrote:
On Fri, Apr 19, 2013 at 1:52 PM, Jonas Kulla wrote:
I'm stuck on a Mac at the moment, unfortunately, so I can't give
you verified Linux examples, but I'm writing this email in the GMail
web client on Firefox. If I grab the scroll thumb and drag it
upwards, the mouse
Hi
On Fri, Apr 19, 2013 at 5:02 PM, Richard Hughes wrote:
> At the moment we're only extracting interesting strings. We have to be quite
> careful parsing the EDID data, as vendors like to do insane things.
>
> The original EDID parsing code was written by me for gnome-color-manager.
> ---
> src
Am 19.04.2013 21:12, schrieb David Herrmann:
Why do you keep the blob around all the time? Just free it in
create_output_for_connector() after you parsed it. If we somehow need
it later, we can always change it again. But your patches don't depend
on it being around all the time so lets just fre
2013/4/16 Kristian Høgsberg :
> On Sun, Apr 14, 2013 at 07:17:40PM +0200, Pier Luigi Fiorini wrote:
>> Let --modules override modules list and load desktop-shell.so as a
>> fallback if a modules list is not specified neither by passing
>> --modules nor with weston.ini.
>>
>> Signed-off-by: Pier Lui
Hi
On Fri, Apr 19, 2013 at 5:02 PM, Richard Hughes wrote:
> ---
> src/compositor-drm.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index da1ba79..61ef97e 100644
> --- a/src/compositor-drm.c
> +++ b/src/composi
On Fri, Apr 19, 2013 at 2:55 PM, Todd Showalter wrote:
> I suppose you could also handle this with pointer sensitivity
> modification; if you know the document:view ratio is 10:1, you could
> scale the pointer speed by 0.1 when the scroll wheel was grabbed while
> not allowing warping.
s
On Fri, Apr 19, 2013 at 1:52 PM, Jonas Kulla wrote:
> I can totally see where you're coming from (having worked on a small
> engine myself in the past), but I feel like creating static input states
> should always be done on client side. Especially in Wayland where
> "frame-perfectness" is crucia
2013/4/19 Todd Showalter
> On Fri, Apr 19, 2013 at 5:18 AM, Pekka Paalanen
> wrote:
>
> > Event driven is a little more work for the "simple" games, but it gives
> > you guarantees. Would you not agree?
>
> We can definitely work with it. As much as anything it's a
> question of convenienc
wl_egl_window_destory() distroys the window handle that
dri2_destroy_surface() later uses when eglTerminate() is called.
Reordering the tear down order prevents such case from occuring.
---
clients/simple-egl.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/cli
> If this is the case (two different output, two different seats), then
> why not have two different compositors? Perhaps you need some
> syncing between them? Is there something else I'm missing here?
>
> I don't know for sure, but It should be possible (perhaps with a
> little modification) to
On Fri, Apr 19, 2013 at 5:18 AM, Pekka Paalanen wrote:
> I am going to reply from the Wayland protocol point of view, and what
> Wayland explicitly can (and must) do for you. This is likely much lower
> level than what a game programmer would like to use. How SDL or some
> other higher level libr
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 166 +++
---
src/compositor-drm.c | 1 +
src/compositor.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 61ef97e..a454676 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1522,6 +1522,7 @@ create_output_for_connect
---
src/compositor-drm.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..61ef97e 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -139,6 +139,7 @@ struct drm_output {
int pipe;
At the moment weston doesn't know anything about EDID blobs. To make
the CMS functionality complete we have to tell the CM the display
attributes, e.g. make, model and serial. This allows us to show
something nice in the calibration UI, and also allows us to match a
specific _display_ to the color
At the moment weston doesn't know anything about EDID blobs. To make
the CMS functionality complete we have to tell the CM the display
attributes, e.g. make, model and serial. This allows us to show
something nice in the calibration UI, and also allows us to match a
specific _display_ to the color
Hi Todd,
I am going to reply from the Wayland protocol point of view, and what
Wayland explicitly can (and must) do for you. This is likely much lower
level than what a game programmer would like to use. How SDL or some
other higher level library exposes input is a different matter, and I
will not
On Fri, 19 Apr 2013 01:43:52 +0100
João Jerónimo wrote:
> Hello.
>
> I was trying to understand what is the minimal code needed to get a
> square painter on the screen. However, although I can make the client
> talk to the Weston compositor, enumerate the global objects, etc, I
> can't still
19 matches
Mail list logo
