[Intel-gfx] i810 only partially usable

[Chris Wilson]

On Mon, Sep 23, 2013 at 10:13:02AM -0400, Felix Miata wrote:
> On 2013-09-23 09:22 (GMT+0100) Chris Wilson composed:
> 
> >On Sun, Sep 22, 2013 at 08:45:57PM -0400, Felix Miata wrote:
> 
> >>82810E DC-133 (GMCH)(rev 03)
> ...
> >>*************************
> >>Not good (openSUSE 12.2):
> >>glamor-0.4.1-2.2.2
> >>kernel-desktop-3.4.47-2.38
> >>libdrm2-2.4.33-2.47.33-2.3.2
> >>libdrm_intel1-2.4.33-2.47.33-2.3.2
> >>(no Plymouth)
> >>xf86-video-intel-2.20.3-1.8.1
> >>xorg-x11-driver-video-intel-legacy-2.9.1-22.1.2
> >>xorg-x11-server-7.6_1.12.3-1.9.1 (server 1.12.3)
> 
> >>highest (& initial) video mode available according to xrandr and
> >>krandrtray: 1280x1024
> 
> >>PreferredMode is apparently ignored.
> 
> >Broken by
> 
> >commit 7bb653bedceb6180a0361ead1c612839e776ce98
> >Author: Olivier Fourdan <ofourdan at redhat.com>
> >Date:   Mon Oct 18 15:59:35 2010 -0400
> 
> >     modes: improve aspect ratio match for classic drivers
> 
> >which filters the modes reported by the EDID to the largest builtin
> >mode.
> 
> >diff --git a/hw/xfree86/common/xf86Mode.c b/hw/xfree86/common/xf86Mode.c
> >index 706ab64..2a11590 100644
> >--- a/hw/xfree86/common/xf86Mode.c
> >+++ b/hw/xfree86/common/xf86Mode.c
> >@@ -1869,10 +1869,10 @@ xf86ValidateModes(ScrnInfoPtr scrp, DisplayModePtr availModes,
> >          }
> >          if (vx < virtX || vy < virtY) {
> >              const int types[] = {
> >-                M_T_BUILTIN | M_T_PREFERRED,
> >-                M_T_BUILTIN,
> >                  M_T_DRIVER | M_T_PREFERRED,
> >                  M_T_DRIVER,
> >+                M_T_BUILTIN | M_T_PREFERRED,
> >+                M_T_BUILTIN,
> >                  0
> >              };
> >              const int ntypes = sizeof(types) / sizeof(int);
> 
> >Should restore the intent back to
> 
> >commit 81ef1b6d6063c20db4963abf7b7848e235aa4ebb
> >Author: Adam Jackson <ajax at benzedrine.nwnk.net>
> >Date:   Thu Sep 14 19:18:58 2006 -0400
> 
> >     Mark EDID modes as driver modes.  Infer virtual size from driver modes.
> 
> I don't know what to make of your response. I don't build packages.
> My i810 box is used only for seeking out and reporting regressions
> such as this. I'm puzzled how I missed this for so long, although
> part of why is probably attributable to loss of sysvinit causing me
> to have skipped over the openSUSE 12.3 development process with this
> machine. It's plenty slow, a 1GHz Coppermine with PC100 RAM, so I
> don't boot it much.
> 
> Did Adam already fix this? Will you be including this among your
> next submits? Do I need to file a bug first?

You have reported the bug, I've sent the patch onwards. It would be most
useful if you could test it, but I'm optimistic that Adam would be able
to review it without.

> >>vttys are stable only as long as X never started, regardless whether
> >>video= and/or vga= are present on cmdline. Only way I've found so
> >>far to make them work reliably again once X is started is to reboot.
> >>With various combinations of X running or not and video= and/or vga=
> >>used, vttys get scrambled in various ways (font mismatched to row
> >>and/or column counts of active mode).
> >>While X is running but a vtty is active, X/KDE3 may abort spontaneously.
> 
> >That sounds like the dangers inherent in UMS.
> 
> The whole paragraph? The last line only? Suggestions how to cope?
> I'm not including nomodeset on any of my cmdlines. AFAIK, only my
> MGA systems are not using KMS.

The i810 and all UMS drivers are inherently fragile wrt to VT switches,
sharing the device and the like. Unless you can demonstrate that it has
actually regressed, I suspect it is just the known instability.
 
> >The biggest change here is the loss of XAA in Xorg.
> 
> This too says nothing I understand. Referring to XAA or EXA or the
> like has no meaning to me. I'm not a programmer. I just test what
> others package, and get frustrated by comments like this one:
> https://bugs.freedesktop.org/show_bug.cgi?id=66462#c10

I am suggesting that there is a large known change in behaviour with
recent Xservers which is very likely to impact upon you. I am sorry you
find our requests for feedback frustrating, we too find it frustrating
not to be in a position to test ideas and fixes ourselves, and very much
rely on your good selves to both report issues and help us diagnose them.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre