# Call For Proposals
**2013 X.Org Developers Conference (XDC 2013)**
**23-25 September 2013**
**Portland, Oregon USA**
The [2013 X.Org Developers Conference]
(http://www.x.org/wiki/Events/XDC2013) is the annual
technical meeting for [X Window System](http://x.org) and
[Free Desktop](http://freede
Now that we have everything in place we can finally make it official
and announce it:
XDC2013 will take place from September 23th to September 25th in
Portland, Oregon at the University Place Hotel and Conference Center
Ian Romanick, Bart Massey, and I will be orgainzing this event.
The initial
Martin Minarik wrote:
The way to verify this:
1. press A on keyboard 1
2. press A on keyboard 2
3. release A on keyboard 1
4. release A on keyboard 2
The actual sequence:
[2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1)
[2134421.1337] -> wl_keyboard at 39.key(2316, 899782584,
sardemff7+wayl...@sardemff7.net wrote:
This is a requirement so that non-trivial clients can be written
that are not forced to blink the transient windows to change their
parenting.
Do you have a use case for this scenario ? There are probably some I
cannot see, but maybe could we solve them
Hi,
Can someone pls have a look at this patch?
I implemented configuration options for relativ output positioning in
weston.ini. Currently the implementation is private to the drm compositor,
but i think this can be generalized for all output drivers.
ATM it can only be configured in weston.ini,
Since evdev keys are unreliable, they might randomly get dropped, such
as, on SYN_DROPPED. Even SYN_DROPPED is sometimes not delivered.
Clients, compositor are not able to recover from duplicate press/release.
Multiple wl_keyboard attached devices are not distinguished properly.
This fixes this bug
On Tue, Jun 11, 2013 at 03:33:46PM +0300, Pekka Paalanen wrote:
> Hi Rob,
>
> I think patches 2, 3, and 4 should be all squashed, and I would like to
> know more of what is the use case here.
>
> More questions below.
>
>
> On Mon, 10 Jun 2013 15:17:30 +0100
> Rob Bradford wrote:
>
> > From:
Hi,
On 13.06.2013 16:06, John Kåre Alsaker wrote:
> On Thu, Jun 13, 2013 at 2:42 PM, Pekka Paalanen wrote:
>> Libwayland does not synchronize, it only protects the queues for the
>> very short moment each time they are modified. It does not cause one
>> application component to stall and wait for
On Thu, Jun 13, 2013 at 2:42 PM, Pekka Paalanen wrote:
> Libwayland does not synchronize, it only protects the queues for the
> very short moment each time they are modified. It does not cause one
> application component to stall and wait for another component to wake
> up, realize there is somet
On Thu, 13 Jun 2013 14:03:26 +0200
John Kåre Alsaker wrote:
> On Thu, Jun 13, 2013 at 1:04 PM, Pekka Paalanen
> wrote:
>
> > On Thu, 13 Jun 2013 12:35:36 +0200
> > John Kåre Alsaker wrote:
> >
> > > I propose the we should change the commit behavior to having
> > > commit on the toplevel wl_su
On Thu, Jun 13, 2013 at 1:04 PM, Pekka Paalanen wrote:
> On Thu, 13 Jun 2013 12:35:36 +0200
> John Kåre Alsaker wrote:
>
> > I propose the we should change the commit behavior to having commit
> > on the toplevel wl_surface
> > commit itself and all it's subsurfaces atomically. Commiting on
> >
On Thu, 13 Jun 2013 12:35:36 +0200
John Kåre Alsaker wrote:
> I propose the we should change the commit behavior to having commit
> on the toplevel wl_surface
> commit itself and all it's subsurfaces atomically. Commiting on
> subsurfaces should be a no-op.
When a component is running asynchrono
I propose the we should change the commit behavior to having commit on the
toplevel wl_surface
commit itself and all it's subsurfaces atomically. Commiting on subsurfaces
should be a no-op.
That is to allow eglSwapBuffers to be used in subsurfaces, should you
manage to get it to be non-blocking.
Th
On Wed, 12 Jun 2013 12:54:57 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > I guess the question for the Wayland developer community is, do we
> > want such cursor theme settings in the shell protocol, or is that
> > something that should be left for DEs to solve in their own
> > config
On Wed, 12 Jun 2013 18:31:17 -0700
Bill Spitzak wrote:
> Rafael Antognolli wrote:
>
> >> Rafael Antognolli
> >
> > I've just updated the proposal, considering my last statement. Take
> > a look at it and see if it fits your suggestion.
> >
> > This lets us with 2 surface types (toplevel and fu
Free plane resources using drmModeFreePlaneResources()
Signed-off-by: Samuel Iglesias Gonsalvez
---
src/compositor-drm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 76d0810..8787723 100644
--- a/src/compositor-drm.c
+
On 12/06/2013 21:39, Bill Spitzak wrote:
Shell surface types, exclusive: - top-level - transient (umm,
what was this for, again?) - popup (menu?)
Transcient is for dialog (modal?) boxes, isn’t it?
It means "this window stays above another one".
Transient cannot be a type, but instead a sta
17 matches
Mail list logo
