[i945] totem overrides XV_CONSTRAST/XV_SATURATION to wrong default value (Xv movies on i810/i945 have horrible colour/gamma/contrast)

[Alan Tam]

Totem (in some Ubuntu versions only -gstreamer or -xine variants) overrides XV_CONTRAST/XV_SATURATION to wrong values, this causes viewing movies with accelerated XV Intel and I810 drivers (i855/i810/i945/etc video cards) have horrible (distorted) colors/gamma/contrast/brightness (in such case it's pretty hard to set correct color balance in totem's preferences, often you need to change not only contrast, but also saturation from standard values).

Most other media players (vlc, mplayer, gxine, etc) doesn't have this problem, AFAIK. Also this problem disappears by changing video output driver from XV to X11. Note: XV_CONTRAST/XV_SATURATION should be reseted to real defaults before running another media player, as in most cases totem changes XV_CONTRAST/XV_SATURATION for whole session, until you reboot.

In some Ubuntu versions (for example in Ubuntu 7.10 "Gutsy") this problem appears only with totem-xine, in other (e.g. 8.04 "Hardy") - only with totem-gstreamer, AFAIK problem is in both totem variants in older Ubuntu versions (e.g. 6.06 "Dapper").

Example of testcase (applies to Ubuntu 8.10 Hardy's driver, as well as Debian experimental, date 2008-04):

System:
Dell Inspiron 510m, 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
xserver-xorg-video-intel package version 2:2.2.1-1ubuntu12

Test case:
1. Install "xvattr" package
2. Reboot system, and get "base" settings for XV, i.e. "xvattr >xvattr.default"
3. Open a movie using a different movie player (totem-xine, totem-gstreamer, vlc, mplayer, gxine, etc), close it, then get a new reading via xvattr; e.g. after playing a movie in VLC: "xvattr >xvattr.vlc" (or during the play)
4. Compare files, e.g.: diff -u xvattr.default xvattr.vlc
5a. If there is a difference, you will need to reset xvattr to "default" settings before trying another movie player (this can be done by rebooting computer).
5b. If there is no difference, repeat step 3 & 4 with a different movie player.

Expected results:
No movie players change XV settings

Actual results:
Totem (only using the gstreamer backend) and SMplayer (this can be another bug) causes XV settings to change each time a movie is opened. No other movie player (including totem-xine and mplayer) causes this problem.

conn@inspiron:~/intelbug$ diff -u xvattr.default xvattr.totem-gstreamer
--- xvattr.default 2008-04-24 00:07:00.000000000 +0100
+++ xvattr.totem-gstreamer 2008-04-24 00:08:14.000000000 +0100
- Current value: 66046
+ Current value: 66051
   Name: XV_BRIGHTNESS
    Min value: -128, Max value: 127
- Current value: 0
+ Current value: -1
   Name: XV_CONTRAST
    Min value: 0, Max value: 255
- Current value: 64
+ Current value: 62
   Name: XV_SATURATION
    Min value: 0, Max value: 1023
- Current value: 128
+ Current value: 125
[..]

Test Case 2:

1. Get default settings from fresh startup, before launching any movie players, i.e. xvattr >xvattr.default
2. Repeatedly open a movie in totem-gstreamer, then close movie and record xvattr settings, i.e.

totem /usr/share/example-content/Experience\ ubuntu.ogg
xvattr >xvattr.1
totem /usr/share/example-content/Experience\ ubuntu.ogg
xvattr >xvattr.2
totem /usr/share/example-content/Experience\ ubuntu.ogg
xvattr >xvattr.3

3. Compare xvattr settings.

Conclusion: each time totem opens a new movie, it further changes the default movie settings (please see attachment).

See attached file "xvattr diff comparison from example in Test Case 2"

[Alan Tam (at)]

xorg.conf

[Paul Sladen (sladen)]

Hi Alan, can you post:

  lspci -n | grep 0000:00:0

I think the appropriate IDs were added after Flight 5 (so Flight 6 should have them).

Second part of the question; this Xv distortion has also been posted elsewhere. Seems to be related to the brightness/constrant setting being defaulted to an extreme value rather than in the centre. Can you adjust them under Xine or Mplayer?

[Alan Tam (at)]

sltam@beech:~$ lspci -n | grep 0000:00:0
0000:00:00.0 0600: 8086:2770 (rev 02)
0000:00:02.0 0300: 8086:2772 (rev 02)

I tried to vary the brightness and contract, but none of them looks right.

[Paul Sladen (sladen)]

Urge, looks very saturated.

Seems to be reverse 'solarised' (the low values are having their top bit set).

[Paul Sladen (sladen)]

This seems to be related to XV_GAMMA handling. There's a lack of documentation at what exactly the six registers do.

  $ sudo apt-get install xvattr

  $ xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08#x\n",$3}'
  XV_COLORKEY 0x0101fe
  XV_BRIGHTNESS 0xffffffffffffffff
  XV_CONTRAST 0x00007f
  XV_GAMMA0 0x00fe83
  XV_GAMMA1 0x00ff00
  XV_GAMMA2 0x00fe83
  XV_GAMMA3 0x00ff00
  XV_GAMMA4 0x00fe83
  XV_GAMMA5 0x00ff00

The Brightness and Constrast can be changed on-the-fly (while another program has the Xvideo port open) but the GAMMA values cannot. There's actually a comment saying that this is enforced:

  /* Avoid video anomalies, so set gamma registers when overlay is off */

Setting the gamma values with a command like:

  $ xvattr -a XV_GAMMA1 -v $((0x00ff00))

or:

  $ for G in XV_GAMMA{0,2,4} ; do xvattr -a $G -v $((0xff0000)) ; done

causes the display to go mostly RED, GREEN or BLUE. So it's clear that this is some sort of image/mask or multiple channel gamma ramp.

The values are initalised in a very mask-like way:

  ./src/i830_video.c: pPriv->gamma5 = 0xc0c0c0;
  ./src/i830_video.c: pPriv->gamma4 = 0x808080;
  ./src/i830_video.c: pPriv->gamma3 = 0x404040;
  ./src/i830_video.c: pPriv->gamma2 = 0x202020;
  ./src/i830_video.c: pPriv->gamma1 = 0x101010;
  ./src/i830_video.c: pPriv->gamma0 = 0x080808;

I do not understand the '0xc0' values since this covers two bits and the rest only cover 1 bit. It could be that these are a 6-step linear approximation to the desired gamma ramp. To support this there is various code like:

  pPriv->gamma0 = value;
  if (pPriv->gamma1 - pPriv->gamma0 > 0x7d)
    pPriv->gamma1 = pPriv->gamma0 + 0x7d;

However for a masked-value, "randomly" adding 0x7d in just the blue channel is tottally broken.

[Paul Sladen (sladen)]

xserver-xorg-driver-i810 (1:1.4.1.3-0ubuntu5) dapper; urgency=low

  * Attempt to fix Xvideo Gamma issues on i9xx [Malone: #32963].

Can people please see if this fixes it?

[Paul Sladen (sladen)]

It maybe possible to improve the colour aswell (rather than just letting the current defaults take care of it. Do either of the following combinations of parmeters improve the colours aswell?

(You need to install the 'xvattr' package (from universe) to be able to send these commands to the video driver):

xvattr -a XV_BRIGHTNESS -v 0
xvattr -a XV_CONTRAST -v 48
xvattr -a XV_GAMMA0 -v 0x000000
xvattr -a XV_GAMMA1 -v 0x101010
xvattr -a XV_GAMMA2 -v 0x202020
xvattr -a XV_GAMMA3 -v 0x404040
xvattr -a XV_GAMMA4 -v 0x808080
xvattr -a XV_GAMMA5 -v 0xffffff

xvattr -a XV_BRIGHTNESS -v 0
xvattr -a XV_CONTRAST -v 48
xvattr -a XV_GAMMA0 -v 0x070707
xvattr -a XV_GAMMA1 -v 0x0f0f0f
xvattr -a XV_GAMMA2 -v 0x1f1f1f
xvattr -a XV_GAMMA3 -v 0x3f3f3f
xvattr -a XV_GAMMA4 -v 0x7f7f7f
xvattr -a XV_GAMMA5 -v 0xfefefe

They are bascially RGB-triplets which appear to be on a curve with 1-bit per gamma-value, but /not quite/...

[Alan Tam (at)]

It appears to have fixed bug 42349, which was introuced more recent than this bug. But it still looks like the time when the bug was reported.

That is, if I tune Brightness to smallest (inside Totem), then the whiteness is somehow acceptable, though the color is still not as good as that by the gl/gl2/xshm drivers in mplayer/xine.

[Alan Tam (at)]

And, both sets of commands from Paul do not seem to correct the problem.

[Paul Sladen (sladen)]

AlanTam: Okay, I think I've worked out why the commands aren't working for you. You need to start a movie playing (eg. in Totem). Then bring up eg. Gnome Terminal and paste those commands (*while the movie is already loaded*).

The values are getting "reset" to the horrible looking ones each time the Xv port is initialised.

Can you try that again please if you get a chance?

[Alan Tam (at)]

Both works now. I cannot distinguish which is better.

[Paul Sladen (sladen)]

Excellent news. I'll whip up a patch.

[Paul Sladen (sladen)]

xserver-xorg-driver-i810 (1:1.4.1.3-0ubuntu6) dapper; urgency=low

  * Adjust the default Xvideo Gamma levels [Malone: #32963].

This seems to be looking consistently good for me now! Please reopen if you're still seeing a problem with the latest dapper packages (make sure you have the above one).

[Alan Tam (at)]

I've installed 1.4.1.3-0ubuntu6 and rebooted. It still persists.

[Gert Kulyk (gkulyk)]

I can confirm this. 1.4.1.3-0ubuntu6 does not fix the bug.

[Paul Sladen (sladen)]

Okay, I'm now in a situation where I can't replicate this bug. Can you both paste:

  $ xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08#x\n",$3}'

from after a cold start of the machine.

[Alan Tam (at)]

I suppose you typed an extra "#" there.

sltam@beech:~$ xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08x\n",$3}'
XV_COLORKEY 000101fe
XV_BRIGHTNESS fffffffb
XV_CONTRAST 00000030
XV_GAMMA0 00000000
XV_GAMMA1 00101010
XV_GAMMA2 00202020
XV_GAMMA3 00404040
XV_GAMMA4 00808080
XV_GAMMA5 00ffffff

[Julien Olivier (julo)]

julien@lifebook ~ $ xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08#x\n",$3}'
XV_COLORKEY 0x0101fe
XV_BRIGHTNESS 0xfffffffffffffffb
XV_CONTRAST 0x000030

[Paul Sladen (sladen)]

Okay, those numbers are pretty much correct (or at least *appear* to be what they should be). Can you try doing things (playing videos etc) to try an get them to change?

The Brightness is -5, Contrast is 48.

Can you include the version of 'totem' you are using (-gstreamer or -xine):

  dpkg -l | awk '/totem-/{print$1,$2m$3}'

(The '#' in the format string means to convert the number in to the "alternate form", for hexadecimal numbers this starts the number with an '0x'. See 'man 3 printf' for more information).

[Paul Sladen (sladen)]

julien: you missed out your GAMMA results---the patch attempts to fix these aswell.

[Alan Tam (at)]

The same values are shown even when totem is playing. When I slide contrast to the left, the video seems to become ok. But I expect it to work when the contrast is in the middle.

Adding "#" does not work:
sltam@beech:~$ xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08#x\n",$3}'
awk: run time error: improper conversion(number 1) in printf(" %08#x
")
        FILENAME="-" FNR=9 NR=9

sltam@beech:~$ dpkg -l | awk '/totem-/{print$1,$2m$3}'
ii libtotem-plparser11.4.1-0ubuntu3
rc totem-gstreamer1.3.91-0ubuntu2
ii totem-xine1.4.1-0ubuntu3

The same happens even if I replace totem-xine by totem-gstreamer.

[Paul Sladen (sladen)]

Alan: the contrast needs to be at 25%, or thereabouts.

If all you need to do is to change the contrast level to get it to look right, please can you post me the hex value that you think works best afterwards.

I'll consider doing a change to the X server so that the best default constrast is moved to the centre of the range.

[Alan Tam (at)]

It looks nice when XV_CONTRAST is around 55-70 (out of 255).

[Conn O Griofa (psyke83)]

In fact, it XV_CONTRAST is "normal" at 64 (I've been experiencing this bug too).

[Julien Olivier (julo)]

Here's what I get just after starting a movie in Totem-gstreamer:

julien@lifebook ~ $ xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08#x\n",$3}'
XV_COLORKEY 0x010203
XV_BRIGHTNESS 00000000
XV_CONTRAST 0x00007e

For info:
julien@lifebook ~ $ dpkg -l | awk '/totem-/{print$1,$2m$3}'
ii libtotem-plparser11.4.1-0ubuntu3
ii totem-gstreamer1.4.1-0ubuntu3
ii totem-gstreamer-firefox-plugin1.4.1-0ubuntu3

[Gert Kulyk (gkulyk)]

Here the results for my hpnx6110:

xvattr | awk '/ Name/{printf$2}/Current/{printf"\t%08#x\n",$3}'

XV_COLORKEY 0x0101fe
XV_BRIGHTNESS 0xfffffffffffffffb
XV_CONTRAST 0x000030
XV_GAMMA0 00000000
XV_GAMMA1 0x101010
XV_GAMMA2 0x202020
XV_GAMMA3 0x404040
XV_GAMMA4 0x808080
XV_GAMMA5 0xffffff

using:
ii libtotem-plparser11.4.1-0ubuntu3
ii totem-xine1.4.1-0ubuntu3
ii totem-xine-firefox-plugin1.4.1-0ubuntu3

Playing a Video in totem, manual contrast-setting:

xvattr | awk (etc.)

...
XV_CONTRAST 00000039
...

[Alan Tam (at)]

Will you upload to dapper a new default constrast?

[Paul Sladen (sladen)]

We went into deep-freeze; I'll try and get this into dapper-updates.

[Carlos (carlos-james-r)]

I just want to add that I too am experiencing the above problem with xv in dapper. I have a "Intel Corporation Mobile 915GM/GMS/910GM L Express Graphics Controller" as given by lspci. I am using the defauly i810 driver in my xorg.conf.

The problem first appeared when I upgrade to dapper yesterday (2006/06/04). Using mplayer with -vo xv option the contrast and the brightness of the video are incorrect. This problem also appears in totem (i believe it is also using the xv option). With mplayer, this problem goes away if I using -vo gl or -vo gl2. This problem also goes away (or at least this might just be covering it up) when I set the contrast in totem to about 25%, this fixs it for both totem and mplayer and remains fixed even after restart. Changing the contrast in the above method does not fix the problem all the way though, the values of the contrast and brightness appear they still need tweaking, which I might do latter if I have time.

[Jeffrey Knockel (jeff250)]

Ditto Carlos (the post above).

[muhkayoh (matt-mattjordan)]

I'm new to Ubuntu and Linux and not sure what card I have, but I also have the problem described in this report.

[muhkayoh (matt-mattjordan)]

After some help, I now have this info about my video card:

0000:00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

One of my main uses for my computer is producing cartoon animation, so I'd really like to get this color issue figured out. I tried the xvattr fixes listed above and saw some improvement - videos are at least watchable now. But the color still isn't really right.

If/when this bug is fixed (if it is a bug and I'm in the right place) how will I learn what to do to apply the fix to my computer? Is this one of those things that will automatically update?

Thanks for any help.

Matt Jordan

[Alan Tam (at)]

matt,

Now that half of the bug is fixed. You don't need xvattr. Just tune the contrast (Edit -> Preferences -> Display) into 25% and it will look right.

[Daniel Lombraña González (teleyinex)]

With Dapper stable release I have the same problem. I can't watch movies with normal colors in mplayer totem or xine. I think this haven't been fixed yet.

[Carlos (carlos-james-r)]

Alan,

Like I said in my post above, changing the contrast to 25% makes it look better, but it is still not completely "right." The brightness and contrast still look like they could use tweaking.

[Philipp Ehses (ehses-deactivatedaccount)]

Same problem here. Sometimes the contrast is fine, tough.

I have an Intel 910 GM chipset, btw.

[wildutah (wildutah)]

Now that I know this is a contrast setting problem, I can adjust it. It's not good but I'll do okay.

But there are lots of people with computers like my Dell Inspiron 6400 with the default Intel controller. This really needs to be fixed. Badly.

The best setting for contrast seems to be about 0x40.

-----lspci:
0000:00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 03)
        Subsystem: Dell: Unknown device 01bd
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] #09 [5109]

0000:00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: Dell: Unknown device 01bd
        Flags: bus master, fast devsel, latency 0, IRQ 169
        Memory at dff00000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at eff8 [size=8]
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Memory at dfec0000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 2

0000:00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03)
        Subsystem: Dell: Unknown device 01bd
        Flags: bus master, fast devsel, latency 0
        Memory at dff80000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 2

[muhkayoh (matt-mattjordan)]

I'm just checking back in to ask if there's any sort of ETA on a total fix for this bug. I followed Alan Tam's helpful reply to me above and, like others here, I can live with the result as far as simply watching a video. However, I'm learning to use Cinelerra to edit video and the colors really aren't working for that.

So is there an ETA on a total fix? Will there be a total fix? And if there is one, will it update Ubuntu automatically, or will I have to fetch/apply the fix (and if so, how will I know when and what to do)?

Sorry to ask so many questions and I hope I don't seem demanding or rude, but I really want to get this sorted out so that I can get on with learning to edit video.

Thanks,

Matt Jordan

[Sebastien Bacher (seb128)]

Fixing bugs often require people having the issue working on it so it might take some time. If once fixed the fix is easy enough it can be backported

[muhkayoh (matt-mattjordan)]

"If once fixed the fix is easy enough it can be backported"

Thanks for the reply and forgive my ignorance, but will that happen automatically via the update function, or will I have to do it manually? And if the latter, how will I know when the fix is available, where to get it, etc.?

Thanks again,

Matt Jordan

[Sebastien Bacher (seb128)]

If you have the dapper-updates source activated (which should be the default) those fixes come with the updates from it and you should just have to click on the "update available"

[Paul Sladen (sladen)]

Matt: as it happens, about 1 hour ago I had a update about getting some information directly from Intel, so I'm hoping I should be able to deal with this bug in a more complete way when the low-level documentation arrives, and hoping nail this one shut properly :)

[Jeff Johnson (jeff-comfrey)]

disabling dri in xorg.conf seems to do the trick for me. dont know if it is a real fix or just intermittent.

got the idea from
https://bugs.freedesktop.org/show_bug.cgi?id=6933

[Jeff Johnson (jeff-comfrey)]

ok, not the fix. after a while the color distortion came back

eagerly awaiting more info/fix.

[Daniel Lombraña González (teleyinex)]

I have tried what Jeff Johnson said, but no works here too. You have let me hope it could be a fix ;)

The "fix" that I am using is use vesa instead of i810.

[Eduardo Cárdenas-Trejo (edcartre)]

I'm having the same problem here (Ubuntu Dapper Drake stable) on Intel 945G. The problem only appears when I close Totem and open it again (too few colors / wrong colors) and disappears when I restart X.

Moving the contrast slider doesn't fix the problem.

Thanks!

[Lukas Kolbe (lucky)]

Same problem here, with a i855gm:

0000:00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
0000:00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

Both of the different xvattr-settings from Paul Sladen above fix the bad image quality while playing.

[hellmet (vsanju85)]

hmm...all this while I ws thinkin I was the only one with this problem!!
Well,I've got company...
Hope to get this fixed soon!!

See the snapshot ppl!!

http://img154.imageshack.us/img154/8647/dsc000333lj.jpg

[hellmet (vsanju85)]

well for me...after lotsa experimenting..
I found out tht all i needed to do was

xvattr -a XV_GAMMA5 -v 0xbbbbbb

this did the trick..
But I have a doubt..each time I start Totem,the values get reset.
How do I make them permanent??
Any Ideas??

[Daniel Lombraña González (teleyinex)]

This doesn't work for me. I get this error:
Found Xv 2.2
X Error of failed request: BadMatch (invalid parameter attributes)
  Major opcode of failed request: 141 (XVideo)
  Minor opcode of failed request: 13 ()
  Serial number of failed request: 11
  Current serial number in output stream: 12

Cya!

[Paul Sladen (sladen)]

On Fri, 7 Jul 2006, Daniel Lombraña wrote:
> X Error of failed request: BadMatch (invalid parameter attributes)

Daniel: what version of the chip to do you have? (eg. i845). The individual
gamma attributes are only available on i9xx.

[Daniel Lombraña González (teleyinex)]

This is my video card: Intel Corporation 82852/855GM Integrated Graphics Device.

So I can't fix it with that solution :(

Thanks!

[Paul Sladen (sladen)]

Daniel: interesting. So you're still getting ugly video even though those
registers don't even come into the equation. Can you move any of the slides
in Totem to improve the situation?

[Daniel Lombraña González (teleyinex)]

I have moved it to all positions and always the same horror color. All the colors are very red. If I use opengl in totem or in mplayer I can see the movies in the right way, but with Xv very bad.

[hellmet (vsanju85)]

did u try the values..when the movie window was minimized??
else it won't work..
btw I also tried gxvattr....the graphical version of xvattr..

same problem..now values get reset on reboot..

paul ..any ideas as to what i can do to make the changes
permanent??Like executing a command whenever Xv is initialised
anywhere???

[seanh (seanh)]

Okay, a friend of mine has this problem on a Dell Inspiron laptop running Dapper, with totem-xine. If I remember rightly, the same problem was appearing with MPlayer as well. We didn't try xine-ui. She did not have the problem on the same laptop with Breezy, when she was using xine-ui.

Turning down the brightness and contrast in Totem can alleviate the problem somewhat, but can't seem to get it quite right. It feels as if there is an extra setting, maybe gamma or something, that is mis-set, and Totem doesn't provide access to it.

The problem she has looks very similar to the one in the screenshot on the following bug report:

https://launchpad.net/distros/ubuntu/+bug/47566

the author of which believes it to be a duplicate of this bug.

I don't have access to this Dell laptop right now, but can get to it on Sunday or Monday. I'll add the backports and updates repositories and download all the latest updates and see if the problem still occurs. If it does, I'll post lshw and xorg.conf for the laptop here.

I would like to know what else I can post that will be most useful for getting this bug fixed. If you can ask me for something before Sunday then I'll post it, but I'm only going to have a short window of access to the laptop.

My friend would really like to have this fixed, as she basically uses her laptop to watch movies.

[taj (othertaj)]

The same happens to me.
I have an Intel 915 GM chipset.

[Iain Murray (ubuntu-iainmurray)]

I have similar washed out videos under some circumstances with an "Intel Corporation 82852/855GM Integrated Graphics Device" using the i810 driver. This is a Dell Inspiron 710m. I'm running 6.06 LTS originally installed from an official CD with whatever updates apt offered me.

My impression is that it is a totem-xine and gxine bug.

If I watch movies with xine (from the xine-ui package) or mplayer after an X restart then everything is fine. xvattr information (given later) is not changed by running xine or mplayer.

Movies under totem (totem-xine) are washed out. The values reported by xvattr change, but are reset after closing totem. Moves subsequently play ok in xine or mplayer. Totem can also play movies fine if xvattr values are fixed after starting totem.

Movies under gxine are washed out, xvattr values are changed (although not to same values as by totem) and stay changed. Movies in xine or mplayer are washed out until an X restart or xvattr stuff changed back by hand. Again gxine plays fine if fix xvattr values by hand while gxine running.

I get the following xvattr output after X restart: and stays the same after running xine(-ui) or totem(-xine):
% xvattr
Found Xv 2.2
Adaptor: 0
Name: Intel(R) Video Overlay
 Port: 73
  Name: XV_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 66046
  Name: XV_BRIGHTNESS
   Flags: XvGettable XvSettable
   Min value: -128
   Max value: 127
   Current value: -5
  Name: XV_CONTRAST
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 255
   Current value: 48

The values are reset after closing totem, but while it is running I get:
% xvattr
Found Xv 2.2
Adaptor: 0
Name: Intel(R) Video Overlay
 Port: 73
  Name: XV_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 66046
  Name: XV_BRIGHTNESS
   Flags: XvGettable XvSettable
   Min value: -128
   Max value: 127
   Current value: -1
  Name: XV_CONTRAST
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 255
   Current value: 127

After running (and closing) gxine I get:
% xvattr
Found Xv 2.2
Adaptor: 0
Name: Intel(R) Video Overlay
 Port: 73
  Name: XV_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 66046
  Name: XV_BRIGHTNESS
   Flags: XvGettable XvSettable
   Min value: -128
   Max value: 127
   Current value: 0
  Name: XV_CONTRAST
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 255
   Current value: 128

I've been fixing color washouts by running:
    xvattr -a XV_CONTRAST -v 48 ; xvattr -a XV_BRIGHTNESS -v -5

Why (with the default settings, which I haven't touched) don't totem/gxine just leave the xvattr settings alone?

[Iain Murray (ubuntu-iainmurray)]

I've also tried totem-gstreamer, which also exhibits the bug as above.

[FrogPR (p-roediger)]

Hi all,

I had the same problems as mentioned here. On second time playing a movie using xv in xine or any other xine-based app, the colors would be totally distorted. Only restarting X would "resolve" the problem. On the other hand, when playing movies in mplayer, the colors seemed to be washed out and too bright. Anyway, I was able to solve the problem by installing the latest xorg i810 drivers (which were actually released today). They can be found here:

http://www.t2-project.org/packages/xf86-video-i810.html

Compile and install them, restart X and everything works fine. I also noticed that my screensaver (in KDE) is working now, it did not work with the old i810 driver.

Please note that "make install" installs the driver to /usr/local/lib/xorg/modules/drivers, while the modules (at least on my debian) are located in /usr/lib/xorg/modules/drivers. Back-up the original i810_drv.so and then replace it by the shiny new one (X might crash, thus doing this from a text console would be the safe way out)

Happy kaffeine-ing

[peter_weber69 (peter-weber69)]

hi,

i have the same problem and an workaround for ubuntu dapper, but isn't fine.

apt-get install xserver-xorg-driver-i810=1:1.4.1.3-0ubuntu6
then restart (X), Ctrl+Alt+BS

this version works fine.
the new version in dapper (1:1.5.0.1-0ubuntu2) is buggy
i hope someone find a better way

bye
Horst

[peter_weber69 (peter-weber69)]

and the workaround for
debian sid or kanotix

add to your sources.list

# Experimental
deb http://ftp.de.debian.org/debian experimental main contrib non-free
deb-src http://ftp.de.debian.org/debian experimental main contrib non-free

apt-get install xserver-xorg-video-i810/experimental xserver-xorg-core/experimental

this will install the version
xserver-xorg-video-i810 1.6.3-1
xserver-xorg-core 1.1.1-1
which work's too

[peter_weber69 (peter-weber69)]

hi,

so i think,

xf86-video-i810 Version 1.4.1 and 1.6.3 works,
1.5.0 doesn't

[Peter Soetens (peter-soetens)]

Intel has released the free software 2D/3D drivers for this chipset. See <http://intellinuxgraphics.org/>

Note: " While these drivers represent significant work at both Tungsten Graphics and Intel—as our first release of this code—they're still in need of significant testing, tuning, and bug fixing before they will be ready for production use. We're releasing them now to demonstrate our ongoing commitment to providing free software drivers for Intel hardware."

[crendon (crendonk)]

I have the same problem... my hardware is a desktop IBM Netvista 6290-14J and it cames with an Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (Driver i810 1.4.xx). My Flat screen is a Hyvision MV141 14" (http://www.megavisionsys.com/products2_specs.asp?model=MV141)

I had a refresh rate problem that I solved adding this line to my xorg.conf ("monitor" section):

# V-freq: 60.00 Hz // h-freq: 47.80 KHz
Modeline "1024x768" 60.80 1024 1056 1128 1272 768 768 770 796

But now I have this problem when I play videos... they look too much bright. My xvattr shows this:

Found Xv 2.2
Adaptor: 0
Name: Intel(R) Video Overlay
 Port: 73
  Name: XV_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 66046
  Name: XV_BRIGHTNESS
   Flags: XvGettable XvSettable
   Min value: -128
   Max value: 127
   Current value: -1
  Name: XV_CONTRAST
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 255
   Current value: 127

When I open gxvattr and set up my HV_CONTRAST to 55 it seems to fix the problem but soon after I open any other video player (vlc, totem, mplayer,gxine or firefox with totem-xine-firefox-plugin) the problem came back (HV_CONTRAST reset to 127).

I am following this bug report and I would like to know if anyone found the permanent solution. (I want to make sure that xserver-xorg-video-i810 1.6.3-1 wont break my system).

Sorry for my bad english I am not native speaker.

C.Rendon

[Conn O Griofa (psyke83)]

Hi,

This is a bug with a combination of the xserver-xorg-i810 driver and totem (-xine and -gstreamer backends). I'll attach two logs to illustrate:

1. xvattr_boot.log - xvattr output after a fresh reboot
2. xvattr_gstreamer.log - xvattr output after playing a movie in totem (-gstreamer). Note that using the totem-xine causes the same difference as in this log.

A "fix" is to run "xvattr -a XV_COLORKEY -v 66046;xvattr -a XV_CONTRAST -v 64" *during* movie playback in totem to restore the proper defaults and give a good quality picture. Setting it beforehand won't work, and running totem again will reset the values back to bad non-default values.

I have two separate systems running Edgy (although I've had this same problem with Dapper too), both with Intel chipsets (865G and 945G). On the latter system I use DVI input, but I tested analog and it's the same, so it's a software issue.

I installed an NVIDIA card in my older system, and never experience such a bug, nor have I seen any problems with my old Inspiron 8000 laptop with a Mobility M4 (ati/r128) chipset.

Why am I sure it's totem's fault? Do a fresh reboot and immediately play a movie in vlc (using Xvideo output) or "mplayer -vo xv" and you'll see that the xvattr variables are untouched - and picture quality is fine; only totem seems to change these values once started and thus create problems with picture quality (until proper defaults are re-set).

[Conn O Griofa (psyke83)]

A little followup: using totem's preferences to manually set the contrast slider to 64 (using xvattr -a XV_CONTRAST in a terminal to monitor exactly when it reaches 64), totem saves and remembers the setting each time it's subsequently run. So it may be a problem with totem's internal contrast handling that's to blame. So a "fix" is to manually set the contrast slider to 64, but there's still a bug somewhere that should be fixed to avoid this headache for others.

[Jonas Jørgensen (jonasj)]

I have seen this bug on two laptops. On at least one of them (a ThinkPad T60 with an Intel GMA950), I see this bug with totem-xine and gxine, but not totem-gstreamer, vlc or mplayer. Two interesting things:

* If I have VLC playing a video when I open a video in totem-xine, that instance of totem-xine does not show the bug. Closing both players and then opening the video in totem-xine again makes the bug reappear.

* Once I've played a video with gxine, it seems to "infect" the other players (or at least vlc), which then also shows this bug until I log out.

Definitely seems xine-related to me. Has anyone seen this bug on a system which uses totem-gstreamer and never had xine installed?

[kapetanski (klangwerkstadt)]

I also have this bug, spec - amilo pro v2000 with intel 855gm, running xubuntu edgy.

Conn: How do you mean I can use "xvattr -a XV_CONTRAST" to monitor the value used by totem?

I think this bug is quite annoying, as vlc doesn't work on my external display in fullscreen mode using xinerama.

[kapetanski (klangwerkstadt)]

Ok, sorry Conn, now I understand how to use that command.

[FuturePast (4uturepast)]

Problem seen here too.

Dell Latitude D620
VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

[loko (arph)]

Conn,

it is not only totem that is the problem. the color-problem also appears in xine and kaffeine, mplayer, vlc and every other player i've tested. it seems not be a totem-only problem.

[Saint Germain (saintger)]

Hello,

With Edgy, I have a similar problem here : after using gxine, pictures are washed-out.

I have an Intel 82815 Chipset Graphics Controller (rev 02) (note that I had to use 16 bit colors in order to have DRI).

But I also have an extra one : when using mplayer with -vo xv, I got a weird image distortion (like ghost images at 45 degrees).
If I use -vo x11 or -vo gl2, picture is OK (but slooooow).

Funny thing is that if I try to take a snapshot directly (-vf snapshot) the picture is OK.

Fortunately using VLC is perfect, but I'd rather use mplayer.

Feel free to ask any additional information.

Regards,

P.S. : How am I supposed to take a snapshot with mplayer and -vo xv ? Each time I try to use 'print screent' or capture with Gimp, I got a blue screen...

[Lionel Dricot (ploum-deactivatedaccount)]

I also have this bug under stable dapper and Edgy.

What is interesting to me is the following :

1) Totem-gstreamer, xine, mplayer and vlc work perfectly. Not bug at all !

2) Install totem-xine. Play a video. It shows you the bug

3) uninstall totem-xine and put totem-gstreamer again : totem-gstreamer, mplayer and vlc are all infected ! Funny thing is that xine-ui is still working normaly !

4) I hope it will be solved at my next reboot

[Lionel Dricot (ploum-deactivatedaccount)]

it doesn't work after a reboot ! So, installing totem-xine and playing a video with it has broken the system in a permanent way !

This seems a pretty huge bug of totem-xine to me...

[Erich Schubert (erich)]

Lionel:
Did you try poweroff, or just a "warm" reboot?
Maybe the gamma settings aren't reinitalized on a warm reboot. I'd doubt that totem-xine would be able to break your system permanently.

[Lionel Dricot (ploum-deactivatedaccount)]

erich > my computer was off for a whole night so I assume I could consider it as a cold boot ;-)

