8:25 a.m.
Hi
since last Monday or so, I have been able to run firefox over ssh
anymore. I thought it was my setup, but further investigation showed
that it is something specific to firefox.
My setup is a bit more convoluted than this, but I am able to do:
$ ssh -X localhost gnome-terminal
And it shows a terminal as expected
$ ssh -X localhost firefox
Without a firefox running will hang there forever, no output at all. I
tried doing strace of it, and see that is waiting for futexes. But
haven't been able to see what is happening.
Until last Tuesday or so (I am on F23) firefox worked over ssh without
any problems. I have been running it like that for something like a
year.
Anyone has any suggestion? I tried also
$ ssh -Y localhost firefox
And it didn't helped at all (not that I am sure of the difference either).
Later, Juan.
PD. Really, what I normally do is run ssh to a virtual manchine in the
same host.
9:42 a.m.
On Tue, Mar 08, 2016 at 03:25:05PM +0100, Juan Quintela wrote:
Anyone has any suggestion?
Does setting LIBGL_DRI3_DISABLE=1 help?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
11:12 a.m.
On Tue, 2016-03-08 at 17:54 +0100, Juan Quintela wrote:
Yes. This makes it work. Thanks a lot.
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
12:22 p.m.
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> Yes. This makes it work. Thanks a lot.
Then it was probably broken by this update:
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as
well (running Iceweasel on a remote Debian box from a local
Fedora box). Does that mean that there is an error in Fe-
dora, Firefox/Iceweasel, something else? Is there a bug
tracking this?
Tim
2:30 p.m.
On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote:
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> Then it was probably broken by this update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as
well (running Iceweasel on a remote Debian box from a local
Fedora box). Does that mean that there is an error in Fe-
dora, Firefox/Iceweasel, something else? Is there a bug
tracking this?
libreoffice-core-5.0.5.2-6.fc23.x86_64 is broken+workarounded the same way.
Jan
8:43 p.m.
On Fri, 2016-04-01 at 21:30 +0200, Jan Kratochvil wrote:
On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote:
> Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> > Then it was probably broken by this update:
>
> > https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
>
> The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as
> well (running Iceweasel on a remote Debian box from a local
> Fedora box). Does that mean that there is an error in Fe-
> dora, Firefox/Iceweasel, something else? Is there a bug
> tracking this?
libreoffice-core-5.0.5.2-6.fc23.x86_64 is broken+workarounded the
same way.
Jan
I will just add: DRI3 plus the modesetting graphics driver (mandatory
for new Intel processors) plus accelerated compositing is known-broken
in WebKit; we unfortunately cannot support that combination. As we are
going to make accelerated compositing mandatory in WebKit in the near
future, my understanding is that will break all apps using WebKit for
users with new computers. Only known solution is LIBGL_DRI3_DISABLE=1.
This is your obligatory "I told you so" for when the complaints start
rolling in half a year from now.
This is https://bugs.freedesktop.org/show_bug.cgi?id=85064
I'm concerned that we may have enabled DRI3 before it was fully-baked,
if it's known to be broken with Firefox, WebKit, LibreOffice....
Michael
2:20 a.m.
On Sat, Apr 2, 2016 at 3:43 AM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Fri, 2016-04-01 at 21:30 +0200, Jan Kratochvil wrote:
> On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote:
> > Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
> > > Then it was probably broken by this update:
> >
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
> >
> > The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as
> > well (running Iceweasel on a remote Debian box from a local
> > Fedora box). Does that mean that there is an error in Fe-
> > dora, Firefox/Iceweasel, something else? Is there a bug
> > tracking this?
>
> libreoffice-core-5.0.5.2-6.fc23.x86_64 is broken+workarounded the
> same way.
>
>
> Jan
I will just add: DRI3 plus the modesetting graphics driver (mandatory
for new Intel processors)
This is not true. While the plan is to get stop using device specific
ddx drivers
you do not need modesetting for "new intel processors" they works with the
intel ddx as well.
plus accelerated compositing is known-broken
in WebKit; we unfortunately cannot support that combination.
Why?
As we are
going to make accelerated compositing mandatory in WebKit in the near
future, my understanding is that will break all apps using WebKit for
users with new computers. Only known solution is LIBGL_DRI3_DISABLE=1.
This is your obligatory "I told you so" for when the complaints start
rolling in half a year from now.
This is https://bugs.freedesktop.org/show_bug.cgi?id=85064
I'm concerned that we may have enabled DRI3 before it was fully-baked,
if it's known to be broken with Firefox, WebKit, LibreOffice....
Its not broken with Firefox or LibreOffice ... it can by design not work
remotely. This issue has been fixed in xserver git by transparently fallback
to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=93261
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan.
It also helps compositors like mutter to avoid tearing and improves performance.
So if there are issues with WebKit they should be fixed. "It can't
work lets go back to DRI2" isn't really an option in the long run
2:26 a.m.
On 04/02/2016 12:20 AM, drago01 wrote:
Its not broken with Firefox or LibreOffice ... it can by design not
work
remotely. This issue has been fixed in xserver git by transparently fallback
to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=93261
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan.
It also helps compositors like mutter to avoid tearing and improves performance.
So if there are issues with WebKit they should be fixed. "It can't
work lets go back to DRI2" isn't really an option in the long run
Does this mean that eventually X applications over ssh will stop working?
You say it's currently fixed by falling back to DRI2, but then you say
that DRI2 is going away or at least won't be supported.
2:39 a.m.
On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb <samuel(a)sieb.net> wrote:
On 04/02/2016 12:20 AM, drago01 wrote:
>
> Its not broken with Firefox or LibreOffice ... it can by design not work
> remotely. This issue has been fixed in xserver git by transparently
> fallback
> to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=93261
>
> Also XWayland only supports DRI3; and DRI3 on X is a requirement for
> Vulkan.
> It also helps compositors like mutter to avoid tearing and improves
> performance.
> So if there are issues with WebKit they should be fixed. "It can't
> work lets go back to DRI2" isn't really an option in the long run
Does this mean that eventually X applications over ssh will stop working?
You say it's currently fixed by falling back to DRI2, but then you say that
DRI2 is going away or at least won't be supported.
DRI2 will stay around. It just wont be the default choice for the above reasons.
3:04 a.m.
On Sat, 02 Apr 2016 09:39:33 +0200, drago01 wrote:
On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb <samuel(a)sieb.net>
wrote:
> On 04/02/2016 12:20 AM, drago01 wrote:
>> Also XWayland only supports DRI3;
>
> You say it's currently fixed by falling back to DRI2, but then you say that
> DRI2 is going away or at least won't be supported.
DRI2 will stay around. It just wont be the default choice for the above reasons.
But after Fedora switches to Wayland (XWayland?) then you say DRI2 won't be
around anymore. So I do not understand how it will work afterwards.
>> So if there are issues with WebKit they should be fixed.
"It can't
>> work lets go back to DRI2" isn't really an option in the long run
Therefore not only WebKit but also Firefox and LibreOffice each need their own
specific fixes?
Jan
3:10 a.m.
On Sat, Apr 2, 2016 at 10:04 AM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
On Sat, 02 Apr 2016 09:39:33 +0200, drago01 wrote:
> On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb <samuel(a)sieb.net> wrote:
> > On 04/02/2016 12:20 AM, drago01 wrote:
> >> Also XWayland only supports DRI3;
> >
> > You say it's currently fixed by falling back to DRI2, but then you say that
> > DRI2 is going away or at least won't be supported.
>
> DRI2 will stay around. It just wont be the default choice for the above reasons.
But after Fedora switches to Wayland (XWayland?) then you say DRI2 won't be
around anymore. So I do not understand how it will work afterwards.
You get software rendering.
> >> So if there are issues with WebKit they should be fixed.
"It can't
> >> work lets go back to DRI2" isn't really an option in the long run
Therefore not only WebKit but also Firefox and LibreOffice each need their own
specific fixes?
LibreOffie and Firefox do not need any fixes.
9:17 a.m.
On Sat, 2016-04-02 at 09:20 +0200, drago01 wrote:
This is not true. While the plan is to get stop using device
specific
ddx drivers
you do not need modesetting for "new intel processors" they works
with the
intel ddx as well.
Great. Maybe that plan could be delayed until this issue is resolved,
then?
> plus accelerated compositing is known-broken
> in WebKit; we unfortunately cannot support that combination.
Why?
I don't know. It works with other graphics drivers.
Its not broken with Firefox or LibreOffice ... it can by design not
work
remotely. This issue has been fixed in xserver git by transparently
fallback
to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=
93261
OK
Also XWayland only supports DRI3; and DRI3 on X is a requirement for
Vulkan.
OK
It also helps compositors like mutter to avoid tearing and improves
performance.
OK
So if there are issues with WebKit they should be fixed. "It
can't
work lets go back to DRI2" isn't really an option in the long run
It would be great if somebody would fix this. I just want to give a
heads-up that we are not going to delay architectural improvements in
WebKit for just DRI3 plus modesetting driver, and that this is going to
render lots of apps totally unusable (gnome-initial-setup, gnome-
online-accounts, Evolution, etc.) possibly in the F25/F26 timeframe if
this isn't resolved.
Michael
1:19 p.m.
On Sat, 2016-04-02 at 09:17 -0500, Michael Catanzaro wrote:
>
> So if there are issues with WebKit they should be fixed. "It can't
> work lets go back to DRI2" isn't really an option in the long run
It would be great if somebody would fix this. I just want to give a
heads-up that we are not going to delay architectural improvements in
WebKit for just DRI3 plus modesetting driver, and that this is going
to
render lots of apps totally unusable (gnome-initial-setup, gnome-
online-accounts, Evolution, etc.) possibly in the F25/F26 timeframe
if
this isn't resolved.
That seems to be a bit over-dramatic. gnome-initial-setup works fine.
The online accounts step will be affected, but that's about it.
2:13 p.m.
On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
That seems to be a bit over-dramatic. gnome-initial-setup works
fine.
The online accounts step will be affected, but that's about it.
Yes, only the webview portions of g-i-s would be affected, of course
(gnome-online-accounts page, and the EULA page). Users will still be
able to install Fedora. Only the webviews would become borderline
unusable.
And the breakage will be limited to only those using the modesetting
driver, i.e. computers than are newer than the ones we're probably
using right now.
Michael
2:33 p.m.
On Mon, Apr 4, 2016 at 3:13 PM, Michael Catanzaro <mcatanzaro(a)gnome.org>
wrote:
On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
> That seems to be a bit over-dramatic. gnome-initial-setup works fine.
> The online accounts step will be affected, but that's about it.
And the breakage will be limited to only those using the modesetting
driver, i.e. computers than are newer than the ones we're probably
using right now.
Intel i7-6700k checking in. Unless i misunderstood the thread, does Skylake
not use -modesetting?
2:56 p.m.
On Mon, 4 Apr 2016 15:33:51 -0400
Eric Griffith <egriffith92(a)gmail.com> wrote:
On Mon, Apr 4, 2016 at 3:13 PM, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
> > That seems to be a bit over-dramatic. gnome-initial-setup works
> > fine. The online accounts step will be affected, but that's about
> > it.
>
> And the breakage will be limited to only those using the modesetting
> driver, i.e. computers than are newer than the ones we're probably
> using right now.
>
Intel i7-6700k checking in. Unless i misunderstood the thread, does
Skylake not use -modesetting?
It does.
Also, I haven't seen any of the breakage in webkit mentioned in this
thread here with a skylake laptop.
kevin
3:23 p.m.
On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
It does.
Also, I haven't seen any of the breakage in webkit mentioned in this
thread here with a skylake laptop.
The bug only occurs in accelerated compositing (OpenGL) mode, which is
currently only used when necessary to support a particular web page
(e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing
work is to make accelerated compositing mode mandatory and use it on
all web pages. Once this work lands, modesetting driver users will need
to disable DRI3 in order to practically use WebKit.
Michael
3:29 p.m.
On Mon, 04 Apr 2016 15:23:56 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
> It does.
>
> Also, I haven't seen any of the breakage in webkit mentioned in this
> thread here with a skylake laptop.
The bug only occurs in accelerated compositing (OpenGL) mode, which is
currently only used when necessary to support a particular web page
(e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing
work is to make accelerated compositing mode mandatory and use it on
all web pages. Once this work lands, modesetting driver users will
need to disable DRI3 in order to practically use WebKit.
ok, that makes more sense. Thanks.
kevin
9:01 a.m.
On Mon, 2016-04-04 at 15:23 -0500, Michael Catanzaro wrote:
On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
>
> It does.
>
> Also, I haven't seen any of the breakage in webkit mentioned in
> this
> thread here with a skylake laptop.
The bug only occurs in accelerated compositing (OpenGL) mode, which
is
currently only used when necessary to support a particular web page
(e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing
work is to make accelerated compositing mode mandatory and use it on
all web pages. Once this work lands, modesetting driver users will
need
to disable DRI3 in order to practically use WebKit.
Once again goes to show how problematic it is to use web rendering
stacks from browsers in other places: Now we have an initial setup tool
that depends on GL+DRI3 working just because it needs to render two
entries in a webpage :-(
12:57 a.m.
On Mon, Apr 4, 2016 at 9:33 PM, Eric Griffith <egriffith92(a)gmail.com> wrote:
On Mon, Apr 4, 2016 at 3:13 PM, Michael Catanzaro
<mcatanzaro(a)gnome.org>
wrote:
>
> On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
> > That seems to be a bit over-dramatic. gnome-initial-setup works fine.
> > The online accounts step will be affected, but that's about it.
>
> And the breakage will be limited to only those using the modesetting
> driver, i.e. computers than are newer than the ones we're probably
> using right now.
Intel i7-6700k checking in. Unless i misunderstood the thread, does Skylake
not use -modesetting?
It does on F24 / rawhide ... it still uses the intel ddx on F23.
3 p.m.
On Sat, 2 Apr 2016 09:20:00 +0200
drago01 <drago01(a)gmail.com> wrote:
This is not true. While the plan is to get stop using device
specific
ddx drivers
you do not need modesetting for "new intel processors" they works
with the intel ddx as well.
My understanding is that gen9 intel chipsets get modesetting, gen8 and
earlier still use xorg-x11-drv-intel. (For f24+)
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-intel.git/commit/?h=...
...snip...
Also XWayland only supports DRI3; and DRI3 on X is a requirement for
Vulkan. It also helps compositors like mutter to avoid tearing and
improves performance. So if there are issues with WebKit they should
be fixed. "It can't work lets go back to DRI2" isn't really an option
in the long run --
Oddly, I have a skylake laptop here (gen 9) and it does indeed use
modesetting driver, but I only get DRI2 (which is why I haven't seen
any DRI3 problems I guess).
Apr 02 13:50:17 sheelba.scrye.com org.gnome.Shell.desktop[2064]:
glamor: EGL version 1.4 (DRI2):
Is DRI3 only default for xorg-x11-drv-intel ?
kevin
4:14 p.m.
On Sat, Apr 2, 2016 at 10:00 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, 2 Apr 2016 09:20:00 +0200
drago01 <drago01(a)gmail.com> wrote:
> This is not true. While the plan is to get stop using device specific
> ddx drivers
> you do not need modesetting for "new intel processors" they works
> with the intel ddx as well.
My understanding is that gen9 intel chipsets get modesetting, gen8 and
earlier still use xorg-x11-drv-intel. (For f24+)
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-intel.git/commit/?h=...
That's a fedora specific patch I haven't seen yet. But given that's
what we want to move to its ok anyways.
> Also XWayland only supports DRI3; and DRI3 on X is a requirement
for
> Vulkan. It also helps compositors like mutter to avoid tearing and
> improves performance. So if there are issues with WebKit they should
> be fixed. "It can't work lets go back to DRI2" isn't really an
option
> in the long run --
Oddly, I have a skylake laptop here (gen 9) and it does indeed use
modesetting driver, but I only get DRI2 (which is why I haven't seen
any DRI3 problems I guess).
Apr 02 13:50:17 sheelba.scrye.com org.gnome.Shell.desktop[2064]:
glamor: EGL version 1.4 (DRI2):
Is DRI3 only default for xorg-x11-drv-intel ?
No. This line does not tell you much.
Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if
you have to lines in that output you'd have DRI3.
As for why you haven't seen problems ... because usually it "just
works" (even better than DRI2).
4:28 p.m.
On Sat, 2 Apr 2016 23:14:14 +0200
drago01 <drago01(a)gmail.com> wrote:
No. This line does not tell you much.
Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if
you have to lines in that output you'd have DRI3.
Intuitive. :)
% glxinfo|grep buffer_age
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age,
As for why you haven't seen problems ... because usually it
"just
works" (even better than DRI2).
Alright.
kevin
5:11 a.m.
On Sat, Apr 2, 2016 at 11:28 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, 2 Apr 2016 23:14:14 +0200
drago01 <drago01(a)gmail.com> wrote:
> No. This line does not tell you much.
>
> Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if
> you have to lines in that output you'd have DRI3.
Intuitive. :)
Well that's the easiest thing I could think of that doesn't require
jumping through hoops ... you could use dri3info, which isn't
packaged.
But you can do:
wget https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/tools/dri3...
gcc -o dri3info dri3info.c `pkg-config --cflags --libs xcb-dri3
x11-xcb xrandr xxf86vm libdrm`
./dri3info
10:49 a.m.
New subject: Detecting DRI3
On 04/03/2016 04:11 AM, drago01 wrote:
On Sat, Apr 2, 2016 at 11:28 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Sat, 2 Apr 2016 23:14:14 +0200
> drago01 <drago01(a)gmail.com> wrote:
>
>> No. This line does not tell you much.
>>
>> Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if
>> you have to lines in that output you'd have DRI3.
>
> Intuitive. :)
Well that's the easiest thing I could think of that doesn't require
jumping through hoops ... you could use dri3info, which isn't
packaged.
But you can do:
wget https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/tools/dri3...
gcc -o dri3info dri3info.c `pkg-config --cflags --libs xcb-dri3
x11-xcb xrandr xxf86vm libdrm`
./dri3info
Should be:
wget
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/plain/tools/dri...
I'll note:
# glxinfo|grep buffer_age
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
# ./dri3info
Display ':0'
Unable to connect to DRI3
Primary refresh rate: 865625/14443 (59.9Hz)
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
11:02 a.m.
On Fri, 2016-04-01 at 20:43 -0500, Michael Catanzaro wrote:
I will just add: DRI3 plus the modesetting graphics driver
(mandatory
for new Intel processors) plus accelerated compositing is known-
broken
in WebKit; we unfortunately cannot support that combination. As we
are
going to make accelerated compositing mandatory in WebKit in the near
future, my understanding is that will break all apps using WebKit for
users with new computers. Only known solution is
LIBGL_DRI3_DISABLE=1.
This is your obligatory "I told you so" for when the complaints start
rolling in half a year from now.
This is https://bugs.freedesktop.org/show_bug.cgi?id=85064
I'm concerned that we may have enabled DRI3 before it was fully-
baked,
if it's known to be broken with Firefox, WebKit, LibreOffice....
Michael
Hi,
This is a heads-up that the change to enable accelerated compositing
always has landed in WebKit trunk and will be landing in rawhide soon.
As previously discussed, the DRI3 plus modesetting driver combination
is known to be broken in accelerated compositing mode as per [1].
WebKitWebViews will most likely not be functional in F25 for affected
users. Any help in fixing [1] would of course be appreciated. The
relevant upstream WebKit developers are not very interested in this
problem because Debian doesn't use DRI3.
Michael
[1] https://bugs.freedesktop.org/show_bug.cgi?id=85064
4:50 a.m.
On 29.03.2016 19:22, Tim Landscheidt wrote:
Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
>> Yes. This makes it work. Thanks a lot.
> Then it was probably broken by this update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as
well (running Iceweasel on a remote Debian box from a local
Fedora box). Does that mean that there is an error in Fe-
dora, Firefox/Iceweasel, something else? Is there a bug
tracking this?
looks like
https://bugzilla.redhat.com/show_bug.cgi?id=1174257
2832
days inactive
2968
days old
27 comments
12 participants
participants (12)
-
drago01 -
Eric Griffith -
Jan Kratochvil -
Juan Quintela -
Kevin Fenzi -
Matthias Clasen -
Michael Catanzaro -
Michael Stahl -
Orion Poplawski -
Richard W.M. Jones -
Samuel Sieb -
Tim Landscheidt