Re: [Intel-gfx] i810 only partially usable
On 2013-10-08 00:06 (GMT-0400) Felix Miata composed:
Still broken:
Linux gx110 3.11.3-3.gac1d7be-default #1 SMP Fri Oct 4 12:14:40 UTC 2013
(ac1d7be) i686 i686 i386 GNU/Linux
glamor-0.5.1-39.2.i586
intel-gpu-tools-1.3-20.10.i586
libdrm_intel1-2.4.46-121.1.i586
libdrm2-2.4.46-121.1.i586
vaapi-intel-driver-1.2.0-22.8.i586
xf86-video-intel-2.99.903-88.2.i586
xorg-x11-server-7.6_1.14.3-251.15.i586
Linux gx110 3.11.4-1.g40d7ca3-default #1 SMP Sat Oct 5 16:59:29 UTC 2013
(40d7ca3) i686 i686 i386 GNU/Linux
Turns out configuring a screen section in the old pre-KMS format enumerating
desired/selectable modes solves the problem, even enabling virtal (aka KMS
panning). However on exit from the X session back to the ttys, the default
mode set on boot (neither vga= nor video= on {Grub Legacy} cmdline), or one
that was set via vga= (video= is ignored), may or may not restored. When not,
the ttys are left unusable from mismatch between font used and (no longer
correct) rows/columns. Apparently the first X session following boot exits
OK, but not a second.
--
"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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On 2013-10-04 19:32 (GMT-0400) Felix Miata composed: Valid modes are now being recognized, but PreferredMode is still being ignored, and EDID preferred is inescapable via /etc/X11/xorg.conf*. Linux gx110 3.11.2-1.g420e19b-default #1 SMP Sat Sep 28 16:00:10 UTC 2013 (420e19b) i686 i686 i386 GNU/Linux glamor-0.5.1-39.1.i586 intel-gpu-tools-1.3-20.10.i586 libdrm2-2.4.46-121.1.i586 libdrm_intel1-2.4.46-121.1.i586 (no Plymouth) vaapi-intel-driver-1.2.0-22.8.i586 xf86-video-intel-2.99.903-88.2.i586 xorg-x11-server-7.6_1.14.3-251.12.i586 log: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-PreferredModeIGNORED Still broken: Linux gx110 3.11.3-3.gac1d7be-default #1 SMP Fri Oct 4 12:14:40 UTC 2013 (ac1d7be) i686 i686 i386 GNU/Linux glamor-0.5.1-39.2.i586 intel-gpu-tools-1.3-20.10.i586 libdrm_intel1-2.4.46-121.1.i586 libdrm2-2.4.46-121.1.i586 vaapi-intel-driver-1.2.0-22.8.i586 xf86-video-intel-2.99.903-88.2.i586 xorg-x11-server-7.6_1.14.3-251.15.i586 -- "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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On 2013-09-22 20:45 (GMT-0400) Felix Miata composed: * Awful (openSUSE 13.1 Beta 1): glamor-0.5.1-1.1 intel-gpu-tools-1.3-4.4 kernel-desktop-3.11.1-1 libdrm2-2.4.46-2.1 libdrm-intel1-2.4.46-2.1 (no Plymouth) xf86-video-intel-2.99.902-1.1 xorg-x11-server-7.6_1.14.3-1.1 (server 1.14.3) PreferredMode is apparently ignored. highest (& initial) video mode available according to xrandr and krandrtray: 1280x1024 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. http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-0vga0video-1280x1024maxBAD http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-1vga1video-1280x1024maxBAD I was unable to find a bug matching this behavior on https://bugs.freedesktop.org/. Comments? Valid modes are now being recognized, but PreferredMode is still being ignored, and EDID preferred is inescapable via /etc/X11/xorg.conf*. Linux gx110 3.11.2-1.g420e19b-default #1 SMP Sat Sep 28 16:00:10 UTC 2013 (420e19b) i686 i686 i386 GNU/Linux glamor-0.5.1-39.1.i586 intel-gpu-tools-1.3-20.10.i586 libdrm2-2.4.46-121.1.i586 libdrm_intel1-2.4.46-121.1.i586 (no Plymouth) vaapi-intel-driver-1.2.0-22.8.i586 xf86-video-intel-2.99.903-88.2.i586 xorg-x11-server-7.6_1.14.3-251.12.i586 log: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-PreferredModeIGNORED -- "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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On 2013-09-24 11:07 (GMT+0200) Daniel Vetter composed: usually downloading the sources, patching them and rebuilding a custom rpm isn't too onerous a journey. Here, it is onerous, for multiple reasons. I tried it in 2006/2007. It isn't likely to happen again here, ever. -- "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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On Mon, Sep 23, 2013 at 11:41:25AM -0400, Felix Miata wrote: > On 2013-09-23 15:51 (GMT+0100) Chris Wilson composed: > > >On Mon, Sep 23, 2013 at 10:13:02AM -0400, Felix Miata wrote: > > >>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. > > :-) > > >>...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. > > The frustration is not the comment itself, but the obstacle in > needing to build a binary to be able to test the efficacy of the > patch. Might having a Gentoo installation facilitate such tests by > non-programmers like me who normally use a dpkg or rpm distro and > don't how to use developer tools? Hopping onto your distro channel and begging the X package maintainers for a custom build usually helps. Otherwise you'll have a good excuse to jump into creating your own packages - usually downloading the sources, patching them and rebuilding a custom rpm isn't too onerous a journey. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On 2013-09-23 15:51 (GMT+0100) Chris Wilson composed: On Mon, Sep 23, 2013 at 10:13:02AM -0400, Felix Miata wrote: 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. :-) ...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. The frustration is not the comment itself, but the obstacle in needing to build a binary to be able to test the efficacy of the patch. Might having a Gentoo installation facilitate such tests by non-programmers like me who normally use a dpkg or rpm distro and don't how to use developer tools? -- "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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
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
> >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
> >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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
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
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
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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On Sun, Sep 22, 2013 at 08:45:57PM -0400, Felix Miata wrote:
> 82810E DC-133 (GMCH)(rev 03)
>
> Everything seems to be OK with these (openSUSE 12.1):
> glamor (no such package)
> kernel-desktop-3.1.10-1.29
> libdrm-2.4.26-15.1.2
> (no Plymouth)
> xorg-x11-driver-video-intel-legacy-2.9.1-13.1.2
> xorg-x11-server-7.6_1.10.4-36.9.2 (server 1.9.3)
>
> 1600x1200 (which happens to be the EDID preferred mode) as specified
> via PreferredMode works.
>
> vga=8121 on cmdline works as expected on the vttys (no material BIOS
> VESA support available).
>
> http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os121-1600x1200x120OK
>
> *
> 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
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
Date: Thu Sep 14 19:18:58 2006 -0400
Mark EDID modes as driver modes. Infer virtual size from driver modes.
> vga=8121 on cmdline works as expected on the vttys even after X is terminated.
>
> http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os122-bad1280x1024
>
>
> *
> Awful (openSUSE 13.1 Beta 1):
> glamor-0.5.1-1.1
> intel-gpu-tools-1.3-4.4
> kernel-desktop-3.11.1-1
> libdrm2-2.4.46-2.1
> libdrm-intel1-2.4.46-2.1
> (no Plymouth)
> xf86-video-intel-2.99.902-1.1
> xorg-x11-server-7.6_1.14.3-1.1 (server 1.14.3)
>
> PreferredMode is apparently ignored.
>
> highest (& initial) video mode available according to xrandr and
> krandrtray: 1280x1024
>
> 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 biggest change here is
the loss of XAA in Xorg.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i810 only partially usable
82810E DC-133 (GMCH)(rev 03) Everything seems to be OK with these (openSUSE 12.1): glamor (no such package) kernel-desktop-3.1.10-1.29 libdrm-2.4.26-15.1.2 (no Plymouth) xorg-x11-driver-video-intel-legacy-2.9.1-13.1.2 xorg-x11-server-7.6_1.10.4-36.9.2 (server 1.9.3) 1600x1200 (which happens to be the EDID preferred mode) as specified via PreferredMode works. vga=8121 on cmdline works as expected on the vttys (no material BIOS VESA support available). http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os121-1600x1200x120OK * 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. vga=8121 on cmdline works as expected on the vttys even after X is terminated. http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os122-bad1280x1024 * Awful (openSUSE 13.1 Beta 1): glamor-0.5.1-1.1 intel-gpu-tools-1.3-4.4 kernel-desktop-3.11.1-1 libdrm2-2.4.46-2.1 libdrm-intel1-2.4.46-2.1 (no Plymouth) xf86-video-intel-2.99.902-1.1 xorg-x11-server-7.6_1.14.3-1.1 (server 1.14.3) PreferredMode is apparently ignored. highest (& initial) video mode available according to xrandr and krandrtray: 1280x1024 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. http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-0vga0video-1280x1024maxBAD http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-1vga1video-1280x1024maxBAD I was unable to find a bug matching this behavior on https://bugs.freedesktop.org/. Comments? -- "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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