[Pat_Primate (patprimate)]

This problem persists in Kubuntu Feisty Fawn Herd 5. Using the included xserver-xorg-video-i810 driver (version 1.7.4-1). Xine video driver auto/xv will play the washed out video (horrible color/Gamma) and I still have to manually change the video driver to Xshm to view video properly.

Hopefully this will be fixed for Feisty Fawn Final :)

Take Care,

Pat

[Saint Germain (saintger)]

Can someone confirm that they also have a weird image distortion with mplayer when playing DivX 5.0 movies ?

I have an Intel 82815 Chipset Graphics Controller (rev 02) and without first using Xine or Totem, I always got a ghost red/green image at 45 degrees with mplayer.

I have confirmed this on Debian Etch/Testing and with the latest svn-compiled mplayer.

Using VLC I don't have any problem at all, so I'm not sure if the problem lies in the i810 driver or in mplayer.

The folks at mplayer mailing list told me that if the snapshots (with mplayer -vf screenshot) are correct (and they are) then the problem probably lies in i810 driver...

Thanks,

[Timo Aaltonen (tjaalton)]

Closing bogus component.

[Paul Sladen (sladen)]

Fixed in Feisty.

[Conn O Griofa (psyke83)]

Paul,

Unless the fix has yet to land in the repositories, it's not fixed in Feisty. It's a bug in totem's GUI, I think.

