[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#925555: linux-image-4.19.0-4-amd64: [regression] No graphics on some IvyBridge / Haswell systems



Hi,

On Mon, 6 May 2019 12:08:03 +0100 "Rebecca N. Palmer"
<rebecca_palmer@zoho.com> wrote:
> Control: forcemerge -1 926193
> Control: tags -1 upstream patch
> Control: retitle -1 linux-image-4.19.0-4-amd64: [regression] No graphics on some IvyBridge / Haswell systems
> Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=109806
> 
> (Summary of the merged bugs - I haven't tried any of this myself)
> 
> Workaround for individuals (from leandroembu) - install 
> xserver-xorg-video-intel and copy 
> /usr/share/doc/xserver-xorg-video-intel/xorg.conf to /etc/X11.  This is 
> probably not suitable as an official fix as it may cause problems on 
> newer hardware (e.g. #860133).
> 
> Possible patch: revert drm/i915/fbdev: Actually configure untiled 
> displays (d179b88deb3bf6fed4991a31fd6f0f2cad21fab5).  Has been applied 
> upstream, but the real bug is thought to be in xorg not linux.
> 
> 
> 

As a side note, I'm affected by this bug and your suggested workaround
of copying a xorg.conf in /etc/Xorg worked for me, thanks :)

The linux commit got reverted since v5.1-rc7.

I don't know how Xorg and modeset work and what is exactly the atomic mode.
Also, I wasn't able to find what was fixed with the commit
d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 in linux, if it was possible
bugs discovered by reading the code or actual bugs users already
encountered.

But as I understand, there are several solutions to this bug:

- Revert the drm/i915/fbdev: Actually configure untiled displays
(d179b88deb3bf6fed4991a31fd6f0f2cad21fab5) commit in Linux. This revert
is in mainline since v5.1-rc7 [0]

- Rework the atomic support in Xorg, that require extensive
modifications but is in state to be tested, updated and validated [1]

- Disable atomic mode and fallback to legacy mode but that seem
suboptimal as atomic mode might be required by some drivers [2]



I guess backporting PR !36 [1] is too much changes in Xorg now that we
are in hard freeze and probably too risky given it is still
work-in-progress.

But I can't see how broken is to revert d179b88 commit in linux as I
don't what that commit fixed.
It seems to be not that critical as upstream linux has done the revert.

So I guess one solution is to just do the revert in linux and let the
next stable after Buster have the proper fix in Xorg with the time
needed to ensure it is working fine without breaking in various ways.

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9fa246256e09dc30820524401cdbeeaadee94025
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/36
[2] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F











Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: