From: Kevin Hendricks <khendricks@ivey.uwo.ca>
To: Kostas Gewrgiou <gewrgiou@imbc.gr>, Ani Joshi <ajoshi@shell.unixbox.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Found bug in mode switching but who is at fault...XFree86 or aty128fb.c?
Date: Fri, 24 Mar 2000 22:54:51 -0500 [thread overview]
Message-ID: <00032423100100.00584@localhost.localdomain> (raw)
In-Reply-To: <00032313263100.01328@localhost.localdomain>
Hi,
I figured since the fbdev driver showed the same problem as the r128 driver,
that the mode switching problem must be in either aty128fb.c or xfree86 but not
in the r128 driver.
Okay so I found the bug. It seems all through the r128 driver, crtc.pitch
values are set to the virtual x resolution (vxres) / 8. But in aty128fb.c in
the var_to_crtc routine the crtc.pitch is set to be just the xres / 8.
This is not a problem if xres == vxres. Which is what happens when the
aty128fb.c starts up. So for any one mode it defaults to being okay.
However, when doing mode switching via the Cntl-Alt-Keypad+- keys, xfree sets
vxres and vyres to be the same as the resolution of the largest mode on that
line (so 1152x870 becomes my vxres, and vyres when 1152x870, 832x624, 1024x768
are all specified on the same line.
This results in a call to aty128fb_set-var which calls decode_var which calls
var_to_crtc. which gets the crtc.pitch wrong.
So my questions is as follows?
Who is wrong? Should xfree shrink the vxres and vyres to match xres and yres
before calling set_var or should aty128fb.c var_to_crtc routine be fixed to use
vxres >> 3 instead of just xres >> 3?
If aty128fb.c needs to be fixed, here is a patch:
--- aty128fb.c.last Sat Mar 18 23:04:24 2000
+++ aty128fb.c Fri Mar 24 22:39:26 2000
@@ -794,8 +794,11 @@
crtc->v_sync_strt_wid = v_sync_strt | (v_sync_wid << 16) |
(v_sync_pol << 23);
+#if 0
crtc->pitch = xres >> 3;
-
+#else
+ crtc->pitch = vxres >> 3;
+#endif
crtc->offset = 0;
crtc->offset_cntl = 0;
But I am not sure if this makes sense alone.
What use is it to get a nice 832x624 hole into a display that is virtually
1152x870?!? I can't get to any of the kde controls, panels, etc since they are
off the screen! And it would be a pain to have to pan around looking for them
(especially since the ioctl for panning is on the "to do" list!).
So my feeling is that both are wrong. We should shrink the virtual resolution
to match the physical resolution in xfree when mode switching and put the patch
in place in aty128fb.c
Comments?
Thanks,
Kevin
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-03-25 3:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.10.10003230911180.6826-100000@shell.unixbox.com>
2000-03-23 18:16 ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks
2000-03-25 3:54 ` Kevin Hendricks [this message]
2000-03-25 7:57 ` Found bug in mode switching but who is at fault...XFree86 or aty128fb.c? Michel Dänzer
2000-03-25 8:07 ` Michel Dänzer
2000-03-25 13:46 ` Geert Uytterhoeven
2000-03-25 23:50 ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks
2000-03-27 11:09 ` Kostas Gewrgiou
2000-03-27 17:41 ` Ryuichi Oikawa
2000-03-27 18:05 ` Ani Joshi
2000-03-27 19:06 ` Kevin B. Hendricks
2000-03-27 19:13 ` David Edelsohn
2000-03-27 19:20 ` Kevin B. Hendricks
2000-03-27 19:25 ` Ani Joshi
2000-03-27 19:45 ` David Edelsohn
2000-03-27 19:38 ` Ani Joshi
2000-03-27 20:01 ` David Edelsohn
2000-03-27 19:48 ` Kevin B. Hendricks
2000-03-28 7:59 ` Geert Uytterhoeven
2000-03-29 10:45 ` Gabriel Paubert
2000-03-29 13:11 ` Franz Sirl
2000-03-29 14:58 ` Gabriel Paubert
2000-03-29 19:39 ` Franz Sirl
2000-03-28 16:51 ` Ryuichi Oikawa
2000-03-28 17:51 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00032423100100.00584@localhost.localdomain \
--to=khendricks@ivey.uwo.ca \
--cc=ajoshi@shell.unixbox.com \
--cc=gewrgiou@imbc.gr \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).