I thought that I'd christen this forum with a Chromium problem that I've encountered on a Linux Box with a GeForce3:
After making the apps/libraries, I seem to run into trouble with the 'Hello World' example listed on the project's main page. I get the blank screen after running the mothership and crserver. However, crappfaker doesn't what you'd expect. Instead of displaying 'fonttest' in the crserver's window, I get the new window with a messed up color palette. In other words, fonttest doesn't seem to be redirected to the servers window and end messes up X's color palette in the process. The messed up palette can only be described as an inversion of the current colors that's only active when crappfaker's window is active.
I should mention that this isn't limited to fonttest or the crdemo.conf files. I've tried a slew of different files. I wanna say that there's something funky with glx...
I'd appreciate any response.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is normal -- you should see the output in a *different* window which should be titled the "Chromium Render SPU".
X is messing with your color palette when the window gains focus. I expect this is happening because we're intercepting glXChooseVisual, so the bogus window is getting created with some sort of color-index visual that is grabbing a local palette when you enter it. I've been meaning to fix that behavior for a while; I'll go ahead and file it as a bug.
-Greg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, the output doesn't go to the crserver's window. In fact, it doesn't go to either window (the latter being the one create by the app faker). Both have blank screens and the palette problem that I mentioned earlier.
crappfaker seems to intercept all the libGL files successfully after I took a look at the debugger output. Just for kicks, I threw in a break statement in the while loop (nested in a for loop) of the do_it() function of app_faker.c and the program goes to crappfaker's window (but obviously that's the wrong window).
Thanks much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, unfortunately the bogo-color-map is a bit of a red herring, although the build for the source tree I pulled out of CVS tonight doesn't exhibit the color map problem.
Color-maps aside, we're seeing the same null-render problem, with nvidia drivers 1.0-1251 on RedHat 7.1 (up). What version of the drivers are you using?
Log files also suggest that the call stream is properly getting to the print spu on the server, but what's happening to the calls in the render spu isn't as clear...
I've not had time yet to properly grub through the code to figure it out, but I note the following from the driver (1.0-1251) installation notes:
" OpenGL and dlopen()
The current thought is that there are some bugs in the glibc
dynamic library loading and libdl.so that cause problems with
applications that use dlopen() to load the OpenGL library.
Apps that use dlopen() include Quake3 and Radiant. A workaround
has been implemented that will fix some, but not all, cases
where this happens."
...don't know if this is applicable, but it seems suspect...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed that the color-map problem went away after doing a CVS checkout, too. We here at Argonne are using the exact same Nvidia drivers: 1.0-1251. Our Linux boxes are running Mandrake 7.2 and have 64MB GeForce 3's installed (ELSA Gladiac 920). I examined the log files pretty thoroughly and everything looked fine on that end. We're wondering if something weird is going on with the Render SPU or maybe the unpacker. I'm starting to suspect if the Nvidia drivers are the problem after reading you previous post. Anyway, I'm now building Chromium on a Win2K box w/ a Nvidia Quadro to see if we're getting the same problem. I'll post a note on how that goes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Welcome to Help
I thought that I'd christen this forum with a Chromium problem that I've encountered on a Linux Box with a GeForce3:
After making the apps/libraries, I seem to run into trouble with the 'Hello World' example listed on the project's main page. I get the blank screen after running the mothership and crserver. However, crappfaker doesn't what you'd expect. Instead of displaying 'fonttest' in the crserver's window, I get the new window with a messed up color palette. In other words, fonttest doesn't seem to be redirected to the servers window and end messes up X's color palette in the process. The messed up palette can only be described as an inversion of the current colors that's only active when crappfaker's window is active.
I should mention that this isn't limited to fonttest or the crdemo.conf files. I've tried a slew of different files. I wanna say that there's something funky with glx...
I'd appreciate any response.
This is normal -- you should see the output in a *different* window which should be titled the "Chromium Render SPU".
X is messing with your color palette when the window gains focus. I expect this is happening because we're intercepting glXChooseVisual, so the bogus window is getting created with some sort of color-index visual that is grabbing a local palette when you enter it. I've been meaning to fix that behavior for a while; I'll go ahead and file it as a bug.
-Greg
Unfortunately, the output doesn't go to the crserver's window. In fact, it doesn't go to either window (the latter being the one create by the app faker). Both have blank screens and the palette problem that I mentioned earlier.
crappfaker seems to intercept all the libGL files successfully after I took a look at the debugger output. Just for kicks, I threw in a break statement in the while loop (nested in a for loop) of the do_it() function of app_faker.c and the program goes to crappfaker's window (but obviously that's the wrong window).
Thanks much.
Yes, unfortunately the bogo-color-map is a bit of a red herring, although the build for the source tree I pulled out of CVS tonight doesn't exhibit the color map problem.
Color-maps aside, we're seeing the same null-render problem, with nvidia drivers 1.0-1251 on RedHat 7.1 (up). What version of the drivers are you using?
Log files also suggest that the call stream is properly getting to the print spu on the server, but what's happening to the calls in the render spu isn't as clear...
I've not had time yet to properly grub through the code to figure it out, but I note the following from the driver (1.0-1251) installation notes:
" OpenGL and dlopen()
The current thought is that there are some bugs in the glibc
dynamic library loading and libdl.so that cause problems with
applications that use dlopen() to load the OpenGL library.
Apps that use dlopen() include Quake3 and Radiant. A workaround
has been implemented that will fix some, but not all, cases
where this happens."
...don't know if this is applicable, but it seems suspect...
I noticed that the color-map problem went away after doing a CVS checkout, too. We here at Argonne are using the exact same Nvidia drivers: 1.0-1251. Our Linux boxes are running Mandrake 7.2 and have 64MB GeForce 3's installed (ELSA Gladiac 920). I examined the log files pretty thoroughly and everything looked fine on that end. We're wondering if something weird is going on with the Render SPU or maybe the unpacker. I'm starting to suspect if the Nvidia drivers are the problem after reading you previous post. Anyway, I'm now building Chromium on a Win2K box w/ a Nvidia Quadro to see if we're getting the same problem. I'll post a note on how that goes.