Summary: | [TV]Flicker when launching applications in the 2.4-branch | ||
---|---|---|---|
Product: | xorg | Reporter: | Timo Jyrinki <timo.jyrinki> |
Component: | Driver/intel | Assignee: | Wang Zhenyu <zhenyu.z.wang> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | high | CC: | anarsoul, b.buschinski, colin, diegoe, hasso, inform, jbarnes, mozilla_bugs, remi, stephane, unggnu |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 18858, 20276 |
Description
Timo Jyrinki
2008-09-02 02:56:37 UTC
Just about every Gentoo user who has contacted me about issues with the 2.4.2 release has seen flicker (among other various issues). So I can confirm this on xserver 1.4.2 with just about every Intel chipset from 855GM (my own laptop) to 965 chips. Another easy way to reproduce a flicker is xbacklight. The _first_ execution of xbacklight after boot (I have keys binded to "xbacklight -10" and "xbacklight +10") produces very visible flicker. It should be noted that for me it affect any GTK application. Most KDE apps are not affected. I believe this is due to the way GTK interacts with the RandR API. Hopefully Jesse will have a shiny, flicker free fix shortly :D > --- Comment #3 from Colin Guthrie <fdo@colin.guthr.ie> 2008-09-02 03:58:14 PST ---
> It should be noted that for me it affect any GTK application. Most KDE apps are
> not affected. I believe this is due to the way GTK interacts with the RandR
> API.
>
Anything calling XRRGetScreenResources will do that.
Downstream bug at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/256142 hints at the commit http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=7b6f4d22211d71480caf6335a3eacaacff369371 in git master and 2.5 branch fixing the problem. I cannot test it right now, but if that's true this only affects 2.4 users (which is currently about everyone since 2.5 hasn't been released). I can confirm that cherry picking the commit in comment 5 does indeed seem to solve the problem for me. Confirming too. I guess Intel people can decide if they see this worthwhile putting to 2.4 branch or just marking "fixed". Meanwhile Ubuntu also put the mentioned commit on top of their current 2.4 driver in the current development version (8.10). Probably other distros will follow / have followed if not changing to 2.5 series. I still get flicker the first time I start mplayer with Xv output, but for "regular" applications, the flicker seems to be gone. I'll be definitely be pushing that patch to our package, but having it in a nice release would be best. I'll let you know if it fixes issues for Gentoo users who have reported flickering. However, is there anything I can do to help track down the Xv flicker? Thanks (In reply to comment #8) > I still get flicker the first time I start mplayer with Xv output I don't seem to see this personally, but I've only tested with Compiz + Xv + Video plugin + mplayer compiz extensions, so this may be clouding the core issue. I've already added this patch to the Mandriva packages for wider testing. My own tests are done on an 855GM laptop with plain old metacity (no compositor, yet...), only the LVDS is active and nothing is plugged in on the VGA port. I can confirm that I can still see some flickering with that setup. I've also pushed the patch to Gentoo's package tree for wider testing, I'll report back when I have more feedback. Thanks I can confirm the flicker too with the patch from gentoo tree (xf86-video-intel-2.4.2(patched), 945GM, git xorg-server 1.5-branch) On my maschine I can easily reproduce the flicker by starting "powertop", after the first 5 seconds it flickers once, as root and user. (started in konsole kde-4.1.0) Looks like the old workaround "FramebufferCompression" "false" doesnt work in this case Can someone else reproduce the flicker with powertop? Yes with powertop but also with xrandr. For example with xrandr --prop I believe that I found a way to remove the flickering by forcing a video mode on a non-connected output. See my comment in launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/256142/comments/30 Zhenyu, it looks like we need 2.4.3 release for this? I'm still getting reports from some users that problems exist even with the patch (much like other reports in this thread). Some people are getting issues with external monitors and others still with lvds See https://qa.mandriva.com/show_bug.cgi?id=43596 and https://qa.mandriva.com/show_bug.cgi?id=42826 Are there any other commits I could try backporting? I have some news on this. It seems that xserver 1.5 solves/hides some of the flickers (I have almost none now on my 855GM) but that varies with different chips, it seems it does not help on 945... I can reproduce flickering on my gma950 with latest patched xf86-video-intel (2.4.2-r1 in gentoo, with applied patch to avoid flickering). Even worse - with 2.4.2 sometimes screen becomes black, and I can't get Xorg working until reboot (I can switch back to console, but X won't start anymore...). I can provide any additional info if you need. P.S. I'm just wondering why this bug still is not fixed if it is reproduceble on almost every intel chipset? *** Bug 17937 has been marked as a duplicate of this bug. *** Can any of the reporters confirm if this still exist with 2.5.0 release? Yes, bug still exists on xf86-video-intel-2.5.0 on gma950 I.e. launching app with wine produces flicker. (In reply to comment #18) > Can any of the reporters confirm if this still exist with 2.5.0 release? I still get flickering when launching apps which use xv for the first time. Following launches are fine. Thanks I can confirm this on git 2.5 branch. Launching totem or anything else using XV will make the whole screen "blink" once. If this issue still exists with recent release that is not related to Xv, please reopen this. If only with Xv, a new bug should be open for it. Thanks. Issue is still being seen: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/278146 (In reply to comment #23) > Issue is still being seen: > > https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/278146 > Which xf86-video-intel version is used in the Ubuntu bug report? In the XorgLog.txt there I see it's still 2.4.1. http://launchpadlibrarian.net/20841507/Xorg.0.log.old The 2.5.1 version of Jaunty. Do you need anything else to nail down the problem? I have run ubuntu 8.10 livecd in 915GM and 945GM here, xrandr and totem video work fine. Can you say more about how it can be produced? Does it only happen with 915GM and with VGA/TV connected or something? We might steal pipe for output detect, that might cause flicker, but should be short, once, and happen only on external output, which doesn't look like the symptom here... (In reply to comment #26) > Do you need anything else to nail down the problem? > could you try the workaround in bug# 13502 comment# 9? If yes, it's a dup then. Seems to work after a short test, at least when I run xrandr. Could the other posters confirm it? 1. add Option "Monitor-TV" "TV" to your xorg.conf device section. 2. add a monitor section Section "Monitor" Identifier "TV" option "ignore" "true" EndSection I am going to make more tests soon. Thanks! For my case this could be marked as a duplicate. But this doesn't happen in Hardy with intel 2.2.1 and previous versions. *** Bug 13502 has been marked as a duplicate of this bug. *** With commit 4e95327323e3d081b565147f7738eb49c28542bc Author: Zhenyu Wang <zhenyu.z.wang@intel.com> Date: Mon Mar 16 09:30:22 2009 +0800 TV: force TV as connected with TV_Connector option In order to bypass failure in TV load detect, TV_Connector option will always force TV as connected with user specified connector type. 'TV_Connector' option is provided for forcing TV connect to bypass load detect which caused flick. This option can be used as workaround for TV detect issue which we have to steal pipe and do load detect. It doesn't seem to be possible to apply the commit against the 2.6.3 branch. Is there any patch to get the old behavior with 2.6.3 or is the only possibility the xorg.conf workaround atm? I have tested the 2.7.0 driver and the problem still appears without the xorg.conf options. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.