Again, my system: Dell Inspiron 510m, Intel 855GM, running Feisty with everything up-to-date.

Steps to reproduce:
1. Open a video in totem (gstreamer), then go to Edit, Preferences, Display, click "Reset to defaults" and close Preferences window. Notice the colours are all washed out.
2. Keep the same movie playing, and in a terminal invoke "xvattr -a XV_CONTRAST -v 64". The video's colours will look normal.
3. Close totem, and open the same video with vlc (making sure it uses xv output, as default). The colours should still look good.
4. Close vlc, and once again open the video with totem. Colours are bad again!
5. Close totem, and open the video with vlc. The colours are still bad.

The problem is with totem's GUI. Totem thinks that XV_CONTRAST should default to 126, and resets it every time the application starts, ignoring the system setting (as opposed to apps such as vlc, that respect the setting). The only solution is to manually adjust the contrast slider in totem's GUI until it's at 64 (which can be verified precisely with xvattr as you adjust).

The bug is still present, and it needs to be fixed either in totem's GUI, or via a change to the i810's contrast values. In other words, XV_CONTRAST=126 is the default, but it needs to be around 64.

[Paul Sladen (sladen)]

Excellent summary Conn. Thanks for that. Could you 'apt-get source' both the packages for totem and for a known-working program (vlc?), then locate the appropriate place/file in each so that we can compare the broken code to the good.

