[Bug 107162] Ivybridge HD4000 graphics system reports modesettnot working with X11

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107162

--- Comment #13 from Father McGuire <niqxwxgy at guerrillamail.org> ---
(In reply to Chris Wilson from comment #12)
> Vague recollection of it being a bug in the atomic modesetting rework since
> fixed.

I have very strong recollections of this machine crashing a few years ago with
i915 driver for months on end. I also remember that this chipset was mean to
support IOMMU (ie. VT-d) and I haven't seen that ever work. I also remember the
TSX debacle, which rendered haswell's and broadwells cripppled, and now we have
the so called speed ups in recent generations of intel cruft being riddled with
great gapping security holes. But I digressed.

I tried the same build in a VT-d enviromentment on other intel hardware, some
crippled haswell IP and it worked a treat. I don't know if this is display is
on a display port or whatever pipe is used to connect it to the smoke an
mirrors.

I did find this in the xorg server changelog 
commit c256e31a9eba20da259f31ee70d1c8e1870993f1
Author: Takashi Iwai <tiwai at suse.de>
Date:   Thu Jul 19 14:38:19 2018 +0200

    modesetting: Fix cirrus 24bpp breakage

    The recent rewrite of modesetting driver broke the 24bpp support.
    As typically found on cirrus KMS, it leads to a blank screen, spewing
    the error like:
      failed to add fb -22
      (EE) modeset(0): failed to set mode: Invalid argument

    The culript is that the wrong bpp value of the front buffer is passed
    to drmModeAddFB().  Fix it by replacing with the back buffer bpp,
    drmmode->kbpp.

    Signed-off-by: Takashi Iwai <tiwai at suse.de>
    Tested-by: Stefan Dirsch <sndirsch at suse.de>
    Reviewed-by: Adam Jackson <ajax at redhat.com>
    (cherry picked from commit d625e16918ef9104863709eb108346464767c444)


I don't know if it is related.

Whatever, I just tried this patch and I get 100% X startup success:


de_display.c.orig 
./work/xorg-server-1.20.1/hw/xfree86/drivers/modesetting/drmmode_display.c
---
./work/xorg-server-1.20.1/hw/xfree86/drivers/modesetting/drmmode_display.c.orig
    2018-08-07 16:31:03.000000000 +0000
+++ ./work/xorg-server-1.20.1/hw/xfree86/drivers/modesetting/drmmode_display.c 
2018-08-18 23:34:43.820435159 +0000
@@ -1494,10 +1494,8 @@
         if (drmmode_crtc_set_mode(crtc, can_test)) {
             xf86DrvMsg(crtc->scrn->scrnIndex, X_ERROR,
                        "failed to set mode: %s\n", strerror(errno));
-            ret = FALSE;
-            goto done;
-        } else
-            ret = TRUE;
+       }
+        ret = TRUE;

         if (crtc->scrn->pScreen)
             xf86CrtcSetScreenSubpixelOrder(crtc->scrn->pScreen);

PS: The MAC addresses in the log files are fake

Thanks again Chipzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180818/399e7e5e/attachment.html>