Re: color maps issues
flat view
From: Michel D�nzer <hidden>
Date: 2000-08-02 16:42:12
Jack Howarth wrote:
I think we should revisit the issue Kevin Hendricks brought up in
March since it still was a problem up until a week ago in the linuxppc
stable kernel anyway....Here was his old message...But Steffen Haeuser stated on the Xpert ML someone told him the problem was fixed?
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?
IMO aty128fb is definitely wrong. v{x,y}res never change in the X server - in
fact, the size of the X root window can't be changed legally, and these values
correspond to its size.
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!).
That's not the X server's problem. It's still better to get a correct display where you can't reach certain parts of the display instead of an incorrect display, isn't it? And then as soon as panning is implemented, everything works fine. And in the special case of games using full-screen modes, panning isn't even needed...
quoted hunk ↗ jump to hunk
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 I submitted the following patch to BenH for use in his test kernels...--- drivers/video/aty128fb.c.prev Sun Jul 30 22:04:24 2000 +++ drivers/video/aty128fb.c Sun Jul 30 22:05:01 2000@@ -842,7 +842,7 @@ crtc->v_sync_strt_wid = v_sync_strt | (v_sync_wid << 16) | (v_sync_pol << 23); - crtc->pitch = xres >> 3; + crtc->pitch = vxres >> 3; crtc->offset = 0; crtc->offset_cntl = 0;that Kevin sent me last week. However after finding Kevin's original message I think he final suggestion in it is right and we should have a patch placed in aty128fb.c which shrinks the virtual resolution down to match the physical resolution in xfree when mode switching.
I don't think that's possible without destroying the framebuffer contents. Michel -- It is easier to fix Unix than to live with NT. ______________________________________________________________________________ Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast Debian GNU/Linux (powerpc,i386) user \ member of XFree86, Team *AMIGA*, AUGS ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/