On 20/09/2013 5:09 AM, "Bill Spitzak" wrote:
>
>
>
> Sam Spilsbury wrote:
>>
>>
>> The point is to any arbitrary geometry against a rectangle. This is used
to ensure that redraw areas only stick to damage areas.
>>
> I suspect the most efficient thing to do is to clip against the bounding
box of t
Having now understood what a "view" is, I don't think there should be a
"primary view". This is because it looks like there can be zero views
for a surface (ie if it is clipped by all the outputs or the compositor
otherwise decides to hide it). So there will be instances when you
cannot retriev
Sam Spilsbury wrote:
The point is to any arbitrary geometry against a rectangle. This is
used to ensure that redraw areas only stick to damage areas.
I suspect the most efficient thing to do is to clip against the bounding
box of the obscuring object, even if that produces excess redraw, d
I did not see that they were not visible to the client. This makes sense
then.
I would guess that the compositor would turn surfaces+buffers into
views+buffers, and the final compositing step would not interact with
the surface objects at all.
Jason Ekstrand wrote:
Bill,
Sorry for not respo
** I don't expect this patch to be landed but it might be useful if
anyone wants to test the multi-resource stuff **
This adds a hacked version of simple-shm which can create multiple
pointer and keyboard resources. The resources are created with the
command line options -p and -k. Both take an
Here is a second version of Robert's patch with the following changes:
I think the problem where clients would not immediately become active
when starting was caused by it calling weston_*_set_focus instead of
sending the enter event for the first keyboard or pointer resource.
The set_focus functi
On Wed, Sep 18, 2013 at 10:49 PM, Bill Spitzak wrote:
>
>
> Sam Spilsbury wrote:
>
>> Hey all,
>>
>> I've started playing around with trying to get weston surfaces (or
>> views as they will later be called) to use arbitrary vertex meshes.
>>
>>
> Do you have an explanation for "views"? I thought
On Sat, Sep 14, 2013 at 5:26 PM, Bill Spitzak wrote:
> Can't buffers already be shared between surfaces? I don't understand what
> problem or solution views are trying to address.
>
Sorry about the delay. I just responded to your previous e-mail.
--Jason Ekstrand
___
Bill,
Sorry for not responding sooner. It kind of got lost in the pile.
On Sat, Sep 14, 2013 at 5:26 PM, Bill Spitzak wrote:
> Can't buffers already be shared between surfaces? I don't understand what
> problem or solution views are trying to address.
>
Yes, they can. However, views have not
The scanner is not very forgiving if the protocol doesn't match it's
expectations and crashes without much of a notice. Thus, validate the protocol
against a DTD.
Move the protocol subdir forward so we validate first before trying anything
else, and install the DTD so we can validate weston's prot
On Thu, 19 Sep 2013 13:54:34 +1000
Peter Hutterer wrote:
> Instead of NULL, a client that doesn't implement all callbacks of a listener
> can use named defines to increase readability of the code. For example:
>
> const struct wl_pointer_listener pointer_listener = {
> WL_POINTER_ENTER_HAN
How does this work if the primary output frequency is more than the
clone output?
I'm afraid the weston log might become very big after a while when
running a such a configuration
Axel Davy
Le 18/09/2013 05:50, Xiong Zhang a écrit :
Only repsone to primary output repaint request; Primary out
12 matches
Mail list logo