Doing a:

  grep -r XV_CONTRAST

in the source tree maybe enough to find the place where it is set/queried.

[Conn O Griofa (psyke83)]

Paul,

Here's the output from the source packages:

conn@dimension:~/work$ grep -r XV_CONTRAST vlc-0.8.6.release/
vlc-0.8.6.release/modules/video_output/x11/xvideo.c: * XV_CONTRAST.
"f_value" should be in the range of 0 to 1.
vlc-0.8.6.release/modules/video_output/x11/xcommon.c: XVideoSetAttribute(
p_vout, "XV_CONTRAST", 0.5 );

conn@dimension:~/work$ grep -r XV_CONTRAST totem-2.18.0/

conn@dimension:~/work$ grep -r XV_CONTRAST xserver-xorg-video-i810-1.7.4/
xserver-xorg-video-i810-1.7.4/src/xvmc/I810XvMC.c: pI810XvMC->xv_contrast =
XInternAtom(display,"XV_CONTRAST",0);
xserver-xorg-video-i810-1.7.4/src/xvmc/I810XvMC.c: {XvGettable |
XvSettable, 0, 0x1ff, "XV_CONTRAST"},
xserver-xorg-video-i810-1.7.4/src/xvmc/I810XvMC.c:// XV_CONTRAST
xserver-xorg-video-i810-1.7.4/src/xvmc/I810XvMC.c:// XV_CONTRAST
xserver-xorg-video-i810-1.7.4/src/xvmc/I810XvMC.c:// XV_CONTRAST
xserver-xorg-video-i810-1.7.4/src/i810_video.c: {XvSettable | XvGettable,
0, 255, "XV_CONTRAST"}
xserver-xorg-video-i810-1.7.4/src/i810_video.c: xvContrast =
MAKE_ATOM("XV_CONTRAST");
xserver-xorg-video-i810-1.7.4/src/i830_video.c: {XvSettable | XvGettable,
0, 255, "XV_CONTRAST"},
xserver-xorg-video-i810-1.7.4/src/i830_video.c: {XvSettable | XvGettable,
0, 255, "XV_CONTRAST"},
xserver-xorg-video-i810-1.7.4/src/i830_video.c: xvContrast =
MAKE_ATOM("XV_CONTRAST");

Strangely, totem doesn't refer to XV_CONTRAST at all. But...

conn@dimension:~/work$ grep -r CONTRAST totem-2.18.0/
totem-2.18.0/po/rw.po:# sw/source\ui\utlui\attrdesc.src:STR_CONTRAST.text
totem-2.18.0/src/backend/bacon-video-widget-gst-0.10.c: else if
(type == BVW_VIDEO_CONTRAST && channel &&
totem-2.18.0/src/backend/bacon-video-widget-gst-0.10.c:
g_strrstr (channel->label, "CONTRAST"))
totem-2.18.0/src/backend/bacon-video-widget-gst-0.10.c: else if
(type == BVW_VIDEO_CONTRAST && channel &&
totem-2.18.0/src/backend/bacon-video-widget-gst-0.10.c:
g_strrstr (channel->label, "CONTRAST"))
totem-2.18.0/src/backend/bacon-video-widget-xine.c:
XINE_PARAM_VO_CONTRAST,
totem-2.18.0/src/backend/bacon-video-widget.h: BVW_VIDEO_CONTRAST,
totem-2.18.0/src/totem-preferences.c: BVW_VIDEO_CONTRAST,
(int) i);
totem-2.18.0/src/totem-preferences.c: BVW_VIDEO_CONTRAST);

There's a few possibilities we can look into: a) totem-preferences.c, or b)
changing the i810 driver's contrast handling.

On 3/22/07, Paul Sladen <email address hidden> wrote:
>
> Excellent summary Conn. Thanks for that. Could you 'apt-get source'
> both the packages for totem and for a known-working program (vlc?), then
> locate the appropriate place/file in each so that we can compare the
> broken code to the good.
>
> Doing a:
>
> grep -r XV_CONTRAST
>
> in the source tree maybe enough to find the place where it is
> set/queried.
>
> ** Changed in: xserver-xorg-video-i810 (Ubuntu)
> Status: Fix Released => Rejected
>
> ** Changed in: xorg (Ubuntu)
> Sourcepackagename: xorg => totem
> Status: Rejected => Confirmed
>
> --
> Xv movies on 810/i945 gives horrible color, Gamma
> https://launchpad.net/bugs/32963
>

[Lionel Dricot (ploum-deactivatedaccount)]

The bug is fixed for me in Feisty. It wasn't a few days ago. So I suppose that a fix have been released. If I'm not alone, the bug can be marked as fixed

[Conn O Griofa (psyke83)]

Lionel,

Well, the bug is still present on my systems. Check this comment: https://launchpad.net/ubuntu/+source/xserver-xorg-video-i810/+bug/32963/comments/84

Try resetting totem's defaults as explained in that comment, you may have inadvertently changed the contrast to a non-default value, *or* this bug is only fixed for a subset of the Intel chipsets (I'm using 855GM and 865G on my systems).

[Lionel Dricot (ploum-deactivatedaccount)]

Conn > I confirm that the bug is fixed on my system because, even when changing parameters, there were resetted to the bad default each times totem was started. It's not the case anymore.

But I don't have the same hardware : Intel Corporation Mobile 945GM/GMS/940GML

So it seems that the bug is fixed only for 9xx and not 8xx

[FuturePast (4uturepast)]

This is still a bug for me.

Feisty; Intel Corporation Mobile 945GM/GMS/940GML Express.

Only change is that mplayer and gxine are no longer affected,
but totem with totem-xine is still too bright.

[Lionel Dricot (ploum-deactivatedaccount)]

That's the difference > I'm using Totem-gstreamer which was affected but which isn't anymore. No more problem with VLC, mplayer and gstreamer.

[Conn O Griofa (psyke83)]

FuturePast,

Can you check that you're definitely using XV output in gxine and mplayer? Other outputs such as X11, OpenGL, etc. shouldn't have this problem. What about totem-gstreamer, can you see if it's still too bright with that?

Lionel,

Can you check that totem's gstreamer backend is using XV? Compare the output of testing gstreamer-properties' video with and without XV. The problem clearly remains for me when switching between the outputs (XV is too bright, X11 is fine).

Additionally, can someone please verify my steps in comment 84, and check if the same behaviour is experienced? https://launchpad.net/ubuntu/+source/xserver-xorg-video-i810/+bug/32963/comments/84

[Conn O Griofa (psyke83)]

I'm convinced this isn't a gstreamer issue at all, but rather a bug or "feature" in totem's GUI that resets a bad default XV_CONTRAST setting in its interface for Intel chipsets. This could be fixed in totem or in xserver-xorg-video-i810, being in the latter if XV_CONTRAST is given a default value that's non-standard compared to every other driver (which is feasible, given that no other chipsets aside from Intel's appear to suffer from this bug).

I installed totem-xine and followed my own instructions again as listed in comment 84, and the same behaviour is noted. It's definitely due to totem's GUI and/or the Intel driver, specifically with XV_CONTRAST handling.

To complicate matters even further, the bug may be fixed for 9xx chipsets if Lionel's reports are accurate, but not on older chipsets.

[Lionel Dricot (ploum-deactivatedaccount)]

Conn > I was experiencing exactly what you described in comment 84. But I confirm that now, it works ! (with totem-gstreamer). In fact, now matter how hard I try, I cannot reproduce this bug at all ! (maybe with totem-xine ?)

FuturePast > can you try what is described in comment 84 ? (with xv_attr).

I think that the "parameter is set to a bad default" is fixed now in totem but that bad default is not set to a sane value if it was already broken by previous version of totem.

[Conn O Griofa (psyke83)]

Lionel,

I deleted ~/.gnome2/totem*, and as for gconf, I don't know how to safely reset totem's defaults. Anyway, what does "gconftool -g /apps/totem/contrast" show for you? When I reset to defaults, it's 32767 here.

It may be due to a) it's not fixed on 8xx chipsets, or b) You're not running Feisty, so our environments are different.

[Lionel Dricot (ploum-deactivatedaccount)]

Conn > 32767 for me too. I'm running latest Feisty.

I think I've also played with gxvattr but resetted all to default. (I was unable to save anything because the window doesn't fit on my laptop screen)

[Oscaer (odres)]

I have the same problem with Mandriva one 2007 and Realplayer, Video first looks fine in VLC, then after installing realplayer this Program sets the default XV_CONTRAST in xvattr to 127 with is roughly 50 %. I guess this would be rather normal for most videocard, apparently this card (i810) can't handle this thus the default value is 64. Why can a user program like Realplayer change the default system values of the videocard ? It took me some time to solve this problem, had to restart first all the time to fix this now use manually xvattr

[Stani (stani)]

I also have this problem with the i810 driver (thinkpad X30).

[theluddite (matt-aggus)]

Similar problem here, but mine's definitely driver related. Mplayer worked fine when I first installed Ubuntu, but after installing my graphics driver, the colours in MPlayer and Xine are messed-up. Changing the hue to about 25% helps, but it's still not right. I've got Feisty Fawn on an Intel Duo Core with an ATI Radeon X1300Pro video card. I got the gfx driver from the ATI site. Any suggestions would be appreciated, but you'll have to be crystal clear, I'm a new to Linux.

[isayhelloyousaygoodbye (ihiubye)]

6.10 upgraded to Feisty (up to date) on a machine with gm855 chipset did not show any problems at first, but after installing several codecs (multiverse, medibuntu) the problem occured.

My findings:
VLC, gxine and totem-gstreamer do not cause the problem, and they're not affected
totem-xine causes the problem, and is affected
kaffeine (uses xine, medibuntu package) causes the problem

Affected meaning that a previous program showed the effect, and now the current player shows the symptoms.

So possibly xine-related?

[Henrik Nilsen Omma (henrik)]

Closing Ubuntu task as it's fixed in Feisty.

[Henrik Nilsen Omma (henrik)]

Removing dapper milestone.

[Mantas Kriaučiūnas (mantas)]

totem-xine from Feisty still overrides XV_CONSTRAST to wrong default value (Xv movies on i810/i945 have horrible colour/gamma), so, this bug isn't fixed in Ubuntu 7.04

[Tarik Jabri (tjabri)]

