Arch Linux

The latest beryl == which build number?
The latest from Unstable worked fine for me. Now I use even more later experimental version, made by brain0, which didn't went to Unstable because of unstability issues and bugs (though works fine for me too :p).

As I said, I run the latest SVN as offered by the Unstable (this bug report is filed against the Unstable category too). And yes, this new build is broken for my graphics card. It creates white rectangular borders around windows/menus/panels.

Today I upgraded my mesa to 6.5.2 and the problem started to appear. Beryl worked fine with the previous version of mesa. Downgrading mesa and libgl-dri to 6.5.1 fixed the problem. I think this build of beryl is OK.

Ok, could someone assign this bug report to the dri/mesa maintainer too then? Thanks.
Hopefully, when the textures come back when this bug is fixed, the speed that I have gained with the latest build is still there. Otherwise, there is a real bottleneck to be found and optimized... ;)

The problem seems to be with the latest libgl-dri. Only nvidia card users seems to be unafected.

I rebuilt beryl with the newest mesa and libgl-dri installed. I also disabled beryl-xgl in this build since that pulls in a static build of mesa I don't trust. Could someone test http://www.archlinux.org/~jgc/beryl-core-svn-1774-2.pkg.tar.gz to see if things are still working?

Another thing that might help: try using beryl-xgl instead of beryl as binary name, beryl-xgl is static linked against an internal snapshot of mesa in the package which is in the repositories at this moment.

Running beryl-xgl instead of just beryl (from the current Unstable repository) WORKS with my AIXGL setup, yes. This works well.

After I installed your package though, it removed beryl-xgl, and then new beryl executable has the SAME bug as I described above. In other words, your new test package did not fix the problem. The problem seems to be a real incompatibility between the GL libs and Beryl rather than just a recompilation/relinking problem.

BTW, if I re-install the Unstable beryl-core package, how do I make my Gnome load beryl-xgl rather than beryl by default? I had added "beryl" and "beryl-manager" in my Gnome's startup programs via gnome-session-properties, but now that I revisited that panel, only beryl-manager is there! Weird stuff...

Have you tried newer beryl builds?
I use 1918 now, except for heliodor, which was not updated by brain0 at that time. Due to more experimental nature these packages haven't hit Unstable, but they work for me.
Maybe build 1918 has those compatability issues fixed, just a guess. :-/

btw, only beryl-manager should be added to gnome session autostart. It will run beryl automatically.

>I use 1918 now

I prefer to use stuff that are provided by Arch Linux only -- even if they are in their unstable trees. I prefer to minimize future problems and file conflicts.

>only beryl-manager should be added to gnome session autostart.

How do I tell it to run beryl-xgl instead then?

> I prefer to use stuff that are provided by Arch Linux only
brain0 is Arch dev and beryl package manager, so I assume those packages are provided by Arch.
He just gave me those packages for testing and I liked new features, so I keep those packages until new version will be out.

> How do I tell it to run beryl-xgl instead then?
symlink?

I'm fresh to beryl also, I used the wiki to get something working on my system. The most simple way to force beryl-xgl is to use "cp /usr/bin/beryl-xgl /usr/bin/beryl" for now, that will make sure you will have beryl-xgl running all the time until we fix our packages (either mesa+xorg-server, or a static build of beryl).

I think https://bugs.freedesktop.org/show_bug.cgi?id=9456 describes the problem best, I filed it at freedesktop.org a few minutes ago.

I suspect something is going wrong in the initialization of textures here. A temporary "fix" would be to compile beryl with a static mesa snapshot which doesn't have this bug, as it only affects the texture_from_pixmap things at this moment, which is hardly used by other programs.

Thanks Jan! You rock!

BTW, a new major version was released today: http://www.digg.com/linux_unix/Beryl_0_1_4_Released

Due to absence of a fast compiling and testing machine, there won't be any new beryl packages until January 8th or maybe a few days later. Due to absence of an AIGLX machine, I will have to rely on you guys for testing it, I can only provide testing for nvidia, which apparently always works.

Using the statically built beryl-xgl binary is sort of a workaround, we should always be able to use the system's libGL with AIGLX, that should be investigated once I am back.

As for 0.1.4: I won't put any beryl releases into extra until beryl 0.2 (the first "stable") will be released in February. The 0.1.X are only development "releases", which aren't much better than the svn versions.

For what it's worth, I'll be happy to provide any testing with AIGLX on an i810 card. For now, I have downgraded the libgl-dri package and things are working well here.

Nobody said putting it on Extra, unstable is fine. I will compile the 0.1.4 by myself until you have a new version out. Hopefully you don't use anything else other than --prefix=/usr in the configure script...

Erm, why not use abs && versionpkg to update beryl? Granted svn will be a little different than the 0.1.4 release at this point, but probably not much.

Or, at the very least, you can look at the PKGBUILD and see the compile options..

I just tried the 0.1.4 release and it also has the bug.

I'm also having this problem. I'd be happy to test with my:

01:00.0 VGA compatible controller: ATI Technologies Inc M24 1T [FireGL M24 GL] (rev 80)

:)

this should definitely be confirmed

OK, it appeared to be a GLX protocol mismatch between mesa and Xorg. Xorg-server contains some pregenerated files which are generated by the mesa 6.5 sources. With a bit of bad luck, 6.5.1 shouldn't work either.

I regenerated these files from mesa for xorg-server-1.1.1-6, which will appear in the repository soon (also fixes a security issue).