<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 8/10/2013 6:28 PM, John Hupp wrote: </div> <blockquote cite="mid:5206BE71.1000002@prpcompany.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <div class="moz-cite-prefix">On 8/10/2013 3:52 AM, NikTh wrote: </div> <blockquote cite="mid:a45a588291844ca6db83d05089227e24@openmailbox.org" type="cite"> <blockquote type="cite">I have two lines of attack on this problem: 1) Trying to file a good bug report concerning the Flash behavior, and 2) Trying to get the workaround fully working. Using UXA acceleration solved the Flash problem but left me with a garbled login screen. So I took the suggestion above to test with Chrome and its integrated current version of Flash. I booted the Raring Live CD so I could preserve my hard drive installation as-is, installed Chrome from Google's web site, and played a YouTube video. It worked! Chrome was running Flash 11.8 as I recall. That would seem to be an important step forward in pinning down what's happening, but I don't see that it leads to a firm conclusion. I wanted to stop testing briefly and get this much out to the group, also to solicit some advice on other things I'm thinking about or trying. Another suggestion was to see what happens with Saucy alpha 2 on this hardware. I created a LiveUSB on a 1 GB drive with 100 MB for persistence, but the FlashPlugin-Installer is not installed by default and I couldn't get it installed via Synaptic or Lubuntu Software Center, both failing with no-space-available-on-the-drive sorts of errors. I also tried to get Flash 11.2 directly from Adobe, but it required that I Choose an Application to handle the APT installation, and I couldn't find anything that would work (though maybe it was really just running into the same no-space-available sort of error). So perhaps I should create another LiveUSB on a 4 GB drive with yet more room for persistence, or maybe I burn a Live CD. Another angle: It was reported that another workaround for the Flash behavior was to use an older kernel. I have nothing installed older than 3.8. So I'm wondering if I can temporarily install some older kernels and how to do it -- also wondering if that's a good idea. Another thing that seems reasonable to try is to boot the Quantal Live CD on this hardware and see what happens. I believe that runs the 3.5 kernel. If I can get Flash 11.2 on there I might learn a little something. I also want to try uxa acceleration on both Quantal and Saucy and see what happens. --John </blockquote> You cannot file a bug report against flash player. Ok, maybe you could, but it wouldn't a good option. Flash player is not a project of Ubuntu. As I see it, and as you wrote that worked on Chrome (flash 11.8) then, there could be a problem with the current outdated flash version in Linux in combination with some missing packages in Lubuntu, a problematic kernel version, or in combination with old intel card and its drivers ? (probably the latest). We cannot do anything for Flash Player, but we can do something with intel driver and this is the UXA acceleration as you mentioned. We could locate the problem with LightDM and fix that too. Have you tried another Display Manager ? Also try to add the option Option "TearFree" "true" in 20-intel.conf file. And then add the i915.semaphores=1 option as a boot option via grub (/etc/default/grub). --NikTh-- </blockquote> Running with the suggestion above to see if a couple options could prevent the garbled login screen produced by uxa accleration: I created the xorg.conf.d directory in /etc/X11, then created /etc/X11/xorg.conf.d/20-intel.conf. I copied the contents of /etc/X11/xorg.conf into that to set uxa acceleration, then deleted /etc/X11/xorg.conf. After the Option line that sets uxa acceleration, I added the line: Option "TearFree" "true" Then in /etc/default/grub, in the GRUB_CMDLINE_LINUX_DEFAULT statement, I added i915.semaphores=1. Then I ran sudo update-grub. At reboot I had the same garbled login screen as before. <hr size="2" width="100%"> I booted the Quantal 12.10 Live CD, opened Synaptic and reloaded it, installed Flashplugin-Installer (to install Flash 11.2), and found that Flash colors and window dimensions were normal. This ran the 3.5 kernel. Obviously more than one factor differs from the Raring setup, but it moves toward exonerating Flash 11.2 and perhaps implicating the newer kernel. Then a test to see if uxa acceleration garbles the login screen: I created a Quantal Live USB (4 GB) with 1 GB of persistent storage. Because I had read somewhere that some edited settings are not saved even with persistence under the default user, I created a second user (Administrator and member of sudo group). I also created xorg.conf to set uxa acceleration. Though both the default user and the second user were set to ask for the password at login, the login screen did not appear at boot. (*Anyone know why?*) But choosing Log Out from the desktop, I arrived at a clean login screen. That prompted when to wonder what would happen in the Raring hard drive installation if, though the initial login screen is garbled, I logged out again. As with Quantal, I found that I logged out to arrive at a clean login screen. So under uxa acceleration something happens at initial boot, at least in Raring, to garble the login screen, but that same something does not happen at log out. <hr size="2" width="100%"> Next I created a Saucy alpha 2 Live USB (8 GB) with 1 GB of persistent storage. I opened Synaptic and reloaded it, installed Flashplugin-Installer (to install Flash 11.2), and found that Flash colors and window dimensions were bad as previously described. I created a second user (of type Administrator, and member of the sudo group). I also created xorg.conf to set uxa acceleration. Though both the default user and the second user were set to ask for the password at login, the login screen did not appear at boot. (*And again, anyone know why?*) Instead it booted to a black screen with the pointer visible, but moving the mouse and hitting keys did not bring up the desktop. Ctrl-Alt-Del produced a garbled desktop with the Task Manager open. I closed that, successfully started Firefox in a normal-looking window, and played a YouTube video with normal colors. Choosing Log Out from the desktop, I arrived at a clean login screen. So uxa acceleration once again solves the Flash problem but produces its own buggy side-effects, and once again something happens at initial boot, to garble the desktop rather than the login screen which does not appear, but that same something does not happen at log out. <hr size="2" width="100%"> The above results are added to a previously posted test on Raring with the 3.8 kernel and Chrome with Flash 11.8 in which Flash performance was as it should be. <hr size="2" width="100%"> 1) If I have recorded my observations correctly, we have, on the Intel graphics/driver with default acceleration: - Flash 11.2 working under Quantal with the 3.5 kernel - Flash 11.2 failing under Raring with the 3.8 kernel - Flash 11.2 failing under Saucy - Flash 11.8 working (in Chrome) on Raring with the 3.8 kernel 2) UXA acceleration always fixes the Flash 11.2 problem, but always causes a garbled login screen (or garbled desktop if there is an auto-login). However the login screen is always clean if one logs out after initial boot. I don't see enough here to arrive at any conclusions, but maybe one of you can discern more from the above. And as NikTh suggested, it would be useful to see what happens with another display manager. I would be happy to try something there on a Live USB with persistence, but have some preference not to experiment like that on the hard drive installation unless it's easy to undo again. (I know, I could run another Clonezilla image first, so I merely say "preference.") And I would appreciate some clues or a HowTo on proceeding with that. It would also produce a slightly cleaner experiment if I could make the Live USB setups boot to a login prompt rather than auto-logging into a desktop. --John </blockquote> I was somewhat surprised to find out that disabling Flash hardware acceleration altogether (via R-click in the Flash display window: Settings: General tab) did not fix this problem either. </body> </html>