I can confirm Mantas's assertion that this bug still exits in Feisty. I am also using an Intel i810 and I experience this issue. I had to change all my media players to use X11 instead of XV and that seemed to work around this bug.

[Tarik Jabri (tjabri)]

Just made another little discovery. I played with the Gstreamer properties (I ran gstreamer-properties) and the issues happen when the video output is set to Autodetect or XV Intel Video Overlay (xvimagesink device="0"). It doesn't happen when the setting is X11 only, or XV with Intel Textured Video (xvimagesink device="1").

This problem occurs under ALL media players, whether running Gstreamer or Xine (I've tried all...).

[Hendy Irawan (ceefour)]

Ditto on the above comments.

Bug still exists in Lenovo Y400.

Triggered by running mplayer/Kmplayer, but all other video apps will be affected.

ceefour> lspci -vv
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03)
        Subsystem: Lenovo Unknown device 3800
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Capabilities: <access denied>

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: Lenovo Unknown device 3801
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at d4200000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 1800 [size=8]
        Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at d4300000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: <access denied>

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
        Subsystem: Lenovo Unknown device 3801
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at d4280000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: <access denied>

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
        Subsystem: Lenovo Unknown device 3802
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at d4340000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00002000-00002fff
        Memory behind bridge: d2000000-d3ffffff
        Prefetchable memory behind bridge: 00000000d0000000-00000000d1ffffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capab...

[Peter Maydell (pmaydell)]

I'm seeing this in gutsy -- totem is overriding XV_SATURATION to 511 (should be 128) and XV_BRIGHTNESS to -1 (should be 0), with predictably awful results. This is a Lenovo 3000 C200 with what lspci says is Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03).

[Vytas (vytas)]

For a new user in Gutsy, it works fine.
But for one who has upgraded, it won't. Because normal saturation is now 1/8, normal contrast 1/4. Totem "restore defaults" button moves all values to 1/2 producing very artistic results.

[Conn O Griofa (psyke83)]

System: Dell Inspiron 510m laptop, VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02), Intel(R) Pentium(R) M processor 1500MHz
Ubuntu Gutsy 7.10 (fresh install from RC cd, fully updated as of October 22)

From a fresh reboot, here's some terminal output to illustrate this bug (I simply close vlc/totem as soon as video playback begins):

conn@inspiron:~$ xvinfo >xvinfo_boot.log
conn@inspiron:~$ vlc /media/windows/Downloads/HL2_Trailer01.wmv
VLC media player 0.8.6c Janus
[00000281] main playlist: stopping playback
conn@inspiron:~$ xvinfo >xvinfo_vlc.log
conn@inspiron:~$ diff -u xvinfo_boot.log xvinfo_vlc.log
conn@inspiron:~$ totem /media/windows/Downloads/HL2_Trailer01.wmv
sh: jackd: not found
sh: jackd: not found
DMO dll supports VO Optimizations 0 1
DMO dll might use previous sample when requested
Total Unfree 60 bytes cnt 1 [(nil),0]
conn@inspiron:~$ xvinfo >xvinfo_totem.log
conn@inspiron:~$ diff -u xvinfo_boot.log xvinfo_totem.log
--- xvinfo_boot.log 2007-10-22 20:14:17.000000000 -0200
+++ xvinfo_totem.log 2007-10-22 20:15:36.000000000 -0200
@@ -16,16 +16,16 @@
     number of attributes: 6
       "XV_COLORKEY" (range 0 to 16777215)
               client settable attribute
- client gettable attribute (current value is 66046)
+ client gettable attribute (current value is 66051)
       "XV_BRIGHTNESS" (range -128 to 127)
               client settable attribute
- client gettable attribute (current value is 0)
+ client gettable attribute (current value is -25)
       "XV_CONTRAST" (range 0 to 255)
               client settable attribute
- client gettable attribute (current value is 64)
+ client gettable attribute (current value is 51)
       "XV_SATURATION" (range 0 to 1023)
               client settable attribute
- client gettable attribute (current value is 128)
+ client gettable attribute (current value is 75)
       "XV_DOUBLE_BUFFER" (range 0 to 1)
               client settable attribute
               client gettable attribute (current value is 1)

So, in summary:
1. My XV parameters upon bootup are optimal (video playback looks fine).
2. Other applications such as VLC that use XVideo output *do not* change the XV parameters.
3. Running Totem, specifically the default backend, totem-gstreamer, causes XV parameters to inexplicably change, without any interaction. This causes video to look too dark, and can only be fixed by manually resetting XV parameter, e.g. with xvattr.

This is a bug in totem or one of its backends, and should be investigated. I'm sick of having to manually tweak XV parameters every time I want to watch a movie!

[Ali Sabil (asabil)]

Since I upgraded to gutsy, this bug seems to also affect xserver-xorg-video-intel

[Jamie Lokier (jamie-shareable)]

I see similar problems with Gutsy's driver. However, my image isn't "too white". There is no white at all: it's all blue and red combinations.

I didn't know about xvattr and so on, and it's annoying that Totem has no controls (that I could find) to adjust any of the brightness/contrast/saturation values, and the control to turn of Xv output is rather obscurely hidden in a different program (so I didn't find it).

So I tried other video players. Xine looked similar, but slightly better. Still all blues and reds but with a hint of green. Turning off Xv fixed it.

mplayer had slightly more green, yet still with the same problem. Turning off Xv fixed it (unsurprising by now).

Isn't it odd that Totem/Xine/mplayer all looked different, despite having the same problem. (Note that I always tried Totem first).

Eventually I found that the Xv Contrast control was set to its most negative value. By changing this in mplayer to a low-to-middle value, the picture was fixed.

Curiously, I am now using this driver, and Totem looks fine without touching any Xv settings:
http://people.ubuntu.com/~bryce/Testing/intel/xserver-xorg-video-intel_2.1.1~git20071004-0ubuntu1_i386.deb

But I also notice that Contrast is still set to that most negative value, but now changing any of the controls doesn't have any effect on the picture, in any video player (using Xv).

[Jamie Lokier (jamie-shareable)]

Responding to comment from Vytas: "For a new user in Gutsy, it works fine.
But for one who has upgraded, it won't. Because normal saturation is now 1/8, normal contrast 1/4. Totem "restore defaults" button moves all values to 1/2 producing very artistic results.".

I'm using an upgraded-to-Gutsy, on a laptop with 945GM.

I'm seeing that before "Restore defaults", Totem sets my contrast to the most negative value (i.e. slider in the left position), and that makes the picture all blues and reds. "Restore defaults" actually makes the picture much better, though still not quite right.

[zdzichu (zdzichu-gmail)]

I've upgraded Feisty->Gutsy. i945 on Thinkpad Z61t. Colors are messed up.

[unggnu (unggnu)]

I guess that the i810 driver won't be fixed anymore since it is deprecated.

[Mantas Kriaučiūnas (mantas)]

I've tested totem on Ubuntu 7.10 (Gutsy) / Baltix 3.0 final - it seems this problem exists only with totem-xine packages, totem-gstreamer doesn't change contrast. Same results with Ubuntu 7.04 (Feisty).

Please fix it, other distros, for example, Fedora, doesn't have this annoying problem.

[Ari (ari-reads)]

sorry guys, i'm having the some-colors-messed-up issue when playing videos, and from reading the above I don't understand what the workaround is. Can someone clarify how to fix this?

 - Upgraded a perfectly working Edgy to Gutsy, then the problems with the colors while playing movies started
 - Using the intel driver
 - problems occur in all video players I use (vlc & totem)
 - problems occur regardless of the "desktop effects" setting

TIA

[David Benjamin (davidben)]

I can confirm this regression in Gutsy. (Feisty->Gutsy upgrades anyway.)

The problem occurs consistently and is always reproducible.

[ropers (ropers)]

I am having the same problem with 7.10.

I have a very old and dark HP D2808 monitor.
In my /etc/X11/xorg.conf file, I have set this line
  Gamma 1.6
to adjust the gamma correction.

However, in Ubuntu 7.10 Gutsy Gibbon, XVideo does not respect the X Window system-wide gamma correction setting.

As a workaround, I can use xvattr to turn up the brightness, like so:
  xvattr -a XV_BRIGHTNESS -v 24
This is of course an imperfect substitute, because brightness != gamma, however it makes eg. RealPlayer XVideo and Totem Xvideo videos watchable.

Despite the workaround, I feel that it is very important that the bug be fixed and XVideo be made to respect gamma values and other settings.

[ropers (ropers)]

PS: To add to the above workaround, using not just
  xvattr -a XV_BRIGHTNESS -v 24
but also
  xvattr -a XV_CONTRAST -v 3000
makes the picture better, and more similar to a gamma 1.6 corrected picture. (The default values are 0 and 4096, respectively.)

[Xvani (fredrile+launchpad)]

Happens every boot with xv only in 7.10. Clean install

I have to use x11 to get correct image now. Unfortunately, in that case, my computer isn't fast enough to run HD movies and such.

Please fix this, and/or provide a workaround (the correct xvattr commands?) for us.

Thank you!

[Daniel Lombraña González (teleyinex)]

I have the same problem with my intel card. I have tried to change from i810
to intel driver, but I have always the bright so bright :). I don't know why
release after release this bug is not fixed. I have it since Dapper,
something horrible.

On Dec 14, 2007 11:23 PM, Xvani <email address hidden> wrote:

> Happens every boot with xv only in 7.10. Clean install
>
> I have to use x11 to get correct image now. Unfortunately, in that case,
> my computer isn't fast enough to run HD movies and such.
>
> Please fix this, and/or provide a workaround (the correct xvattr
> commands?) for us.
>
> Thank you!
>
> --
> totem overrides XV_CONSTRAST to wrong default value (Xv movies on
> i810/i945 have horrible colour/gamma)
> https://bugs.launchpad.net/bugs/32963
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
··························································································································································
PhD Candidate
Cátedra Ceta-Ciemat de la Universidad de Extremadura
Universidad de Extremadura
··························································································································································
Por favor, NO utilice formatos de archivo propietarios para el
intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV
o cualquier otro que no obligue a utilizar un programa de un
fabricante concreto para tratar la información contenida en él.
··························································································································································

[Swistak (swistakers)]

Still not fixed in hardy... I'm fed up. Totem went to /dev/null.

[loko (arph)]

Well,

this bug is also driving me crazy. how annoying it is to get this not fixed.

but ppl. maybe this will help you a little bit

start gconf-editor and go to totem:

change:
brightness 32639
contrast 16191
hue 32767
saturation 8135

well, the really annoying thing is if these values are changed by totem from time to time, also mplayer and others are affected.
it's normal since it depends on the video-driver.
i wonder that even these drivers are open-source this cannot get fixed. what a pity.

[Vytas (vytas)]

I also noticed these values are changed by totem from time to time (Hardy up to date), how come?

[unggnu (unggnu)]

I have made a simple script to do these changes mentioned by loko. The problem is, that Totem doesn't recognizes the changes on the fly like gconf and Totem has to be run to transfer the changes to X. So it is definitely a Totem problem.
Just download it, mark it as executable and add a link to you panel. Everytime the color is wrong close the video player an run it. Totem will be run and closed after some seconds. Maybe the sleep time has to be adjusted on slower PCs. Btw I would use another player like VLC or something like that. This problem appears only after Totem or maybe gstreamer use.

[unggnu (unggnu)]

Btw. it seems that the only problem of the Intel driver is that it memorizes the xv color value changes from Totem for the session which is not so bad imho.

[loko (arph)]

Can somebody give an overview of the status of this bug.
i mean is there a chance to get it fixed until hardy release.

or is there any other information needed to fix the bug?

btw. a look at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel is frustrating. 10 or more bugs confirmed and high importance. i doubt these will fixed until hardy is out.

[Sebastien Bacher (seb128)]

