From: Rob Bradford
If gbm_bo_import does not return a valid buffer for usage of
GBM_BO_USE_SCANOUT don't try and scan out the surface directly.
We've caught the SHM case explicitly earlier - this is to prevent other cases
where the bo cannot be scanned out.
Signed-off-by: Rob Bradford
---
src
On Fri, 14 Sep 2012 23:08:55 +0100, Rob Bradford wrote:
> From: Rob Bradford
>
> gbm_bo_import will fail to produce a valid bo since the buffer is an SHM
> buffer. This cause a crash when the NULL bo returned by gbm_bo_import is
> dereferenced later.
So since gbm_bo_import() is already verifyin
From: Rob Bradford
gbm_bo_import will fail to produce a valid bo since the buffer is an SHM
buffer. This cause a crash when the NULL bo returned by gbm_bo_import is
dereferenced later.
Signed-off-by: Rob Bradford
---
src/compositor-drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/s
William Swanson wrote:
On Fri, Sep 14, 2012 at 12:01 PM, Bill Spitzak wrote:
Both Linux and windows support text files that say something like this (we
wrote the code that reads/writes these files):
window_position: 10,30,400,500
Your example is already deeply broken, since it doesn't co
On Fri, Sep 14, 2012 at 12:01 PM, Bill Spitzak wrote:
> Both Linux and windows support text files that say something like this (we
> wrote the code that reads/writes these files):
>
> window_position: 10,30,400,500
Your example is already deeply broken, since it doesn't consider
things like the
I would like to share with you a couple of demos of the 3D virtual reality
desktop, courtesy of Hesham Wahba. I believe it will give you a better idea
of what Pekka was talking about:
Demo 1 shows the side-by-side view for left and right eyes. It also shows
orientation control by a gyroscope in iP
Pekka Paalanen wrote:
What is going to happen is Wayland clients are going to use the X api
just to get this information.
No, that is impossible.
I do believe it will be impossible to use the Wayland API and be able to
set window x/y positions by somehow messing with the X api. My worry is
On Mon, Sep 10, 2012 at 03:55:53PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> Since commit 6a615d262141de7cf094788203d9c044dfb9f08d [1], the opaque
> region would be set only when running fullscreen. Having it set
> properly for the windowed case is helpful
On Fri, Sep 14, 2012 at 04:12:04PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> Also make all the callers of weston_surface_assign_output() update the
> transform instead. This makes sure that when the surface is assigned an
> output its bouding box is valid.
On Fri, Sep 14, 2012 at 04:12:03PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> This is a more generic fix for the issue solved in 4f521731 where
> damage obscured by overlays could be lost in one of the output buffers
> due to rapid move of a surface in an ov
From: Rob Bradford
This simple change allows you to drive the editor using the keyboard
(supporting backspace and delete and left and right arrow keys.) The idea
behind this change is to allow the testing of the interoperation between a
virtual keyboard and real one.
Signed-off-by: Rob Bradford
Sorry about the delay.
I flew 8 legs in 4 days this week.
Here are the mains for both the glut and Wayland instance of my test
application.
uMfdInit, uMfdDraw, and c->controller->event() are the interface
functions, solely used by both implementations.
The code under the hood is IDENTICAL. (with
On sexta-feira, 14 de setembro de 2012 10.07.38, dar...@chaosreigns.com wrote:
> On 09/14, Pekka Paalanen wrote:
> > Apparently you have forgot all about, say, dome projectors or virtual
> > displays, where the output is a half sphere. Good luck mapping Cartesian
> > global coordinates there in any
On 09/14, Pekka Paalanen wrote:
> Apparently you have forgot all about, say, dome projectors or virtual
> displays, where the output is a half sphere. Good luck mapping Cartesian
> global coordinates there in any meaningful way.
What coordinate system does that use, if not cartesian?
--
"Forget
From: Ander Conselvan de Oliveira
Also make all the callers of weston_surface_assign_output() update the
transform instead. This makes sure that when the surface is assigned an
output its bouding box is valid.
This fixes a bug where a newly created surface would have a NULL output
assigned. This
From: Ander Conselvan de Oliveira
This is a more generic fix for the issue solved in 4f521731 where
damage obscured by overlays could be lost in one of the output buffers
due to rapid move of a surface in an overlay plane.
This changes the renderer so it keeps track of the damage in each
buffer.
Hey Bill,
I think this solution is okey. I'm not committing the patches myself to
Xwayland X server repository, so let's see what Kristian has to say now.
Thanks for checking it BTW!
Tiago
On 09/12/2012 10:34 PM, Bill Spitzak wrote:
Any comments on this patch?
Is there another way to get
On Fri, 14 Sep 2012 10:36:53 +0200
Andreas Ericsson wrote:
> On 09/14/2012 08:40 AM, Pekka Paalanen wrote:
> > On Thu, 13 Sep 2012 11:27:50 -0700
> > Bill Spitzak wrote:
> >
> >> My recommendation is to give up on useless "purity" and make Wayland
> >> clients be able to get and set the exact x
On 09/14/2012 08:40 AM, Pekka Paalanen wrote:
> On Thu, 13 Sep 2012 11:27:50 -0700
> Bill Spitzak wrote:
>
>> Tiago Vignatti wrote:
>>
>>> It features ... forwarding global coordinates to X
>>
>> I don't like the idea that X clients are "privileged" to get this
>> information, while real Wayland
On Tue, 11 Sep 2012 17:02:05 +0300
Pekka Paalanen wrote:
> The existing algorithm had some corner cases (pun!), where it failed to
> produce correct vertices in the right order. This appeared only when the
> surface was transformed (rotated). It also produced degenerate polygons
> (3 or more vert
20 matches
Mail list logo