siverlight and unity3d via pipelight: content very dark

Bug #1415219 reported by iw on 2015-01-27
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Pipelight
Undecided
Unassigned

Bug Description

Hallo,

after the last updates the videos (streamed by maxdome.de using silverlight5.1, all the videos) and the graphics in online browser game Chima-Online (eu.chimaonline.com/de#xlink using unity3d) are much darker than before with very high contrast.
This happens in Firefox-35 as well as in Midori 0.5.8.

----------------------------------------------------------------------------------------------------------------------------------------------------------
edit: shortened this posting and moved the system information into an attachment: https://bugs.launchpad.net/pipelight/+bug/1415219/comments/6

iw (iweisheit) on 2015-01-27
description: updated
iw (iweisheit) on 2015-01-27
description: updated
description: updated
iw (iweisheit) wrote :

...and thank you very much for developing this software! It helps me a lot...

Michael Müller (mqchael) wrote :

Hi,

I just tested the maxdome link you wrote in the bug report and I was unable to detect any differences between an older wine version and the current version of wine. I fear that the problem only occurs with specific graphic drivers since you are using the open source AMD/ATI driver and I am using the proprietary nvidia driver. Maybe we know more if other users also encounter the same problem. It might be useful if you could attach a screenshot of the issue.

Could you please try to downgrade to the previous wine version to verify that it is really caused by the wine upgrade? The following commands should downgrade to the previous version:

wget https://code.launchpad.net/~pipelight/+archive/ubuntu/stable/+files/wine-staging_1.7.34-1~ubuntu12.04.1_i386.deb
wget https://code.launchpad.net/~pipelight/+archive/ubuntu/stable/+files/wine-staging-i386_1.7.34-1~ubuntu12.04.1_i386.deb
sudo dpkg -i wine-staging*.deb

Michael

jetrca (knurz) wrote :

Hi!

I had the same problem.

I followed your advice (in a naive way as you can see under http://goo.gl/1B77vH ), and as a matter of fact the maxdome-videos returned to the normal state.

Yours, Jetrca

Sebastian Lackner (slackner) wrote :

@jetrca: Could you please also provide more details about your graphic card. The section "Checking OpenGL ..." from "pipelight-plugin --system-check" should be sufficient.

jetrca (knurz) wrote :

Thank you for coping with mmy problem.
I hope, this is what you asked for:

Checking OpenGL ...
OpenGL Vendor: Tungsten Graphics, Inc
OpenGL Renderer: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2
OpenGL Direct Rendering: True
OpenGL: PASSED

Checking fonts ...

iw (iweisheit) wrote :

Hallo,

in order to shorten my original posting I moved the output of my system into an attachment, hope this is better :)

description: updated
iw (iweisheit) wrote :

Hallo,

you asked about other users... well, I have a conversation in the ubuntuusers.de-forum regarding this topic, there is at least one more user, I assume you are native german speakers so here is the link:
http://forum.ubuntuusers.de/topic/maxdome-via-pipelight-bild-zu-dunkel/

He or she uses a different graphic.

For more information here some detailed information about my graphic:

wir@zeitmaschine:~$ lspci -nnk | grep -i VGA -A2
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RS690 [Radeon X1200] [1002:791e]
 Subsystem: ASUSTeK Computer Inc. Device [1043:8287]
 Kernel driver in use: radeon
wir@zeitmaschine:~$ glxinfo | grep 'OpenGL version string'
OpenGL version string: 2.1 Mesa 8.0.4

hope it helps, best regards!

Michael Müller (mqchael) wrote :

Hi,

i just looked at your log again and saw one error related to samplers:

fixme:d3d:state_zenable Z buffer disabled, but ARB_depth_clamp isn't supported.
err:d3d:wined3d_sampler_init >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from sampler creation @ sampler.c / 101

Wine changed some code related to wined3d_sampler and I expect the problem was introduced by these changes.

Michael

Sebastian Lackner (slackner) wrote :

Is the problem also visible when visiting the DRM-free "smooth streaming demo"?
http://www.iis.net/media/experiencesmoothstreaming

Are here people familiar with doing a git bisect / regression test, and have already a working wine build environment (or can set it up)? I am pretty sure that this is problem was introduced in upstream Wine (recent changes to the sampler code), but we can't forward this issue directly there because "wine-staging" contains various additions on top of vanilla wine, like DXTn texture compression support. Most likely unrelated, but upstream developers expect a bug report reproduced with either vanilla wine or at least minimal changes.

In order to do the regression test it is necessary to have a working Wine build environment. It might be easier to bisect the problem in Unity3D (if the problem is easily visible), because it doesn't require any patches. If Silverlight is better for reproducing this is also fine, but for DRM websites it is necessary to apply a bunch of changes on each intermediate step, to make sure that they are still works properly.

More information about doing a regression test with wine:
http://wiki.winehq.org/RegressionTesting

Please join our channel #pipelight on freenode if you would like to give it a try or have any questions about that. For Ubuntu 64-bit users its unfortunately a bit complicated because the build dependencies are not multiarch ready.

More information about building 32-bit on 64-bit systems:
http://wiki.winehq.org/WineOn64bit
(32-bit wine is sufficient, but even that is complicated depending on the used distribution)

iw (iweisheit) wrote :

Hallo,

I just downgraded to 1.7.34 and now I can confirm that the videos appear normal. The logs for both versions are following in the next posts.

iw (iweisheit) wrote :

log for dark videos

iw (iweisheit) wrote :

log for normal videos

iw (iweisheit) wrote :

Now- this is weird:
the demo on http://www.iis.net/media/experiencesmoothstreaming appears normal with both 1.7.35 and 1.7.34 ....

Sebastian Lackner (slackner) wrote :

Since noone of our developer team is able to reproduce this issue, we really need more information from users which are affected by this bug (see comment #2, comment #9).

Changed in pipelight:
status: New → Incomplete
iw (iweisheit) wrote :

see comment #10 and #14 :)

I downgraded and set the packages on hold. This workaround works for me.
Please ask if you need any more logs. And thank you for taking care.

Sebastian Lackner (slackner) wrote :

The information provided so far is unfortunately not yet sufficient. Although we have access to Maxdome and of course also tested Unity3D apps we can't reproduce the issue on our machines. Michael asked for screenshots in comment #2, but even more important is that we need a proper regression test as described in #9.

For those unfamiliar how pipelight works, it uses a modified version of wine (http://wine-staging.com). In this case the regression is most likely not introduced by us, but also present in upstream Wine (http://winehq.org). In upstream Wine there are a lot of changes between each release, so its not possible to "guess" what went wrong. Wine developers also only have limited hardware available, so the person who introduced that problem is most likely not aware of that his changes are not fully compatible with old graphic cards. To find out what the problem is exactly it has to be determined by using a regression test, then it has to be reported to the corresponding developers. Sooner or later they'll probably come up with a patch, which also has to be tested by someone with such an old graphic card. And if that works, then a proper fix can be added for future versions.

We can't really proceed without the information requested in comment #9, otherwise all we can do is wait, and hope that it is magically fixed again in future versions or someone else reports it first. ;)

iw (iweisheit) wrote :

Hallo, unfortuneatly I cannot help you with a regression test (I had to google it :D ), but I can provide a screenshot illustrating the problem.
I hope it will help you... Best regards!

iw (iweisheit) wrote :

ok, I will give it a try. But I will need help for sure. I will contact you on freenode. But not today :)

Michael Müller (mqchael) wrote :

Henri Verbeet had the idea that the problem might be related to the mesa driver handling sRGB textures different during a blit than for example the nvidia driver . So I took the image and approximated a sRGB -> RGB conversion by increasing the gamma to 2.2 (this value should be suitable for most screens).

Except some artifacts introduced by this approximation, the image pretty much looks like what we expect. The theory that the problem is related to sRGB seems to be valid.

iw (iweisheit) wrote :

Hallo,
I just finished the regression test with an unpatched vanilla-wine. (thanks for the support :)).
Output of git:

c6232e1d111ae8929c53c02211cde4a9777311fd is the first bad commit
commit c6232e1d111ae8929c53c02211cde4a9777311fd
Author: Henri Verbeet <email address hidden>
Date: Thu Jan 15 17:19:06 2015 +0100

    wined3d: Create GL sampler objects for wined3d sampler objects.

:040000 040000 bc3c73c3d3e26f93417066a5fb249c5c881c6091 0d3e3196edd01a246315bd6d5458217334d044c5 M dlls
:040000 040000 cb5a94b6d6d6f6aff0cd35355cb6dd26435ff02e 349d57093d37299200af4e9aa178084ac15bcdaf M include

Do you need any additional information? Tested with http://virtualautonomy.com/unity/light_shadow/

Michael Müller (mqchael) wrote :

Hi,

the output of glxinfo would be great since the problem seems to related to the driver / available opengl extensions and some log of using the unity demo with the broken commit applied. This should definitely be sufficient to open a bug report. Do you want me to open a bug report at winehq.org after you added the information or do you want to do this on your own?

Michael

Changed in pipelight:
status: Incomplete → Confirmed
Sebastian Lackner (slackner) wrote :

Besides opening an upstream bug report at winehq.org, I already told one of the d3d developers privately about this issue.

He would like to know if the following patch (applied on top of 1.7.35) shows a different behavour:
http://paste.debian.net/plain/143209

When you have still checked out wine git, you can do:

git bisect reset
git checkout master
patch -p1 < patch_to_downloaded_file

afterwards compile & install, then test again. Thanks for all your effort by the way.

iw (iweisheit) wrote :

Hallo,

please feel free to open the bug report by yourself.
Attached is a log for 'firefox http://virtualautonomy.com/unity/light_shadow/'.

iw (iweisheit) wrote :

...and here my glxinfo.

iw (iweisheit) wrote :

...and not good with the patched wine (1.7.35-24-g3873c93).

Michael Müller (mqchael) wrote :

You mean the patch does not workaround the issue and the output is still identical?

I see in your glxinfo output that you are still using Mesa 8. I would recommend to upgrade to Mesa 10 using the lts backports since this bug might already been fixed in newer driver versions. You can install a more recent xorg/mesa version using:

sudo apt-get install --install-recommends linux-generic-lts-trusty xserver-xorg-lts-trusty libgl1-mesa-glx-lts-trusty

( see https://wiki.ubuntu.com/Kernel/LTSEnablementStack )

I am not sure whether the kernel upgrade is necessary, but it shouldn't have any disadvantages.

Michael

iw (iweisheit) wrote :

Hallo, sorry, I forgot to add the log.

IMHO your idea from comment 2 and setting the packages on hold is more reasonable than changing the driver. The display driver works out of the box and there are no problems until now and your simple workaround works fine. I'm not very happy with the hold status though.
But I'm pleased to help you analyzing the problem, and: it is great fun :) Pleas ask for additional tests if there are any neccessary.

Michael Müller (mqchael) wrote :

Hi,

at the moment it looks like the wine developers consider this to be a driver bug and if no one is willing to test whether it works with a recent driver version, they most probably do not care about it. You can't fix a driver bug within Wine, the change in the sampler is necessary to support new features in Wine and therefore you can't simply revert it.

Michael

iw (iweisheit) wrote :

Hallo,

I'm not sure if I understand you: if no one is willing to test whether it works with a recent driver version, they most probably do not care about it -> they do care about this if I test it?
I'm quite conservative in adding sources to my system which is very stable so far, but if it help I can update it... I will downgrade anyway but its worth a test :)

iw (iweisheit) wrote :

Hallo, I tested with Mesa 10 (new kernel was mandatory). The demo was not dark (that means good) when using the *unpatched* vanilla-wine.
But it was very slow so I had to downgrade to Mesa 8 again. (I need a running system for my familiy). There are more tests in the evening.
Regards!

iw (iweisheit) wrote :

Hi,

I just added an entry in the problems-section in the german uu-wiki: http://wiki.ubuntuusers.de/Pipelight#Problembehebung.
This mesa 8 driver is part of the LTS-versions 12.04.0 and 12.04.1 which are supportet until 04/2017, so maybe it is better to add some dependencies to your package?

best regards!

Josh (josh-hoobler) wrote :

I'm still having this same problem. I'll happily downgrade but I can't find the previous version of wine staging using the links above. Can someone please direct me where to find old versions?

Michael Müller (mqchael) wrote :

Launchpad removes old builds after some time and therefore the files are gone. Downgrading wine staging is also not the correct solution since you will miss new features. I am currently working on GPU decoding for example which will hopefully be part of the next release (only flash at the beginning). The correct solution is to upgrade Mesa since this is the package containing the bug and it won't help to blame wine just because they are using functions that are supposed to work correctly.

Sebastian Lackner (slackner) wrote :

I would like to add that its of course also possible to build older versions of wine-staging, but I wouldn't recommend it. For wine-staging there are no stable releases, the patchset changes very frequently and even though 1.7.34 didn't have this issue yet, it might have all kind of other issues which have been fixed in the meantime.

Besides GPU decoding there were recently also a couple of other fixes related to Silverlight applications which heavily make use of network functions.

Wine cannot workaround every driver bug, this is also the answer we got when we talked to the other Wine developers. The correct solution is to update the graphic card drivers to a newer version, where the problem doesn't exist.

One workaround for those who want to continue using very old graphic drivers, you can disable GPU acceleration by running:

/usr/share/pipelight/scripts/configure-silverlight

Then type "disable" and afterwards "abort" (or use CTRL+C) to terminate the program. This should also fix it.

Eric van der Maarel (etic) wrote :

The upgrade to Mesa 10.1.3 as explained in

https://wiki.ubuntu.com/Kernel/LTSEnablementStack

in my 12.04 works great. I have a [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series].
Not even slow...

neo (csae2608) wrote :

me too having this issue on debian wheezy 64bit and pipelight via intel hd4000 . way too dark; this never happened so before on this machine; i used to install pipelight several times, but time, something went different, and it is dark. i too use useragentoverrider with firefox 29 windows profile

To post a comment you must log in.