The bug is confusing, do people having the issue using totem-gstreamer or totem-xine? What do you do on a new installation to trigger the issue? What driver and card are you using?

[Gert Kulyk (gkulyk)]

As far as it concerns my setup, it is happening with all applications using xv. When having set up e.g. via totem the corrected values, they'll stay until another app is overwriting the settings and/or you're opening another video-window (in that case it will switch back to xshm, and there are other settings needed for correct display). While i810-driver had only wrong contrast-defaults, intel one has additionally insane saturation-settings.

[Jon-o Addleman (jaddle)]

Using totem-xine on a thinkpad x60s. Playing any movie messes up
contrast and saturation. Playing in mplayer never has any trouble
(unless the video had been corrupted already by playing in totem).
Resetting the xv settings fixes it until totem is loaded again.

--
Jon-o Addleman - http://www.redowl.ca

[loko (arph)]

@Sebastian Bacher:

To answere your questions: in my case i use totem-gstreamer

Well: on a new system i do the following and i can reproduce it:

starting with gconf-edit values of totem which are:

brightness 32639
contrast 16191
hue 32767
saturation 8135

I open totem, play a normal dvd-vob file.

after first play, lets say i play it for about 20 sec. (but the playing-time doesn't matter) the values i can see with gconf-editor changed itself to:

brightness 32382
contrast 15934
hue 32767
saturation 8007

after next play (just closing totem and open it some seconds later)

brightness 32125
contrast 15677
hue 32767
saturation 7879

next play:

brightness 31868
contrast 15420
hue 32767
saturation 7751

and so on. after resetting the values, the changes are exactly the same with the same steps.

it seems that the values are constanly going down. this also affects the values from mplayer as well.

system specs:
xorg-video-intel: 2:2.1.1-0ubuntu9.1
xorg: 1:7.2-5ubuntu13
kernel: 2.6.22-14.52
lspci: 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
        Subsystem: ASUSTeK Computer Inc. Unknown device 1267
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] Vendor Specific Information

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: ASUSTeK Computer Inc. Unknown device 1252
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at feb80000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at ec00 [size=8]
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Memory at feb40000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 2

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
        Subsystem: ASUSTeK Computer Inc. Unknown device 1252
        Flags: bus master, fast devsel, latency 0
        Memory at fea80000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 2

some other specs or infos needed?

[Vytas (vytas)]

Problem on my laptop is identical to the one loko described, numbers match identically

[Yuri Glushkov (yglushkov)]

You can workaround this problem by running gstreamer-properties and setting Default Output -> Plugin at "Video" tab to "X Window System (No Xv)".

[Marcus Sundman (sundman)]

> You can workaround this problem by running gstreamer-properties and setting
> Default Output -> Plugin at "Video" tab to "X Window System (No Xv)".

But then it takes 10+ times more CPU and gets huge, ugly pixellation when upsized, which is even worse. How do you work around that?

[loko (arph)]

Yuri Glushkov's suggestion is no acceptable solution at all.
so is there any developer that spends some time on this bug atm and is there a chance to get this fixed until hardy is out?

[Sebastien Bacher (seb128)]

the bug will likely be worked once it's clear whether the issue is due to the driver or the software and than somebody running into it will we wanting to work on it, it seems that the hackers around don't have the issue though

[Lionel Dricot (ploum-deactivatedaccount)]

Sebastien > the issue itself is confusing. Some computer have it all the time, some have it very rarely. On some computer, it's solved by a reboot. On some others, not. As far as I know, it can happen with Nvidia and Intel graphic card.

I had this bug under Gnome 2.6 or 2.8 (I don't remember) on a desktop computer with a GeForce 4MX but never reappared on this computer eventhough it was completely reinstalled (with a whole fresh new hard drive) a few years later l. I had it on my current laptop in Edgy (intel card). It was solved under Feisty.

So, to all reporters : instead of looking for a solution/workaround, this bug needs a real reproducible test case. It must be from a fresh and empty Ubuntu desktop with a given file (and a given Graphic card). If you can reproduce this from a Live CD, it could be a good idea.

I wish there was a comment which says :

1) Install Ubuntu on a computer with XXX graphic card
2) Install packages xxx and yyy
3) Download movie zzzz and launch it in player AAA
4) The bug happens.

[Xvani (fredrile+launchpad)]

I have this problem on my Gutsy install using the -intel driver.

IMHO it can't be the software, because I do not have Totem currently installed. (purged)

However, I believe I did run Totem before I purged it.
Whether I use mplayer or VLC with xv, I will get the contrast/saturation/brightness problem, and I have to use xvattr to correct this every time I open a media file.

What more info is required to make it clear where the issue occurs?

[loko (arph)]

@Lionel Dricot,

here is the info you asked about and i hope that it will be helpfull.

This is a step-by-step to reproduce the bug 100%

System-Specs:
Laptop Asus W5F
graphics: Intel GMA 950
ubuntu gutsy, up-to-date at 25.02.2008
xorg-video-intel: 2:2.1.1-0ubuntu9.1
gstreamer-version: 0.10.14, 0.10.6, 0.10.5
xorg: 1:7.2-5ubuntu13
kernel: 2.6.22-14.52

output of lspci:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
        Subsystem: ASUSTeK Computer Inc. Unknown device 1267
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] Vendor Specific Information

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: ASUSTeK Computer Inc. Unknown device 1252
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at feb80000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at ec00 [size=8]
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Memory at feb40000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 2

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
        Subsystem: ASUSTeK Computer Inc. Unknown device 1252
        Flags: bus master, fast devsel, latency 0
        Memory at fea80000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 2

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
        Subsystem: ASUSTeK Computer Inc. Unknown device 1263
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at feb3c000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
        Capabilities: [70] Express Unknown type IRQ 0

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
        I/O behind bridge: 0000a000-0000cfff
        Memory behind bridge: f8700000-fe6fffff
        Prefetchable memory behind bridge: 000000008ff00000-00000000bfefffff
        Capabilities: [40] Express Root Port (Slot+) IRQ 0
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [90] Subsystem: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
        Capabilities: [a0] Power Management version 2

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
        Memory behind bridge: fe700000-fe7fffff
        Capabilities: [40] Express Root Port (Slot+) IRQ 0
        Cap...

[Vytas (vytas)]

I also reproduce the same bug as loko, though on a different laptop
Ubuntu Hardy up to date

[Conn O Griofa (psyke83)]

It's getting ridiculous that this bug isn't fixed. Anyway, here's a tip for people who are impatient:

1. Install xvattr: sudo apt-get install xvattr

2. Create a diversion from /usr/bin/totem to /usr/bin/totem.real as follows: sudo dpkg-divert --divert /usr/bin/totem.real --rename /usr/bin/totem

3. Create a new file called /usr/bin/totem, and add this into the file:

#!/bin/bash
# To fix contrast issues
totem.real "$@" &
sleep 5
xvattr -a XV_CONTRAST -v 64
xvattr -a XV_BRIGHTNESS -v 0
xvattr -a XV_COLORKEY -v 66051
xvattr -a XV_SATURATION -v 128

4. Finally, make this script executable: sudo chmod +x /usr/bin/totem

Each time totem plays a movie, this script will force default XV settings.

Why isn't this bug fixed yet?

[Sebastien Bacher (seb128)]

the bug is not fixed yet because nobody having the issue worked on it and because there is a small team and thousand of bugs opened

[unggnu (unggnu)]

I have rechecked this issue in current Hardy and it seems that the color settings of Totem haven't any effect at all.

[Konrad Materka (kmaterka)]

I can confirm this on Hardy beta1 with Intel GMA 940/945. It is serious problem, Intel is very popular on laptops!

[Bryce Harrington (bryce)]

bug 105656 proposes a patch with different settings, to correct black/white levels in the driver. We will need to coordinate the fixes both to this bug and that one, to ensure any changes made don't make the situation worse for the other. I'm concerned both are going to want to change the same code but in different ways, so we'll need to account for that.

The patch posted at https://bugs.freedesktop.org/show_bug.cgi?id=15219 can be reviewed and used as a starting point, for anyone wishing to work on a solution to this problem. It looks like a patch for this should be fairly straightforward to create. I'll be willing to package debs of the patch for folks to test.

If we get a patch that looks acceptable and doesn't seem to cause new issues for anyone, the next step in the procedure would involve proposing it upstream to xorg (or Debian) for their comments. Ideally, our patch should be taken upstream by them; if not, we'd need to have a very good rationale for why we should carry it in spite of that.

[the reaper (elfo0scuro)]

I have resolved it installing the xserver-xorg-video-intel_2.2.99.902-1_i386.deb from debian experimental branch...now all work with Xv

[Xvani (fredrile+launchpad)]

I cannot install that patch, because I use the i810 driver for some reason. How do I switch?

If this issue can be fixed by a driver, can we then conclude that this is not a Totem issue? I mean, I don't even have totem installed...

[Konrad Materka (kmaterka)]

It is driver bug, many reports on freedesktop, etc:
https://bugs.freedesktop.org/show_bug.cgi?id=15467
it is resolved now, Debian experimental package works very good.

It is not only related to Totem, SMplayer breaks too.

[Conn O Griofa (psyke83)]

Konrad,

I'll give the experimental package soon, but can I ask: do you use the overlay or texture video adapter on your Intel chipset? It seems that bug fixes textured video, which my 855GM chipset doesn't even support...

[Konrad Materka (kmaterka)]

I am using mplayers XV, still X11 works.

[Conn O Griofa (psyke83)]

I'm sorry Konrad, but Debian's experimental package still has this problem for me. The following testcase applies to Ubuntu Hardy's latest driver, as well as Debian experimental:

System:
Dell Inspiron 510m
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
xserver-xorg-video-intel 2:2.2.1-1ubuntu12

Test case:
1. Install "xvattr" package
2. Reboot system, and get "base" settings for XV, i.e. "xvattr >xvattr.default"
3. Open a movie using a different movie player, close it, then get a new reading via xvattr; e.g. after playing a movie in VLC: "xvattr >xvattr.vlc"
4. Compare files, e.g.: diff -u xvattr.default xvattr.vlc
5. If there is a difference, you will need to reset xvattr to "default" settings before trying another movie player.
5. If there is no difference, repeat step 3 & 4 with a different movie player.

Expected results:
No movie players change XV settings

Actual results:
Totem (only using the gstreamer backend) causes XV settings to change each time a movie is opened. No other movie player (including totem-xine) causes this problem.

conn@inspiron:~/intelbug$ diff -u xvattr.default xvattr.totem-gstreamer
--- xvattr.default 2008-04-24 00:07:00.000000000 +0100
+++ xvattr.totem-gstreamer 2008-04-24 00:08:14.000000000 +0100
@@ -6,22 +6,22 @@
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 16777215
- Current value: 66046
+ Current value: 66051
   Name: XV_BRIGHTNESS
    Flags: XvGettable XvSettable
    Min value: -128
    Max value: 127
- Current value: 0
+ Current value: -1
   Name: XV_CONTRAST
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 255
- Current value: 64
+ Current value: 62
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 128
+ Current value: 125
   Name: XV_DOUBLE_BUFFER
    Flags: XvGettable XvSettable
    Min value: 0

[Conn O Griofa (psyke83)]

Test Case 2:

1. Get default settings from fresh startup, before launching any movie players, i.e. xvattr >xvattr.default
2. Repeatedly open a movie in totem-gstreamer, then close movie and record xvattr settings, i.e.

totem /usr/share/example-content/Experience\ ubuntu.ogg
xvattr >xvattr.1
totem /usr/share/example-content/Experience\ ubuntu.ogg
xvattr >xvattr.2
totem /usr/share/example-content/Experience\ ubuntu.ogg
xvattr >xvattr.3

3. Compare xvattr settings.

Conclusion: each time totem opens a new movie, it further changes the default movie settings (please see attachment).

