Summary: | Dual-Core CPU E5500 / G45: RetroArch refuses to go back into windowed mode after fullscreen | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Diego Viola <diego.viola> | ||||||||||
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | CC: | intel-gfx-bugs | ||||||||||
Version: | XOrg git | ||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | G45 | i915 features: | |||||||||||
Attachments: |
|
Description
Diego Viola
2016-07-01 18:56:02 UTC
Created attachment 124848 [details]
lspci
Created attachment 124849 [details]
cpuinfo
*** Bug 93844 has been marked as a duplicate of this bug. *** Just did a git-bisect of v4.5 and v4.6 on this machine and the end result is the same as in my T450. [diego@myhost ~]$ cd linux [diego@myhost linux]$ git bisect bad 7ac7d19f808697abe6658c64c96868f728273f9c is the first bad commit commit 7ac7d19f808697abe6658c64c96868f728273f9c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Apr 17 20:42:46 2016 +0100 drm/i915: Avoid stalling on pending flips for legacy cursor updates The legacy cursor ioctl expects to be asynchronous with respect to other screen updates, in particular page flips. As X updates the cursor from a signal context, if the cursor blocks then it will stall both the input and output chains causing bad stuttering and horrible UX. Reported-and-tested-by: Rafael Ristovski <rafael.ristovski@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94980 Fixes: 5008e874edd34 ("drm/i915: Make wait_for_flips interruptible.") Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/1460922166-20292-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit acf4e84d6167317ff21be5c03e1ea76ea5783701) Signed-off-by: Jani Nikula <jani.nikula@intel.com> :040000 040000 ffd5371b8faffb065a2cd8c5624127ce2a03284c a19fe78a340ba89e0c206e96b65d5c426eb0e150 M drivers [diego@myhost linux]$ Created attachment 124865 [details]
git bisect log
Created attachment 124866 [details]
lspci -nn
Linux v4.1, v4.2 and v4.3 is also broken (i.e. retroarch hangs when trying to switch to windowed mode) on this machine. This is no longer an issue with the latest xf86-video-intel, especially after they added --with-default-dri=3 by default. https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xf86-video-intel&id=cd3de9bb45a9ab84383541ed45ee6f0c10ea8798 Closing. This is still a problem after installing xf86-video-intel and setting Option "DRI" "2" in /etc/X11/xorg.conf.d/20-intel.conf. Arch Linux have defaulted to DRI3. Pressing F in RetroArch then freezes X. Any ideas, please? What's the difference between this and bug 96767? (In reply to Jani Nikula from comment #12) > What's the difference between this and bug 96767? The end result/effect is basically the same: when pressing F 3-4 times (toggle fullscreen), RetroArch causes my graphics to freeze, only a chvt at that point unfreezes X. I've seen this problem only with DRI2 and SNA, when using DRI3 (modesetting) it's fine. I also originally reported this problem on Bug 93844 but I ended up doing a lot of git-bisecting of the Linux kernel on 2 separate computers I have, so I ended up opening separate bug reports because the culprits in the git-bisect are different, but the result is the same. |
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.