Bug#308610: xserver-xfree86: Monitor rolls
On Friday 12 August 2005 00:04, you wrote:
| Package: xserver-xfree86
| Version: 4.3.0.dfsg.1-14
| Followup-For: Bug #308610
I have some suggestions, and maybe bad news at the end.
| I am not using the debian bug reporting tool since it looks
| like communication is better without it.
reportbug is meant to be used for reporting a bug ;
it automatically includes lots of usefull info into the bugreport.
additional information is supposed to be sent to <bugnumber>@bugs.debian.org,
as plain emails.
it is important to add all information to a bugreport,
so that other users with same problem can find it,
and maintainers can ultimatly fix the bug.
bugs on X packages, and additional information sent to existing bugreports,
are automatically copied to debian-x@lists.debian.org.
| I upgraded from potato to sarge. I did _not_ remove my old XFree86 3.3.6
| installation (fortunately). Old XFree86 3.3.6 works perfectly fine with
| the Mach64 X server. I can easily switch by pointing the symlink in
| /etc/X11/X to /usr/bin/X11/XF86_Mach64 and everything works fine, 1024x768,
| 800x600, and 640x480, all to a color depth of 16bpp (Max for my video
| card). I assume that this guarantees my hardware is fine.
I agree. So no further need for testing hardware.
| When I switch /etc/X11/X back to /usr/bin/xserver-xfree86, I get problems.
|
| This dual X installation is what I'm unsure about and where I need help to
| be sure the installation and configuration done by debian isn't
| causing any trouble. Note I did not use xfree86 version 4 with potato.
This possible cause of bugs must be elimininated
before we can conclude that it is a bug in X.
If a Debian X maintainer reads this and recognizes it,
and knows what to do about it, then it can be foregone,
but otherwise there is only one way to be sure :
install Debian without the old X version.
I hope you have a largish harddisk (4 GB free would be more than enough),
so you can do a clean install of sarge on another partition ;
I routinely use two Debian installs in different partitions myself,
one for stable and one for unstable,
so that when unstable breaks,
i simply reboot into stable, until untstable has been fixed.
so a dual installation can be usefull anyway.
If you do that, please keep notes of what you fill in when X is configured.
| I have tested several different cases.
| 1. Plain vanilla configuration, as done by debconf.
| No modelines in XF86Config-4 file. Module "ati" chosen since I have an ATI
| Mach64 video card. Monitor blanks when I start X because it thinks there
| is no video signal.
There probably is a video signal, but the monitor can not sync to it at all
(not even horizontal sync), so it blanks (or something like that).
| If I switch video modes (CTRL-ALT-keypad +/-), the
| monitor displays a rolling image of the correct image (I can see the gray
| stipple that X starts with, the background color of my window manager, and
| the "Start" bar scrolling/rolling along with the mouse pointer). The same
| thing happens in all video modes, with little difference in the rolling
| pattern. So X is starting and producing output (which my monitor cannot
| display).
X is running fine, and can not detect that monitor does not synchronize,
so there are no errors reported in $HOME/.xsession-errors
| 2. Added standard VESA modelines. Change default mode, trying 800x600 and
| 640x480. BTW, these modelines work perfectly fine in my XF86-Config file
| for XFree86 3.3.6.
Good. Same modeline works in one situation, and not in another ;
this can give upstream something to work with.
| No change in behavior.
| It doesn't matter what video mode I start with, the
| monitor will go blank when I start X, and when I change video modes, it
| will produce a rolling image at all resolutions, 1024x768, 800x600,
| and 640x480, even when I loop through all modes back to the first one.
range of frequencys to which a PLL will synchronize
depends on it's current frequency ;
this might explain that it now partially synchronizes to default videomode.
| 3. Changed module "ati" to module "vga".
| Monitor syncs, but gives me a 320x240 screen.
| No flickers or rolling image.
| 4. Changed module "vga" back to "ati" but start x with a color depth of 4,
| forcing the "ati" module to use vga CRT controller per author's
| documentation - see
| Monitor syncs at 640x480 and, if I played around with the video timings to
| get X to use a Vert Refresh near 60 Hz, at 800x600.
This makes me curious to what it does when started at depth 8.
| However, if I specify a Modeline in the XF86Config-4 file,
| the display frequencies reported by my monitor do not match with what X
| reports when it starts up.
| This is true for both 640x480 and 800x600; however, for 640x480 I could not
| discover any pattern. For 800x600, I noticed that the configuration for
| about 60 Hz produced a very flickery image at 49 Hz, and playing around
| with the timings and configuring X to display around 40 Hz, I got a 56-60
| Hz image. (See my hacked configuration file in my original report.)
The PLL in your monitor has apparently acquired a 'false lock',
i.e.: it runs at 60 Hz while getting a 40 Hz input signal,
so every second syncpules from videocard coincides with
every third pulse from PLL, and it locks onto this.
Generally, PLLs synchronize to fundamental frequency because
1) they measure frequency of input signal
(this is very easy for a clean video signal), and
2) they know what frequency to expect
this is signaled to monitor by polarity of sync signals.
I think i read in ati-driver's docs that it is not necessary to
supply sync polarity in a modeline,
as driver will add correct values itself,
so you might try to leave out the +-hsync +-vsync .
| Because of this, I conclude that there is some error in the video timing
| calculations in the ati driver.
Not proven yet.
(Maybe 3.3.6 automatically corrected sync polarities, for example)
| 5. Back to vanilla configuration, as done by debconf.
| Using 2.4.31 kernel now.
| > What happens if you change that to horiz: 30-50 and vertical 50-90 ?
| > does that get you a usable 1024x768@62Hz ?
| Same result as before.
| However, I noticed and remembered another problem:
| When I set my Display Depth at 16 bpp, the "ati" module reports that the
| color depth is not supported by the adapter. I tried 8, 15, and 24 bpp.
(**) ATI(0): Depth 16, (--) framebuffer bpp 16
It seems to probe a framebuffer.
Do you have anything about a framebuffer (FB) in your XF86Config ?
If so, try removing it.
If not, it is another good starting point for debugging (by upstream).
Apropos upstream : Debian no longer has XFree86 as upstream,
but switched to X.org ,
so if a clean sarge install doesn't work
(and after registering exactly how it fails),
it might be a nice idea to install unstable,
if you are lucky this bug may have been fixed there,
and otherwise it might give additional and more uptodate info.
You could also look at the ati driver's changelog,
and look through the bug tracking system at freedesktop.org
(you can find them from X.org's homepage)
to see if anybody else reported this bug too.
| All except 8 gave the exact same error message and essentially same
| log file. (bpp 24 said driver didn't support it too.) I have included the
| log file XFree86.depth16.log.
| At 8 bpp, same results as 1. and 2.
depth 8 seemed to work, but monitor rolled ; that is one bug.
other depths are not accepted ; that may be another bug
or it may be related to first bug ; impossible to say now.
I looked on http://www.x.org/X11R6.8.2/doc/ati3.html#3 ,
and it says that lots of ati cards are only supported in SVGA mode,
and with maximum 8 bits per pixel ;
only 264xT and 3d rage are supported at higher depths
(mach128 and radeon are supported by other drivers).
This suggests that your card is no longer fully supported,
in which case the failure to use 16 bpp would be explained
and you would probably want to acquire a new videocard.
Well, enough things to try.
Good luck,
Siward
(home.wanadoo.nl/siward)
---------------------------------------------------------------------
meten is weten,
gissen is missen.
Reply to: