Monday, October 30, 2006

Flash/XComposite crasher in X11

This one has been around for a while: When you enable the XComposite extension in X11 and run your desktop using a 15 or 16bit screen depth, the Flash Player will always crash with this error message:
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 115 error_code 8 request_code 143 minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Segmentation fault (core dumped)
There are two workarounds for this:

  • Set the screen depth to 24bit. If you have enough VRAM available this is a good move anyway since you'll get much better performance and quality in general when using Flash. Other applications probably also benefit, there should be less color banding in general.

  • Set the XLIB_SKIP_ARGB_VISUALS environment variable to 1 in one of your init scripts before X11 is started.

So why have we not fixed this in the past? Well, I've not written the code in question and IMO it's even questionable if it is a bug in Flash, depending on what XMatchVisualInfo API is really supposed to do. The docs really do not provide too much information here. The core of the problem is this code in the Flash Player:
int depth = 0;
int mode = 0;
XVisualInfo vi;
static struct
{
int depth, mode;
} formats[] = {
{ 24, TrueColor},
{ 32, TrueColor},
{ 16, TrueColor},
{ 15, TrueColor},
{ 8, PseudoColor},
{ 0, 0}
};
for (int i=0;formats[i].depth; i++ )
{
if(XMatchVisualInfo(display,
DefaultScreen(display),
formats[i].depth,
formats[i].mode,
&vi)) {
depth = formats[i].depth;
mode = formats[i].mode;
break;
}
}
If XComposite is turned on and your screen depth is 16bit this loop will break when the depth is 32. That depth is used to create the XImage the Flash Player will use for its backbuffer. The actual crash occurs when XPutImage or XShmPutImage is called. At this point X11 will bail out when given an XImage with a depth of 32bit.

The fix? It's as simple as prepending this code to the above loop:
XWindowAttributes attribs;
if(XGetWindowAttributes(display,window,&attribs)) {
if(XMatchVisualInfo(display,
DefaultScreen(display),
attribs.depth,
TrueColor,
&vi) {
depth = attribs.depth;
mode = TrueColor;
}
}
if(!depth){
...
}
Pretty much every distribution has complained about this issue over the past few years, so I am happy that we finally resolved this for good. Is this fix in the current beta of the Flash Player (9.0.21.55)? No, I just changed this Friday, so you'll have to wait for a newer build. It also needs to go through QE before this change gets the final approval.

Labels:

Tuesday, October 24, 2006

Extending the reach of the Flash Player on Linux

If you are a Linux user you have probably downloaded the Flash Player beta for Linux by now and played around with it. And if you are running on a system without ALSA you have no sound right now. Or you might have other sound playback issues. Bummer. You really want OSS don't you? And you probably think that you can write better code than we can, don't you? ;-)

We want to partially address this for the upcoming release. The truth is that it is rather difficult for us to support all the different APIs available on Linux. Things change frequently. Overall this is good in since it keeps innovation going. On the other hand we want to concentrate on the APIs which are used the most and ideally drop any legacy and bleeding edge support from the player to keep things lite, predictable and testable by our QE staff. There is still a lot of work left to do on our side, but for now have a look at this page:

Additional Interface Support for Linux

flashsupport.c currently has sample code for OpenSSL, GnuTLS (which is not working), ICU, ALSA and OSS interfaces. The Video4Linux1 code in flashsupport.c is currently not used at all by the Flash Player but I hope to get this up and running for the final release although I can't make any promises here. For now most of you will probably want to play around with the sound support.

As said on the Wiki this is all work in progress, highly experimental and completely untested (apart from me trying it on my lone Ubuntu box). I am sure I will change a bunch of stuff in the not too distant future and hopefully QE will also be able to give this a spin. But if you have anything to say about the approach we are taking, now is the time to speak up and give feedback. And no, we are NOT making the Flash Player open source with this, we are simply trying to give the community a chance to make the player work on as many environments as possible.

(Update: I fixed the line endings in flashsupport.c, OSS should hopefully not have the AV sync problem anymore and I missed to copy&paste a sem_init in the ALSA code)

Tuesday, October 17, 2006

Flash Player 9 for Linux Beta 1



To quote someone well known, 'hell froze over' and we finally released a beta of the GNU/Linux version of the Adobe Flash Player 9 (look for the "Linux version" download link). It did take more to get to this point than you might expect. And no, Mike is not the only engineer working on it. Currently I count 6 engineers working on the GNU/Linux platform, even more have GNU/Linux boxen and/or VMWare images now. And there is still a lot of work left to do before I consider this penguin version not a beta anymore.

Now is this beta version bug free? By no means. Will it install and fully work your specific distro? There is a good chance it will not, although I have tried a good dozen of distributions. Do not walk away frustrated, instead submit as many bugs reports as you can. And no, the feedback page is not a black hole. We collect all feedback, enter it in our bug database and then prioritize it.

There are various things I am not quite happy about in the current version. We'll address these things over time. On my plate for research right now (and not in the beta 1 version) is Xembed support which should yield much better integration into the desktop environment and numerous other advantages.

What I am happy about is performance. This is the fastest GNU/Linux version we ever released. And we haven't reached the maximum yet. While annoying on my part since I had to deal with some rather mechanical conversion from Intel to AT&T assembly notation, it was really worth it. Even better, we will use the same code on OS X to get a completely relocatable binary, something Apple does not offer if you use MS style inline assembly, although this was a big new feature promoted by them to allow easy porting. In some cases though the GNU/Linux version is still way behind the Windows 32bit version (device text rendering performance which is using FreeType f.ex.), but in some cases the GNU/Linux version is up to 20% faster on the same hardware compared to the Windows 32bit version. It will be interesting to see what kind of benchmarks people will come up with. I will try to get this as good as it can get for the final release and so will everyone else on the team.

What about 64bit? There is no Windows 64bit or OS X 64bit version either right now. As I said before it is not a question of 'recompiling' the source code, there is lots of generic non platform specific work which needs to be finished first. We will ship a 64bit version for Windows, OS X Leopard and GNU/Linux. It will happen. When? ... When it is ready.