[Xvani (fredrile+launchpad)]

Conn wrote:

Actual results:
Totem (only using the gstreamer backend) causes XV settings to change each time a movie is opened. No other movie player (including totem-xine) causes this problem.

-----------------------------

I'm sorry Conn, but this is incorrect. SMplayer breaks too....

[Conn O Griofa (psyke83)]

I didn't have smplayer installed, but you are correct, that also changes the values. It is *not* a problem with mplayer, though.

--- xvattr.default 2008-04-25 20:33:02.000000000 +0100
+++ xvattr.smplayer 2008-04-25 20:45:37.000000000 +0100
@@ -11,17 +11,17 @@
    Flags: XvGettable XvSettable
    Min value: -128
    Max value: 127
- Current value: 0
+ Current value: -1
   Name: XV_CONTRAST
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 255
- Current value: 64
+ Current value: 127
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 128
+ Current value: 511
   Name: XV_DOUBLE_BUFFER
    Flags: XvGettable XvSettable
    Min value: 0

[Thomas Fritzsche (tf-noto)]

Hi Guys,

for some of you maybe this help:
http://lists.freedesktop.org/archives/xorg/2008-May/035259.htm

Patched driver is also available (see above following this link, on how to build from source:
http://linux.pengin.de/#xvattr

Have a nice day!
Best regards,
Thomas Fritzsche

[MacAdam (sevenmog)]

Same problem here, with totem-gstreamer and Xv output. I don't remember if it was like that in the begining because i mainly use mplayer and vlc.
When I opened a video with totem, the video was black and white and corrupted the others video players as well. Only solution was to reboot (don't remember if simply reloggin worked) and to never let totem-gstreamer touch anything again.

I also confirme that Smplayer has the same problem, although Gnome mplayer, Gmplayer and mplayer don't.
I didn't have xine installed but i plan to check totem-xine, gxine and xine-ui.

Now the video isn't black and white anymore but the colors are totally messed up, contrast gamma saturation ect... probably due to an update, since i didn't check how totem was doing for a long time.
Reloggin a new session return "desinfect" the sain players

Using X11 solve the problem, but only in apparence since it bring it own issues. Too much cpu load cause me some laggs, flickering and audio and video are out of sync.

Configuration
Gutsy, xserver-xorg-video-intel 2.2.1.1 ubuntu9.1

lspci -vv:
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) (prog-if 00 [VGA])

dpkg -l | awk '/totem-/{print$1,$2m$3}':
ii libtotem-plparser72.20.0-0ubuntu3
ii totem-gstreamer2.20.0-0ubuntu3
ii totem-mozilla2.20.0-0ubuntu3

[MacAdam (sevenmog)]

Hi Thomas,

thanks for the links I 'll check those out.

Also, typo error i presume you forget the l (L) at the end, otherwise you get a nice 404 error.
Here the good link:
http://lists.freedesktop.org/archives/xorg/2008-May/035259.html

[Thomas Fritzsche (tf-noto)]

Hi MacAdam,

yes, the the "l" was missing in the link. Patch is for the driver so not depending on the player software.
At least the issues I suffered here was not showing up with some player because these players doesn't adjust the xv attributes. The defaults value provided by the X driver was OK, so no issue there.
Just totem does has this settings and "tries" to set to "neutral" when started (50%), but the intel driver uses this parameter differently.
I changed "i830_video.c" file that is e.g. used with my "i965" chip. I hope this helps everybody having a similar chip. I tested smplayer and totem-gstreamer here, but I don't have any issues with these programs (any more).

Does it work for you?

Thanks,
Thomas

[MacAdam (sevenmog)]

Actually, i'm still running gutsy 7.10 so i had to compiled from the sources. I successfully apply your patch to the "i830_video.c" file but encounter some depedencies issues while compiling the xserver-xorg-video-intel sources.

Here is where it stop in the ./configure part :

"...
checking for XORG... configure: error: Package requirements (xorg-server xproto xvmc fontsproto ) were not met:

No package 'xorg-server' found
No package 'xproto' found
No package 'xvmc' found
No package 'fontsproto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XORG_CFLAGS
and XORG_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details."

Naturally i tried to install those packages but couldn't find the xorg-server package in the repositories.

So i'm going to look further into the matter.

Cheers

[Peter Clifton (pcjc2)]

On Sun, 2008-05-11 at 15:34 +0000, MacAdam wrote:
> Actually, i'm still running gutsy 7.10 so i had to compiled from the
> sources. I successfully apply your patch to the "i830_video.c" file
> but
> encounter some depedencies issues while compiling the xserver-xorg-
> video-intel sources.
>
> Here is where it stop in the ./configure part :

You're missing various development libraries needed to compile the
driver.

> Naturally i tried to install those packages but couldn't find the xorg-
> server package in the repositories.

Try "sudo apt-get build-dep xserver-xorg-video-intel"

That should pull in what you need.

--
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: [phone] - (No signal in the lab!)

[James McPhee (jmcphe)]

Having similar issues, but using proprietary nvidia drivers. Ref Bug#199975

[MacAdam (sevenmog)]

Thanks for your help Peter, that command was very useful.
However something must have fail somewhere because it boot in low res mode each time (vesa). I can't switch to intel as it doesn't seem to recognize the driver.
Since it's mainly a compiling issue i'll check it in the ubuntu forum.

[Conn O Griofa (psyke83)]

@Bryce Harrington: I tried the patch from bug #151 and it didn't help this situation either. I believe the purpose of that patch is to provide values to improve colour reproduction, and while it's a good patch that has (IIRC) been pushed upstream, it doesn't help with this particular bug.

@Thomas Fritzsche: I tried the proposed patch you referred to in comment #161, and while the default values have been redefined, totem-gstreamer still continues to modify these settings without user consent.

Each time you open a movie with totem-gstreamer, the following occurs:
XV_BRIGHTNESS is reduced by 1 point;
XV_CONTRAST is reduced by 2 points;
XV_SATURATION is reduced by 3 points.

Also, it seems XV_COLORKEY increases by 5 points (from 66046 to 66051) after the first invocation of totem, but it remains stable at 66051, unlike the three attributes above.

@James McPhee: this bug report is for Intel cards only, your linked bug is not related.

[Jamie Lokier (jamie-shareable)]

While this bug is still going on, I'll add something else:

I'm using Ubuntu 8.04 (Hardy), with Medibuntu for media playing, on an
Intel 945G video system.

Xine plays H.264-MKS ok, but the colours are a too bright and a little
too saturated. It's watchable (a big improvement over 6 months ago),
but looks wrong.

VLC plays the same videos much better. They look about right.

This is with no particular adjustments on my part.

Isn't that interesting?

[Thomas Fritzsche (tf-noto)]

looks like it's actually affective! Please have a look on the result without patch:
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 128
+ Current value: 511

@Conn: If you "just" have change by some point this should be Ok. Guess it's rounding issue. Totem seems to set XV attributes to 50% of "Min value" and "Max value", but is maybe rounding a little bit different.
In earlier version the change was from 128--＞511! (change by 383)
Can you check if Saturation looks OK with Totem default setting (about 50%)?
Please notice with unpatched intel driver the neutral setting is by about 128 (default value), but totem then set's 50% of min and max value (looks like they get value 511). So saturation is way too high.

The default values had been not really changed by patch. (just adjusted to new scale I introduced)
@Jamie: If you have specific issue without XV attributes changes it's maybe a different issue.
Can you provide a test case on how to reproduce?

I just adjusted XV_SATURATION and XV_CONTRAST and have not gone in other settings. This patch should provide neutral setting by about 50%.

[MacAdam (sevenmog)]

@Thomas: I've finally applied your patch on gutsy, the second one you release on freedesktop list.
It doesn't solve the problem. Totem still changes colorkeys, brightness, contrast and saturation's values. It also contaminates others video players used afterward.

--- xvattr.default3 2008-05-25 17:13:13.000000000 +0200
+++ xvattr.totem 2008-05-25 18:07:57.000000000 +0200
@@ -6,22 +6,22 @@
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 16777215
- Current value: 66046
+ Current value: 66051
   Name: XV_BRIGHTNESS
    Flags: XvGettable XvSettable
    Min value: -128
    Max value: 127
- Current value: 0
+ Current value: -25
   Name: XV_CONTRAST
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 255
- Current value: 128
+ Current value: 51
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 512
+ Current value: 48
   Name: XV_DOUBLE_BUFFER
    Flags: XvGettable XvSettable
    Min value: 0

However, the interesting thing is that Smplayer also changes the values but they stay stable. Like it reconfigures it's own default values:

--- xvattr.default3 2008-05-25 17:13:13.000000000 +0200
+++ xvattr.smplayer 2008-05-25 17:18:25.000000000 +0200
@@ -11,17 +11,17 @@
    Flags: XvGettable XvSettable
    Min value: -128
    Max value: 127
- Current value: 0
+ Current value: -1
   Name: XV_CONTRAST
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 255
- Current value: 128
+ Current value: 127
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 512
+ Current value: 511
   Name: XV_DOUBLE_BUFFER
    Flags: XvGettable XvSettable
    Min value: 0

You can notice the values are replaced by default values (after your fix) minus 1.
Even if you play totem many times over and keep changing the values, if you play a video with smplayer it will reconfigures the values back at smplayer's default (default after fix -1).
Smplayer seems to be approaching something here, if smplayer can work properly, i wouldn't mind putting totem in quarantine.

Also, i looked a little at your fix as the non-coder noob that i am, and I was wondering why put the default's values of contrast and saturation at 128 and 512.
Couldn't you let them at 64 and 128? Does that change a lot?
The videos are watchables though.
thanks

[Thomas Fritzsche (tf-noto)]

@MacAdam :
Just Saturation and Contrast is changed by patch. The player I'm testing is totem-xine, but I focused on drive issue so the player doesn't matter so much.
The patch just moves neutral setting to about 50% (for Saturation this is about 512 (as Min value 0 and Max value 1023). The default value is adjusted to this.
You output for saturation is:
+ Current value: 51
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 512
+ Current value: 48
*********
So default looks good, somehow you have setup your player to set a value of 48!? That's odd. I just assume that this is maybe an old setting you applied earlier to adjust the earlier XV attribute scale.
Can you confirm that you have default display attributes (in totem settings) (the slider for saturation and contrast is about the half).
If this is not at case, can you push the button to adjust this.
If you are using program "gxvattr" and you adjust "saturation" and "contrast" to about the half, you should have "neutral" setting. Can you check this out?

[MacAdam (sevenmog)]

I didn't used gxvattr yet, although it's installed. In gxvattr, the settings are about half their respectives bar. Without playing totem-gstreamer.

In totem, by default, brightness is a little off on the left, contrast about 25% of the bar and saturation almost totally on the left.
I don't remember touching those settings, but i did some tests with gstreamer-properties. Like switching to x11/XShm/Xv or without Xv.

After changing those buttons approximatly half the bars, here are the new diff xvattr values:

--- xvattr.default3 2008-05-25 17:13:13.000000000 +0200
+++ xvattr.totem2 2008-05-27 17:19:23.000000000 +0200
@@ -6,7 +6,7 @@
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 16777215
- Current value: 66046
+ Current value: 66051
   Name: XV_BRIGHTNESS
    Flags: XvGettable XvSettable
    Min value: -128
@@ -16,12 +16,12 @@
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 255
- Current value: 128
+ Current value: 126
   Name: XV_SATURATION
    Flags: XvGettable XvSettable
    Min value: 0
    Max value: 1023
- Current value: 512
+ Current value: 509
   Name: XV_DOUBLE_BUFFER
    Flags: XvGettable XvSettable
    Min value: 0

They're approaching the new default values. Now the videos are watchables whereas everything was pretty much dark earlier.
But those value could probably match the default ones if we could numerally change them, instead of manually set them.

[Thomas Fritzsche (tf-noto)]

Totem-player display setting has a button "reset to defaults" and here with me this sets the color slider to pretty much exactly 50%. Remaining differences (rounding) are not visible.
Don't know details of totem, but guess it stores default setting. So as the scale is not adjusted to have neutral setting on 50% it should be fine once you have used button "reset to defaults".

[MacAdam (sevenmog)]

You're right, i have reset to default and now the slider looks better.
Here's the new diff:

    Name: XV_COLORKEYS
- Current value: 66046
+ Current value: 66051
    Name: XV_CONTRAST
- Current value: 128
+ Current value: 126
   Name: XV_SATURATION
 - Current value: 512
+ Current value: 510

Brightness doesn't change.
After that, each time I open totem the values follows those pattern:
XV_BRIGHTNESS: -1
XV_CONTRAST: -1
XV_SATURATION: -2
COLORKEYS stays put at 66051 after the +5 change from the first totem invocation.

Pretty much the same as Conn mentionned earlier, but with the 2nd version of the patch you proposed on freedesktop.

[Zorael (zorael)]

It works very nicely for me if I downgrade to Thomas Fritzsche's package. The xvattr settings still reset upon launch of any player (smplayer, kaffeine...), but the contrast/saturation spectrum is now the same for xv and x11/etc.

             $ apt-cache policy xserver-xorg-video-intel
             xserver-xorg-video-intel:
               Installed: 2:2.2.1-1ubuntu13
               Candidate: 2:2.2.1-1ubuntu13.1
               Version table:
                  2:2.2.1-1ubuntu13.1 0
                     500 http://se.archive.ubuntu.com hardy-proposed/main Packages
              *** 2:2.2.1-1ubuntu13 0
                     500 http://se.archive.ubuntu.com hardy-updates/main Packages
                     100 /var/lib/dpkg/status
                  2:2.2.1-1ubuntu12 0
                     500 http://se.archive.ubuntu.com hardy/main Packages

(note: 2.2.1-1ubuntu13 < 2.2.1-1ubuntu13.1)

Would be nice if it could be merged into the, uh, repository packages. Many thanks at any rate. :>

[GFree (gfree678)]

Since nothing seems to work for me as far as driver replacements go, I've developed my own analysis and workaround for the problem, which I'll share here in case people find it useful:

OK, now according to xvattr, my default values for brightness, contrast and saturation are 0, 64 and 128 respectively. I do not use Totem, I hate the GUI, but I do like using SMPlayer for most videos and VLC for DVD playback. There are two problems though:

* The default values above are actually a little too high, even though they look like sensible defaults. For some reason, even after verifying the defaults are not being modified in something like VLC (which doesn't move them around at all), blacks are not entirely black and hence everything's slightly too bright.
* SMPlayer, unlike regular MPlayer, does like to modify the color values and screws things up entirely.

Hence, there are two tasks:

* To change the default values to something sensible so that VLC can show blacks as proper blacks and hence everything looks good.
* To stop SMPlayer from fuxxoring with the values itself.

After experimentation, I discovered that the issue of blacks could be fixed if XV_BRIGHTNESS was reduced to about -12, but everything else looked bright enough to be reasonable. I also discovered that if I ran if I ran MPlayer with the following parameters:

-contrast -49 -brightness -9 -saturation -75

This would adjust all the balances to such that things would look fine. To stop SMPlayer from going screwey, I went to the advanced section of the options menu, put these parameters in the additional parameters section, and so SMplayer worked beautifully. Also, VLC would show nice blacks and colors if I ran SMPlayer at least once before, since it would adjust the brightness as part of the new settings I gave it.

So yeah, that's what I did. A bit of a shame that an open-source driver has this bug which cannot seem to be fixed and yet closed-source binary blobs from NVIDIA work just fine, but there you go. Hope that's useful to someone. :)

[Thomas Fritzsche (tf-noto)]

@GFree: I see you use unpatched driver. Since you use not totem but video player that seems to keep the default values (I think at least VLC is doing like this) this should be fine.
Actually the intel driver is mapping this to the neutral setting for contrast/brightness/saturation. (according to HW register specification)

If you have personally other preferences (the blacks are not back enough etc.), then please adjust the parameters to to your favourite setting, that's what they should be used for.

However I would oppose changing the driver defaults to anything else than neutral. Actually on my system I'm satisfied with the results.

[GFree (gfree678)]

@Thomas: Yeah, I'm using the unpatched driver for two reasons - (1) The prebuilt version you've linked before is older than what's currently available in the repos, (2) I don't want to build the driver myself, and (3) when I tried the patched driver anyway, nothing changed for me.

As for the neutral settings for everything, the problem is that they aren't actually neutral. I've seen what my videos should look like in Windows, and blacks are black. These are not, not even with VLC, so that's why I had to modify things. Also, I still needed to resolve the issue with SMplayer messing with the colors, and that's my favorite player. I'm using an Intel X3100 (965GM) in case it's important. In any case, it's a solution that's worked for me, so I'm sticking with it. :)

[GFree (gfree678)]

OK, that's three reasons. Guess I can't count. :D

[Zorael (zorael)]

Any chance of your (Fritzsche's) patch getting included into the "real" builds?

         xserver-xorg-video-intel:
           Installed: 2:2.2.1-1ubuntu13
           Candidate: 2:2.2.1-1ubuntu13.4

[Thomas Fritzsche (tf-noto)]

I uploaded pre-build patched version 2:2.2.1-1ubuntu13. However "apt-src" makes compiling as easy as installing an pre-build package.

[Linas U. (linas77)]

Thomas Fritzsche wrote on 2008-06-03:
> I uploaded pre-build patched version 2:2.2.1-1ubuntu13.
I can confirm, that patched xorg from http://linux.pengin.de/xserver-xorg-video-intel_2.2.1-1ubun.deb fixes this bug after restarting X server

[Seva Gluschenko (gvs-ya)]

The similar thing happened to me with gxine on Ubuntu 8.04.1 using "intel" video driver in my xorg.conf, but xvattr reports attributes which seem to be normal.

The problem might be not with XV_* or not only with them. While MPlayer plays anything just fine (except of crashing with sig11 from time to time), first run of gxine distorts colors up to the end of X session (no actual reboot is required, only X session end).

[Okko7 (okko7)]

I've tried to apply the patch linked above, but the problem remains...

[Thomas Fritzsche (tf-noto)]

What is xvattr output before and during totem video playback?

[Conn O Griofa (psyke83)]

Thomas,

Your patch is a good start towards getting this fixed, but it's not working correctly yet. I noticed you said it was a rounding issue, can it be fixed? In case you think that decreasing these values by just a few points isn't bad, remember that the values get decreased upon *each* invocation of totem (and possibly other players), again and again. After about 5-6 invocations, totem causes XVideo output to become washed out.

To illustrate:
1. Fresh start -> first totem invocation
   Name: XV_COLORKEY
- Current value: 66046
+ Current value: 66051
   Name: XV_BRIGHTNESS
    Flags: XvGettable XvSettable
- Current value: 0
+ Current value: -1
   Name: XV_CONTRAST
- Current value: 128
+ Current value: 126
   Name: XV_SATURATION
- Current value: 512
+ Current value: 509

2. Fresh start -> second totem invocation
   Name: XV_COLORKEY
- Current value: 66046
+ Current value: 66051
   Name: XV_BRIGHTNESS
- Current value: 0
+ Current value: -2
   Name: XV_CONTRAST
- Current value: 128
+ Current value: 124
   Name: XV_SATURATION
- Current value: 512
+ Current value: 506

Etc.

Again, my video card: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

[Okko7 (okko7)]

Attached the xcattr output right after installing the patch and after using the Video Player.

Simon

[Thomas Fritzsche (tf-noto)]

Hi Simon,
thanks for the output. I can see you have a different chipset and/or driver in use, e.g. the "max saturation" value should be 1023 if it's the same driver/chip but in your case it's 8191. Sorry this patch can't work then.
Thomas

[Thomas Fritzsche (tf-noto)]

@Conn: I tried this, but I can't reproduce it. With me it stays constant on 511 after the first call.

[Okko7 (okko7)]

@Thomas: So is there anything else I can do to fix this bug on my computer?

The funny thing is that this bug did not appear from the beginning on, but only since about two weeks (may be that I had Video Player and MPlayer running in the same time). So I guess if I'd reinstall ubuntu, it would work again, but isn't there an easier way (for example reinstall only a few files)? I have tried to reinstall only totem, but without success.

Simon

[Daniel Lombraña González (teleyinex)]

Hi, I have discovered that the last version of totem-gstreamer on hardy does the same but with a nvidia card. I have tried totem-xine and everything works perfectly well. However, if you are using totem-gstreamer and in gstreamer-settings you have chosen xv, totem shows wrong colors. The solution to this is avoid using totem-gstreamer or in case you want to use gstreamer use X11 with xv.

[Alan Tam (at)]

Hi everyone,

I am the original reporter. While I do not own the original hardware, I have just got a Thinkpad X61 laptop with a GM965 chip, and it exhibits similar symptoms in hardy.

Unlike the way the bug description is written, I can reproduce this bug using all totem-gstreamer, gxine, gmplayer and vlc; whenever I use the (default) xv driver in any of such players.

In usual cases, I can fix the problem by tuning contrast OR hue to 50% of default. Are there any instruction I can follow to help you figure out the bug?

This bug frustrated me most due to my (wishful) belief that Intel is the best brand supported by the open source driver!

[Okko7 (okko7)]

I've completly reinstalled my computer (Thinkpad T61 with nvidia) over the weekend. As for now the problem desapeared (and I hope it will stay that way). As mentioned above, I think that at a certain moment, I had two different video players open at the same time and this triggered the problem. Now everything is fine again, so probably it would do to just replace a certain file with the original one (instead of reinstalling the whole system). The question is just which file.

Simon

[Bryce Harrington (bryce)]

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

[Jeff Fortin Tam (kiddo)]

The packages provided in the PPA for intrepid in the latest comment seem to have fixed the issue for me, on an intel 3100 GPU.

[Jeff Fortin Tam (kiddo)]

However, with this package, I lose the ability to disable textured video (which causes tearing), which was possible with the package from bug #278318. Ideally, a package that solves both bugs would be nice. From what I understand, tearing-less video playback was not implemented in the 2.5 release series of the intel driver just yet.

[Thomas Fritzsche (tf-noto)]

Got requested to add XV Saturation / Contract path, to get this integrated in hardy:
see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/288859
and http://linux.pengin.de/#xvattr

[Bryce Harrington (bryce)]

Thanks, closing as fixed in Jaunty as per comment #197.

Unfortunately, since this is essentially a cosmetic issue (not a crash / data loss situation), it's unlikely it qualifies for a Stable Release update. However, if you'd like to pursue that, you should follow the directions at https://wiki.ubuntu.com/StableReleaseUpdates

[Julien Olivier (julo)]

The bug is back in Lucid.

[Bryce Harrington (bryce)]

Julien, you are neither the original reporter nor have you provided any evidence that you spotted this specific bug as opposed to some other bug that has similar symptoms. Please do not reopen bug reports in such a case. A better approach is to file a new bug and provide detailed information, and reference this bug report if you suspect it might be a dupe.

[Julien Olivier (julo)]

Bryce,

I have read the detailed description of the symptoms of the bug as originally reported, and I'm pretty sure my bug is exactly the same as the reporter. I also did have this bug in Jaunty, but not in Karmic, and then again in Lucid. So, what I said is pretty accurate: the bug that was fixed before re-appeared in Lucid. I don't think it's useful to re-report bugs in case the of a regression.

[JockeTF (jocketf)]

I'm affected by this bug in Ubuntu Natty using XV Overlay on Intel i945GM.