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

xorg.conf

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?

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.

Urge, looks very saturated.

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

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.

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?

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/...

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.

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

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?

Both works now. I cannot distinguish which is better.

Excellent news. I'll whip up a patch.

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).

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

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

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.

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

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).

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

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.

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.

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

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

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

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
...

Will you upload to dapper a new default constrast?

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

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.

Ditto Carlos (the post above).

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

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

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.

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.

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.

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

I have an Intel 910 GM chipset, btw.

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

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

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

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

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: +44 (0)7729 980173 - (No signal in the lab!)

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

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.

@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.

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?

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%.

@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

@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?

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.

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".

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.

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. :>

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. :)

@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.

@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. :)

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

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

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

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

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).

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

What is xvattr output before and during totem video playback?

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)

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

Simon

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

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

@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

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.

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!

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

[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

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.

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.

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

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

The bug is back in Lucid.

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.

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.

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