Gregory Merchan wrote:
Viewport change as described by Bill:
W to A: Request activation.
A to W: Activate me and do these things, or don't activate me at all.
W to Z: (1) You are deactivated; (2) Nothing.
W to A: (1) You are activated (and by other events or by implication
everything is done.);
Gregory Merchan wrote:
>> re: glitches in pagers due to incorrect guessing of activated
surface by comnpositor
I think the API for marking surfaces transient or otherwise secondary
will obviate some potential glitches. For example, I think most
thumbnailing window switchers I've seen just i
On Tue, Nov 5, 2013 at 4:31 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>>> - The compositor can send a "activate request event" saying that it would
>>> like the client to activate.
>>
>>
>> That is not what I described, mostly because I kept the new things to
>> a minimum. It seems I hint
On Tue, Nov 5, 2013 at 1:47 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>> As before, I'm just laying it all out there. Brief summary:
>>
>> 1. All window management policies set focus without exception in
>> certain cases. (E.g. Alt+Tab, viewport changes.)
>
>
> No. All the compositor can
Gregory Merchan wrote:
- The compositor can send a "activate request event" saying that it would
like the client to activate.
That is not what I described, mostly because I kept the new things to
a minimum. It seems I hinted at but failed to explicitly mention what
serves much the same purpose
On Tue, Nov 5, 2013 at 12:36 PM, Bill Spitzak wrote:
> Gregory Merchan wrote:
>
>>> No the client must be in control and decide it does *not* want to be
>>> activated.
>>
>>
>> "Sloppy focus, as a system-wide policy" refers to the list of 5
>> policies which I gave in my first message in this thre
Gregory Merchan wrote:
As before, I'm just laying it all out there. Brief summary:
1. All window management policies set focus without exception in
certain cases. (E.g. Alt+Tab, viewport changes.)
No. All the compositor can do is send a focus-request-event to the
client. The client is allowe
Gregory Merchan wrote:
No the client must be in control and decide it does *not* want to be
activated.
"Sloppy focus, as a system-wide policy" refers to the list of 5
policies which I gave in my first message in this thread. That is a
policy which does not allow clients such control. (Did I me
Add gbm_bo_map() and gbm_bo_unmap(). This lets a user access the
contents of a bo using the CPU.
---
I'm not sure about the extra flags. We do have GBM_BO_USE_WRITE but
that is defined to always work with GBM_BO_USE_CURSOR_64X64. Reusing
that would imply that these buffers are always mappable or
This adds an intel backend that doesn't depend on dri. Its usage is
limited since the current EGL implementation won't work with this as
it is.
---
src/gbm/Makefile.am| 12 ++
src/gbm/backends/intel/gbm_intel.c | 227
src/gbm/backends/intel/g
This adds a GBM platform that doesn't depend on gbm's dri backend. This
can be used, for instance, with the intel backend.
This also adds a gbm_bo_export entrypoint to gbm, so that the EGL code
can access the buffer. This is necessary since EGL won't share the fd
width gbm when using the new platf
Hi,
This is a request for comments on the idea of being able to map gbm
bos and how to implement it. The idea here is to take advantage of
UMA atchitectures when the contents on the screen are a mix of GPU
and CPU rendered.
One of the problems of adding a map entry point to gbm is the fact
that i
On 11/04/2013 10:39 AM, Cameron Stewart wrote:
Otherwise the outputs are removed when they have already
been freed. However don't clean up the debug listeners in gl_renderer
as these would be cleaned up by the compositor previously.
I'm not sure why I didn't notice the error when I wrote the pa
On Mon, 4 Nov 2013 18:21:27 +0200
Pekka Paalanen wrote:
> Hi Axel,
>
> I agree with the clock comments, in that we need to know which clock to
> use, and 32 bits may be too short. If we follow struct timespec,
> uint32_t seconds + uint32_t nanoseconds should be fine. We don't have
> 64-bit integ
It's nice to keep helper sources separately from tests sources.
It's better for searching files as well as for extending
the test-suite.
Also, there were no need to compile each test with test-*.c files
so I used them to create noinst library and link the tests against it.
Now we don't need to att
15 matches
Mail list logo
