Well it is a vsync error - which is extra funny when it looks much better with xv and oss driver...
I never filed a bug because for me it's SO OBVIOUS that I assumed everybody knew and nobody cared / knew how to solve it. For example, I find it impossible to find a #000000 colored pixel with fglrx + xv. The lowest color I can find is a greyish #101010. Just play a video with a black start and notice the difference between the bands and the image:
http://www.xente.mundo-r.com/narf/img/screens/xv.png
With fglrx + gl, fglrx + x11 or EVERY other video driver (radeon, nouveau, nvidia and intel, I also have intel and nvidia chips) it looks like this:
http://www.xente.mundo-r.com/narf/img/screens/gl.png
The same happens with whites or other strong colors. And it has been like this since I bought my 3850... 21 months ago.
Well it is a vsync error - which is extra funny when it looks much better with xv and oss driver...
That's not a fglrx specific bug it happens with Windows too. ATI always uses Video-Level for Videos and there ist no way to configure it to PC-Level.
I'll ask around; it's possible we're using playback on Windows as a reference.
I also suffer from the washed out colours, exactly as Fran describes it.
For reference, I just did a comparison on a trailer for Diablo 3 which I downloaded earlier today. (Monk Trailer). In one window I had Totem running Xv. In another window I had smplayer running OpenGL. Both players where running side by side and in sync. OpenGL yeilds much better result. Xv was gray by comparison. Tough the trailer doesn't contain much colour it's still possible to notice the washed out colours.
I'm running Catalyst 9.8 and Ubuntu 9.04.
I'm pretty sure everybody does; as Muad'Dib pointed out this is most probably caused by fglrx using 16-235 instead of 0-255 for each RGB component under xv.
I seem to remember there was a registry trick to solve the problem in windows (force the driver to expand to 0-255), but in linux...![]()
Great to see people talking about this issue
Frans screenshots nails it. It's funny that with free radeon driver when using Xv the black is black like it should be, but for some reason just like it shows that with catalyst it's brown in a way like some early LCD screens produced black back in the days.
Thanks AMD for the driver, don't forget to release 9.9 and 9.10 (final), too
of course it's still there !
you haven't re-compiled your x-server with the fix from fedora (it's an issue caused by intel from what I've read so far)
fglrx+kde4+composite, how to make it really fast (f.g.o)
the patch is called: fedora_dont_backfill_bg_none.patch patch
when using an x-server with that patch included there's no delay in maximizing (none with compiz and none with kwin's opengl backend)![]()
For the slow resize fiasco, the solution for distros is simple:
1. Keep the backfill functionality in the default x server packages.
2. Add the no backfill x server package to the repository
3. Modify fglrx package building script to set the x server no backfill package as a recommended or dependency.
4. When users install the driver, the good x server will also be pulled.
Why is this not done?![]()
anyone tried KDE4 kwin's compositing with opengl and whether the invert effect works now ?
since I switched from nvidia at the beginning of this year it never worked for me with fglrx even though fglrx seems to support the needed extensions for the effects to work
the output I got was:Originally Posted by Zarin
some more info on this issue:glxinfo | grep -iE '(GL_ARB_fragment_shader)|(GL_ARB_shading_language _100)|(string)|shad'
server glx vendor string: ATI
server glx version string: 1.4
client glx vendor string: ATI
client glx version string: 1.4
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 4800 Series
OpenGL version string: 2.1.8870
OpenGL shading language version string: 1.40
GL_AMDX_vertex_shader_tessellator, GL_AMD_draw_buffers_blend,
GL_AMD_vertex_shader_tessellator, GL_ARB_color_buffer_float,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_geometry_shader4, GL_ARB_half_float_pixel,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects,
GL_ARB_shader_texture_lod, GL_ARB_shading_language_100, GL_ARB_shadow,
GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader,
GL_ATI_fragment_shader, GL_ATI_meminfo, GL_ATI_separate_stencil,
GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters,
GL_EXT_gpu_shader4, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture,
http://forum.kde.org/viewtopic.php?f=111&t=63748
@bridgman:
could you please take a look at it ?
it more seems kind of an driver-problem of fglrx than a problem of kwin itself
many thanks in advance