Sometimes, Xwayland will try to use a cursor that has just been freed,
leading to a crash when trying to access that cursor data either in
miPointerUpdateSprite() or AnimCurTimerNotify().
CheckMotion() updates the pointer's cursor based on which xwindow
XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
to fake a crossing to the root window when the pointer has left the
Wayland surface but is still within the xwindow.
But after an xwindow is unrealized, the last xwindow used to match the
xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
not return the same xwindow.
To avoid this issue, update the last_xwindow based on enter and leave
notifications instead of xwl_xy_to_window(), and check if the xwindow
found by the regular miXYToWindow() is a child of the known last
xwindow, so that multiple consecutive calls to xwl_xy_to_window()
return the same xwindow, being either the one found by miXYToWindow()
or the root window.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Vít Ondruch <vondruch@redhat.com>
Tested-by: Satish Balay <balay@fastmail.fm>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Commits 816015648f and
fee0827a9a made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.
wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.
This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.
On ProcessDeviceEvent() we still need to deactivate X grabs if needed
for KeyReleases.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The definition by the manual is:
calloc(size_t nmemb, size_t size)
Swap the arguments of calloc() calls to be the right way around.
Presumably this makes no functional difference, but better follow the
spec.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not needed anymore now that mipointer exposes an API for that,
miPointerInvalidateSprite()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().
The (simplified) backtrace goes as follow:
(gdb) bt
#0 GetTouchEvents() at getevents.c:1892
#1 QueueTouchEvents() at getevents.c:1866
#2 xwl_touch_send_event() at xwayland-input.c:652
#5 wl_closure_invoke() from libwayland-client.so.0
#6 dispatch_event() from libwayland-client.so.0
#7 wl_display_dispatch_queue_pending() from libwayland-client.so.0
#8 xwl_read_events() at xwayland.c:483
#9 ospoll_wait() at ospoll.c:412
#10 WaitForSomething() at WaitFor.c:222
#11 Dispatch() at dispatch.c:412
#12 dix_main() at main.c:287
#13 __libc_start_main() at libc-start.c:289
#14 _start ()
The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.
Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.
Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Pointer enter event coordinates are surface relative and we need them to
be screen relative for pScreen->SetCursorPosition().
https://bugzilla.gnome.org/show_bug.cgi?id=758283
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Emulate pointer warps by locking the pointer and sending relative
motion events instead of absolute. X will keep track of the "fake"
pointer cursor position given the relative motion events, and the
client warping the cursor will warp the faked cursor position.
Various requirements need to be met for the pointer warp emulator to
enable:
The cursor must be invisible: since it would not be acceptable that a
fake cursor position would be different from the visual representation
of the cursor, emulation can only be done when there is no visual
representation done by the Wayland compositor. Thus, for the emulator
to enable, the cursor must be hidden, and would the cursor be displayed
while the emulator is active, the emulator would be destroyed.
The window that is warped within must be likely to have pointer focus.
For example, warping outside of the window region will be ignored.
The pointer warp emulator will disable itself once the fake cursor
position leaves the window region, or the cursor is made visible.
This makes various games depending on pointer warping (such as 3D
first-person shooters and stategy games using click-to-drag-map like
things) work.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Translate grabbing a pointer device with confineTo set to a window into
confining the Wayland pointer using the pointer constraints protocol.
This makes clients that depend on the pointer not going outside of the
window region, such as certain games and virtual machines viewers, to
function more properly.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If there was an relative pointer motion within the same frame as an
absolute pointer motion, provide both the absolute coordinate and the
unaccelerated delta when setting the valuator mask.
If a frame contained only a relative motion, queue an absolute motion
with an unchanged position, but still pass the unaccelerated motion
event.
If the wl_seat advertised by the compositor is not new enough, assume
each relative and absolute pointer motion arrives within their own
separate frames.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Wait until wl_pointer.frame with dispatching the pointer motion event,
if wl_pointer.frame is supported by the compositor. This will later be
used to combine unaccelerated motion deltas with the absolute motion
delta.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Generating relative and absolute movement events from the same input
device is problematic, because an absolute pointer device doesn't
expect to see any relative motion events. To be able to generate
relative pointer motion events including unaccelerated deltas, create a
secondary pointer device 'xwayland-relative-pointer', and use that for
emitting relative motion events.
Signed-off-by: Krzysztof Sobiecki <sobkas@gmail.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Put device class initialization in init_[device_class](xwl_seat) and
releasing in release_[device class](xwl_seat). The purpose is to make
it easier to add more type of initialization here later, without making
the function too large.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Will be used for getting unaccelerated motion events and later for
relative motions used by a pointer warp emulator.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The way we map the touch absolute device to screen coordinates can't
work across wl_output mode and geometry events. Instead, set up
a fixed coordinate space, and transform touch events according to
the screen coordinate space as they happen.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
The checks in xwayland's XYToWindow handler pretty much assumes that the
sprite is managed by the wl_pointer, which is not entirely right, given
1) The Virtual Core Pointer may be controlled from other interfaces, and
2) there may be other SpriteRecs than the VCP's.
This makes XYToWindow calls return a sprite trace with just the root
window if any of those two assumptions are broken, eg. on touch events.
So turn the check upside down, first assume that the default XYToWindow
proc behavior is right, and later cut down the spriteTrace if the
current device happens to be the pointer and is out of focus. We work
our way to the device's lastSlave here so as not to break assumption #1
above.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Since xwayland's initial commit we have had a check to not process
wayland modifier events while one of our surfaces has keyboard focus
since the normal xkb event processing keeps our internal modifier
state up to date and if we use the modifiers we get from the
compositor we mess up that state.
This was slightly changed in commit
10e9116b3f to allow the xkb group to be
set from the wayland event while we have focus in case the compositor
triggers a group switch.
There's a better solution to the original problem though. Processing
queued events before overriding the xkb state with the compositor's
allows those events to be sent properly modified to X clients while
any further events will be modified with the wayland modifiers as
intended.
This allows us to fully take in the wayland modifiers, including
depressed ones, which fixes an issue where we wouldn't be aware of
already pressed modifiers on enter.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Emitting a LeaveNotify event every time the pointer leaves an X11 window
may confuse focus follow mouse mode in window managers such as
mutter/gnome-shell.
Keep the previously found X window and compare against the new one, and
if they match then it means the pointer has left an Xwayland window for
a native Wayland surface, only in this case fake the crossing to the
root window.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This partially reverts commit c1565f3.
When the pointer moves from an X11 window to a Wayland native window,
no LeaveNotify event is emitted which can lead to various unexpected
behaviors like tooltips remaining visible after the pointer has left the
window.
Yet the pointer_handle_leave() is called and so is the DIX CheckMotion()
but since the pointer enters a Wayland native window with no other
Xwayland window matching, DoEnterLeaveEvents() does not get invoked and
therefore no LeaveNotify event is sent to the X11 client at the time the
pointer leaves the window for a Wayland native surface.
Restore the XYToWindow() handler in xwayland-input that was previously
removed with commit c1565f3 and use that handler to pretend that the
pointer entered the root window in this case so that the LeaveNotify
event is emitted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96437
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The call to 'InitButtonClassDeviceStruct' which initializes the pointer
buttons only results in the first three buttons being created due to a
hardcoded '3'. In order to expose all the buttons defined in the
btn_labels array, we subtitute 'NBUTTONS' in its place.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Substitute a few errant tab characters with eight spaces to conform to the
prevailing style.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This partially revert commit 984be78
The rountrip in Xwayland's InitInput() is unlikely the culprit for the
crash reported in bug 95337, even though it's triggered from
InitInput().
Startup goes like this:
xwl_screen_init()
xwl_output_create()
wl_display_roundtrip()
InitInput()
wl_display_roundtrip()
ConnectionInfo initialized
What happens in bug 95337 is that some output data is already available
when we reach InitInput()'s wl_display_roundtrip() and therefore we end
up trying to update the ConnectionInfo's data from RR routines before
ConnectionInfo is actually initialized.
Removing the wl_display_roundtrip() from InitInput() will not fix the
issue (although it would make it less lileky to happen), because
xwl_screen_init() also does a wl_display_roundtrip() after creating the
output, so the race that led to bug 95337 remains.
However, re-setting the xwl_screen->expecting_event to 0 again in
InitInput() still doesn't seem right. so this part is not restored
(thus a partial revert).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Read and dispatch pending Wayland events to make sure we do not miss a
possible reply from the compositor prior to discard a key repeat.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Key repeat is handled by the X server, but input events need to be
processed and forwarded by the Wayland compositor first.
Make sure the Wayland compositor is actually processing events, to
avoid repeating keys in Xwayland while the Wayland compositor cannot
deal with input events for whatever reason, thus not dispatching key
release events, leading to repeated keys while the user has already
released the key.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762618
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This creates a function that invalidates the current sprite and forces
a sprite image reload the next time the sprite is checked, moving that
logic out of the xwayland sources and allowing the miPointerRec
structure to be removed from the server API.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If data is received during XWayland startup, it will be read early in
InitInput() before the connection data is initialized, causing a crash.
Remove the wayland rountrips from InitInput() as this is done again in
xwl_screen_init() where it seems more appropriate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
The last cursor frame we commited before the pointer left one of our
surfaces might not have been shown. In that case we'll have a cursor
surface frame callback pending which we need to clear so that we can
continue submitting new cursor frames.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
In Wayland, a client (in this case XWayland) should set the cursor
surface when it receives pointer focus. Not doing this will leave the
curser at whatever it was previously.
When running on XWayland, the X server will not be the entity that
controls what actual pointer cursor is displayed, and it wont be notified
about the pointer cursor changes done by the Wayland compositor. This
causes X11 clients running via XWayland to end up with incorrect pointer
cursors because the X server believes that, if the cursor was previously
set to the cursor C, if we receive Wayland pointer focus over window W
which also has the pointer cursor C, we do not need to update it. This
will cause us to end up with the wrong cursor if cursor C was not the
same one that was already set by the Wayland compositor.
This patch works around this by, when receiving pointer focus, getting
the private mipointer struct changing the "current sprite" pointer to
an invalid cursor in order to trigger the update path next time a cursor
is displayed by dix.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
wl_keyboard::enter is the equivalent of FocusIn + KeymapNotify: it
notifies us that the surface/window has now received the focus, and
provides us a set of keys which are currently down.
We should use these keys to update the current state, but not to send
any events to clients.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While we have keyboard focus, the server's xkb code is already locking
and latching modifiers appropriately while processing keyboard
events.
Since there is no guaranteed order between wl_keyboard key and
modifiers events, if we got the modifiers event with a locked or
latched modifier and then process the key press event for that
modifier we would wrongly unlock/unlatch. To prevent this, we ignore
locked and latched modifiers while any of our surfaces has keyboard
focus.
But we always need to set the xkb group index since this might be
triggered programatically by the wayland compositor at any time.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Commit 2172714c changed behavior of capability handling, but it only
solved part of the problem. If Xwayland is launched without a capability
(e.g. no pointer device is connected when Xwayland was spinned up), and
later that capability comes, the device added will not be automatically
initialized. This patch initializes the device when the capability is
reported for the first time, thus avoiding the problem.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=81819
Signed-off-by: Boyan Ding <stu_dby@126.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When grabbed, the slave device is floating, i.e. the master device is NULL.
CheckMotion() isn't happy with NULL. Make sure we pass the right device in,
either the master device when the device is attached, or the device itself
when it is floating.
Reported-by: Jason Gerecke <killertofu@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
A DeviceIntPtr with touch valuators is also created in order to deliver
the translated touch events. The lifetime of xwl_touch structs is tied
to the wayland ones, finishing in either wl_touch.up() or wl_touch.cancel()
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This struct holds information about each individual, ongoing touchpoint.
A list of these is held by the xwl_seat.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
This was built as a hack for simple Wayland compositors like Weston
which were lazy and didn't want to configure windows server-side when
moved.
Since comboboxes and menus are separate toplevel O-R windows, this hack
breaks input as it needs to be traced normally, not simply sent to the
focused window.
X11 toolkits really do need their windows to be configured correctly
for their O-R windows comboboxes or menus other things, so let's fix
the lazy compositors and remove this.
I have tested this patch with both Weston and Mutter and neither of
them require any changes, and it fixes comboboxes and menus.
If somebody then wants to revert 73698d4, that's fine by me, so we
reduce the amount of API that DDXen have.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
xwayland windows ignored any key repeating settings
advertised by a compositor
v2. don't hardcode version 4 of seat
use AutoRepeatModeOn/Off
v3. use min(version, 4) when binding seat
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
By the time we get here we've already done CloseDownDevices, so on the
second regeneration you get:
Invalid read of size 4
at 0x43402A: RemoveDevice (devices.c:1125)
by 0x427902: xwl_seat_destroy (xwayland-input.c:568)
by 0x42649C: xwl_close_screen (xwayland.c:116)
by 0x4B7F67: CursorCloseScreen (cursor.c:187)
by 0x536003: AnimCurCloseScreen (animcur.c:106)
by 0x539831: present_close_screen (present_screen.c:64)
by 0x43E486: dix_main (main.c:351)
by 0x30D70206FF: (below main) (libc-start.c:289)
Address 0x980e1a0 is 64 bytes inside a block of size 904
at 0x4A07D6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x434158: RemoveDevice (devices.c:1157)
by 0x42F77B: CloseDeviceList (devices.c:1017)
by 0x430246: CloseDownDevices (devices.c:1047)
by 0x43E3EB: dix_main (main.c:333)
by 0x30D70206FF: (below main) (libc-start.c:289)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
In some extreme cases with animated cursors at a high frame rate we
could end up filling the wl_display outgoing buffer and end up with
wl_display_flush() failing.
In any case, using the frame callback to throttle ourselves is the
right thing to do.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fix missing newlines from error string and fix grammar.
Signed-off-by: Robert Ancell <robert.ancell@canonical.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We don't even need to simulate button clicks; it's done automatically.
This also fixes scrolling in Qt5 apps.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Nothing was using it and if anyone had they would've gotten a warning and
noticed that it doesn't actually work. Drop this, it has been unused for years.
Input ABI 22
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Currently, the indexes are off by 4 because of the scroll buttons.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
If something quickly maps and unmaps a window, then we'll immediately
create and destroy the Wayland surface that cooresponds to that
window. If our mouse pointer is over the window when the surface is
created, we'll receive a enter on the window.
Since resource creation and destruction is not synchronous, that
means that the compositor will queue up an event for a resource that's
eventually destroyed. On the client-side, when we receive this message,
we note that the resource isn't allocated, and get a NULL surface in our
enter handler. We immediately try to dereference this, and then crash.
This was caused by running gtkperf while moving the window a lot.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Anytime a capability is first reported, the device is created, but after
that, it is only disabled/enabled.
This is a closer behavior to what Xorg does on VT switch, at the expense
of maybe leaving a dangling "physical" device if a capability goes for good.
Otherwise, any DeviceIntPtr (re)created after server initialization will be
left floating, and bad things happen when the wayland enter event handler
tries to update cursor position based on a floating device.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Started out as an Xorg module to be used from Xorg drivers to let
Xorg run under a wayland server. The idea was to be able to reuse the
2D acceleration from the Xorg driver. Now with glamor being credible,
a better plan is to just make Xwayland its own DDX, similar to Xwin
and Xquartz. This is a much better fit, as much of the code in the
original approach had to hack around Xorg doing Xorg things like take
over the VT, probe input devices and read config files. Another big win
is that Xwayland dosn't need to be setuid root.
The Xwayland support for DRI3, Glamor and render nodes was done by
Axel Davy <axel.davy@ens.fr>, who also did a lot of work on the rebase
to the Xwayland DDX.
Contributions from:
Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
Corentin Chary <corentin.chary@gmail.com>
Daniel Stone <daniel@fooishbar.org>
Kristian Høgsberg <krh@bitplanet.net>
Robert Bragg <robert@linux.intel.com>
Scott Moreau <oreaus@gmail.com>
Tiago Vignatti <tiago.vignatti@intel.com>
Giovanni Campagna <gcampagn@redhat.com>
Jonas Ådahl <jadahl@gmail.com>
Ray Strode <rstrode@redhat.com>
Trevor McCort <tjmccort@gmail.com>
Rui Matos <tiagomatos@gmail.com>
Axel Davy <axel.davy@ens.fr>
Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Axel Davy <axel.davy@ens.fr>
