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@xxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx>
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?
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 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
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
