Re: Did anyone refile bug for Flash Player shows green/purple in compressed window?

[John Hupp]

On 8/16/2013 10:35 AM, John Hupp wrote:
On 8/14/2013 6:20 PM, John Hupp wrote:
On 8/13/2013 4:47 PM, Nio Wiklund wrote:
On 2013-08-13 20:46, John Hupp wrote:
Here is a fresh summary (with one new result) of the problem on 
machines
with integrated Intel graphics in which Adobe Flash Player 11.2 
displays
only with shades of purple and green in a horizontally compressed 
window.

(My current example is a Dell Dimension 2400 on Raring.)

In my testing with the Intel driver using its default acceleration:
- Flash 11.2 works on Quantal with the 3.5 kernel
- Flash 11.2 works on Raring with the 3.5 kernel **
- Flash 11.8 works on Raring with the 3.8 kernel (in Chrome)
- Flash 11.2 fails on Raring with the 3.8 kernel
- Flash 11.2 fails on Saucy with its default kernel

Disabling Flash *hardware* acceleration altogether (via R-click in the
Flash display window: Settings: General tab) did not fix the problem.

Setting the Intel driver's acceleration method to UXA rather than its
default SNA *always* fixes the Flash problem, but causes a garbled 
login
screen under LightDM that so far has no workaround.

I also tried one possible fix for the default Intel SNA acceleration
using the TearFree option.   I created
/etc/X11/xorg.conf.d/20-intel.conf with contents:
     Section "Device"
        Identifier  "Intel Graphics"
        Driver      "intel"
        Option      "AccelMethod"  "sna"
        Option      "TearFree"    "true"
     EndSection
But this had no effect.

There was a helpful bug report on file at
http://bugs.launchpad.net/ubuntu/+source/linux/+bug/1178982. (Note 
that
it was filed against Linux.)  Workarounds posted there were to change
the Xorg acceleration method to UXA, or boot with an older kernel.  
The
bug was closed only because the original poster didn't have possession
of the machine anymore.

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


** Flash sort of works in this case.  The colors and window dimensions
are normal.  But there were other odd display-related effects.  Raring
booting to a a low-resolution desktop with the mouse pointer 
locked.  I
started Chromium via the keyboard and the flash video played long 
enough
for me to see normal colors/dimensions, but then it locked up the 
browser.

In my interest in testing under Raring with an older kernel, I 
initially
tried to use a Live USB with persistence and follow the 
instructions at
https://wiki.ubuntu.com/Kernel/MainlineBuilds for installing older
Mainline kernels.  But this failed to install/run properly with the 
Live
USB.  And besides, I wanted to use Stock rather than Mainline kernels.
So I installed a different hard drive, installed Quantal, then 
upgraded
to Raring.  I suppose if I had run Software Update under Quantal, I
would have gotten a 3.6 kernel to test as well.  As it was, Raring's
Software Update did not install a 3.6 kernel, but only the kernel
updates proper to Raring.

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


Looking at the above behavior of the "black box" without nearly enough
technical knowledge, all I can see at this point is that there is an
adverse interplay between certain versions of the kernel, the Intel
driver, and Flash.  (And I grant that I have not documented the 
versions
of the Intel driver in the various cases, but no one has given me any
indication that the Intel driver version is an issue here.)



Hi John,

If I remember correctly, it does not work to install other kernels in
persistent live systems. You can update and or install other program
packages, but not kernels. An installed system on a USB drive will not
suffer from such problems.

Were you able to use that method to update kernels in Raring?

Best regards
Nio

Thanks, Nio.

Though I still haven't tried installing other kernels in an installed 
system on a flash drive, today I used the method at 
http://wiki.ubuntu.com/Kernel/MainlineBuilds to test other mainline 
kernels on the temporarily-installed hard drive I describe above.  
(I'd still like to know if there is a similar archive of stock 
kernels somewhere, though perhaps all the stock kernels are right 
there, identified by 
http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html 
<http://kernel.ubuntu.com/%7Ekernel-ppa/info/kernel-version-map.html>.)

I found that Flash 11.2 works normally on Raring with the last 3.6 
and 3.7 mainline kernels, but fails with the latest mainline kernel, 
3.11.0-031100rc5.

Together with my earlier test results (above), this seemed to me to 
provide enough indications to file a bug against the kernel, which I 
have just done at 
http://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455.


After a little back-and-forth concerning my bug report, one of the 
Buntu kernel maintainers suggested that I move the bug upstream.

Step #1 in that process is to send a specifically formatted report to 
the email list of the team for the relevant kernel module.  So after a 
little research, it seemed that this would be the Intel DRM Driver.

The online archive of the thread begins with my email at 
http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html

Happily for me as regards my time investment on this problem, but 
perhaps unhappily as regards fixing the problem, Chris Wilson from the 
Intel Open Source Technology Centre rendered this summary judgment in 
a reply:

"It's a flash bug. They ignore the format of the Window that they 
PutImage to. (Worse, they create an image of the right depth or else X 
would reject the PutImage with a BadMatch and then render incorrect 
pixel data into it.)"

If his assessment is on the mark, and if you have a PC with affected 
Intel graphics that you want to display Flash content, it would seem 
that the only recourse is to install a supported non-Intel video card.


Good news.  I continued to pursue this with the Ubuntu and upstream 
kernel teams, and Daniel Vetter from upstream has now supplied a good 
workaround.

He wrote:
-------------
Still a flash bug. This commit simply enables rgb555 in the kernel, 
which sna likes to use on gen2/3. Flash is just too dense and always 
presumes xrgb8888.

Adding

Section "Screen"
        Identifier "igd"
        DefaultDepth 24
EndSection

to your xorg.conf will work around.
-------------

And doing so did successfully work around the behavior for the Intel 
graphics machines I reported on.

I note also that just the snippet above in an otherwise blank xorg.conf 
will do.  And many users, like me, will have no existing xorg.conf but 
will have to create one, such as I did at /etc/X11/xorg.conf (though 
there are many other locations where X will find the configuration).

--
Lubuntu-users mailing list
Lubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/lubuntu-users