From: Kevin Hendricks <hidden> Date: 2000-03-23 18:16:37
Hi Ani and Kostas,
ErrorF or xf86DrvMsg the var struct before and after a mode switch, then
see whats wrong.
Okay, here is all the snippets I think you need to see what is going on.
AFAICT everything looks to be okay.
It's almost like we are missing a pixel cache flush or engine flush or
something along those lines.
I current have 3 modes in my XF86Config. If I put only one mode on the mode
line then I can successfully startx properly into that mode. If however, I put
all three modes on one line (allow SwitchMode to work) then only the first mode
(the highest resolution works, the lower resolutions do not).
Here are the snippets from the log for switching modes from 1152x870 (the
working mode) to 832x624 (bad) then to 1024x768 (again bad) and once more back
to 1152x870.
Any ideas here? Do we need something like an engine reset or flush in
aty128fb_set_var?
Here is the log snippet:
fbdevHW: SwitchMode 0
xfree new mode: 57591 832 885 949 1152 624 625 628 667
fbdev before mode: 9999 1152 53 128 123 870 3 3 39 32 8:8:8
fbdev after mode: 17364 832 53 64 203 624 1 3 39 32 8:8:8
fbdevHW: AdjustFrame 0
fbdevHW: SwitchMode 0
xfree new mode: 78747 1024 1056 1152 1312 768 769 772 800
fbdev before mode: 17364 832 53 64 203 624 1 3 39 32 8:8:8
fbdev after mode: 12698 1024 37 96 155 768 1 3 28 32 8:8:8
fbdevHW: AdjustFrame 0
fbdevHW: SwitchMode 0
xfree new mode: 100001 1152 1205 1333 1456 870 873 876 915
fbdev before mode: 12698 1024 37 96 155 768 1 3 28 32 8:8:8
fbdev after mode: 9999 1152 53 128 123 870 3 3 39 32 8:8:8
fbdevHW: AdjustFrame 0
Here are the print routines so that you can see what is being printed above:
static void
print_fbdev_mode(char *txt, struct fb_var_screeninfo *var)
{
ErrorF( "fbdev %s mode:\t%d %d %d %d %d %d %d %d %d %d %d:%d:%d\n"
,
txt,var->pixclock,
var->xres, var->right_margin, var->hsync_len, var->left_margin,
var->yres, var->lower_margin, var->vsync_len, var->upper_margin,
var->bits_per_pixel,
var->red.length, var->green.length, var->blue.length);
}
static void
print_xfree_mode(char *txt, DisplayModePtr mode)
{
ErrorF( "xfree %s mode:\t%d %d %d %d %d %d %d %d %d\n",
txt,mode->Clock,
mode->HDisplay, mode->HSyncStart, mode->HSyncEnd, mode->HTotal,
mode->VDisplay, mode->VSyncStart, mode->VSyncEnd, mode->VTotal);
}
Here is the routine that literally loads the new mode info so you can see how
the calculations from SyncStart to margins and etc are being done:
static void
xfree2fbdev_timing(DisplayModePtr mode, struct fb_var_screeninfo *var)
{
var->xres = mode->HDisplay;
var->yres = mode->VDisplay;
if (var->xres_virtual < var->xres)
var->xres_virtual = var->xres;
if (var->yres_virtual < var->yres)
var->yres_virtual = var->yres;
var->xoffset = var->yoffset = 0;
var->pixclock = mode->Clock ? 1000000000/mode->Clock : 0;
var->right_margin = mode->HSyncStart-mode->HDisplay;
var->hsync_len = mode->HSyncEnd-mode->HSyncStart;
var->left_margin = mode->HTotal-mode->HSyncEnd;
var->lower_margin = mode->VSyncStart-mode->VDisplay;
var->vsync_len = mode->VSyncEnd-mode->VSyncStart;
var->upper_margin = mode->VTotal-mode->VSyncEnd;
var->sync = 0;
if (mode->Flags & V_PHSYNC)
var->sync |= FB_SYNC_HOR_HIGH_ACT;
if (mode->Flags & V_PVSYNC)
var->sync |= FB_SYNC_VERT_HIGH_ACT;
if (mode->Flags & V_PCSYNC)
var->sync |= FB_SYNC_COMP_HIGH_ACT;
#if 0
if (mode->Flags & V_BCAST)
var->sync |= FB_SYNC_BROADCAST;
#endif
if (mode->Flags & V_INTERLACE)
var->vmode = FB_VMODE_INTERLACED;
else if (mode->Flags & V_DBLSCAN)
var->vmode = FB_VMODE_DOUBLE;
else
var->vmode = FB_VMODE_NONINTERLACED;
}
Everything seems to be alright to me. I think we are just missing some sort of
flush or reset in the aty128fb set_var routine? It is interesting to note,
that the r128 code in its SwitchMode (not usig FBDev) literally reloads all of
the registers and does a full R128EngineInit.
Ideas here?
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/
From: Kevin Hendricks <hidden> Date: 2000-03-25 03:54:51
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
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/
From: Michel D�nzer <hidden> Date: 2000-03-25 07:57:37
Kevin Hendricks wrote:
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.
Not necessarily. The problem could have shown up if someone had put a mode
with xres < vxres as first in the "Modes" line, but apparently only
configuration tools tend to do that...
So for any one mode it defaults to being okay.
Okay.
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?
I vote for the latter, because otherwise invisible parts of the screen may be
damaged, or am I wrong?
A better reason might be that it works perfectly as-is in glint ;)
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-03-25 08:07:30
Michel Dänzer wrote:
Kevin Hendricks wrote:
quoted
This is not a problem if xres == vxres. Which is what happens when the
aty128fb.c starts up.
Not necessarily. The problem could have shown up if someone had put a mode
with xres < vxres as first in the "Modes" line, but apparently only
configuration tools tend to do that...
Oops. I misread you were writing about the r128 driver. My apologies.
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
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.
Which is wrong: aty128fb must do `vxres * bpp / 8'.
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?
XFree86 cannot change the visible resolution on the fly.
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!).
Hence panning needs to be fixed :-) In fact panning is very simple, just change
the offset of the first pixel. That's a `one-register' update.
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
XFree86 cannot change the visible resolution on the fly, so we cannot change
it. Design bug in the whole X system :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Kevin Hendricks <hidden> Date: 2000-03-25 23:50:09
Hi Kostas,
Okay, with the patch I posted last night for setting crtc.pitch in aty128fb.c,
mode switching now works fine but the "panning" ioctl is on the "todo" list yet.
Thanks to Geert for pointing out you can't change virtual resolutions on the
fly with XFree (I was about to try! ;-)
You then asked me to look at getting it to work without using the FBDev. Given
my earlier patch which calculates XCLK using OF supplied values in the pll
registers, all you need to do to use it without FBDev is to simply comment out
the calls to vgaHWSave and vgaHWRestore in r128_driver.c.
From that point on, everything works like a charm.
My question is as follows, under ppc should we ever be doing anything with
vgaHWSave and vgaHWRestore. Can I simply ifdef them out for all __powerpc__
machines?
If not, is there any way to determine under which powerpc machines that an r128
card actually can use vgaHWSave and vgaHWRestore.
I think the only outstanding issue on r128 is the damn flashing white square
when cursor images are changed. I have looked and looked at this but I can't
figure out why this is happening unless a big white square is someone's
idea of a transparent cursor! ;-)
I have to start spending time on some other projects for awhile (i.e. real
life research project that needs to get underway) so I wanted to wrap things up
with the r128 driver for awhile.
If and when I get some time, I would be happy to take a shot at taking the r128
source and making it a mach64 source just in case you think that would be of
use (i.e. someone else hasn't done that yet and the old ati driver has not been
converted to work yet).
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/
Hi Kostas,
Okay, with the patch I posted last night for setting crtc.pitch in aty128fb.c,
mode switching now works fine but the "panning" ioctl is on the "todo" list yet.
Thanks to Geert for pointing out you can't change virtual resolutions on the
fly with XFree (I was about to try! ;-)
The aty128fb in the linus 2.3.x tree has panning working so you can try
that and see if its working ok.
You then asked me to look at getting it to work without using the FBDev. Given
my earlier patch which calculates XCLK using OF supplied values in the pll
registers, all you need to do to use it without FBDev is to simply comment out
the calls to vgaHWSave and vgaHWRestore in r128_driver.c.
You will also need to add code to switch the framebuffer in the right
endian for the depth and probably disable the int10 module.
quoted
From that point on, everything works like a charm.
My question is as follows, under ppc should we ever be doing anything with
vgaHWSave and vgaHWRestore. Can I simply ifdef them out for all __powerpc__
machines?
vgahw will not work under powerpc right now (iobase and vga memory aren't
handled right), once its working it will probably be usefull for prep/chrp
but for now you have to disable it.
If not, is there any way to determine under which powerpc machines that an r128
card actually can use vgaHWSave and vgaHWRestore.
Thats a good question, right now they don't work at all under ppc for
drivers that don't switch vgahw to MMIO.
I think the only outstanding issue on r128 is the damn flashing white square
when cursor images are changed. I have looked and looked at this but I can't
figure out why this is happening unless a big white square is someone's
idea of a transparent cursor! ;-)
This is strange, from what i see in the driver it hides the cursor before
loading the image so i can't imagine why you get the artifacts
I have to start spending time on some other projects for awhile (i.e. real
life research project that needs to get underway) so I wanted to wrap things up
with the r128 driver for awhile.
If and when I get some time, I would be happy to take a shot at taking the r128
source and making it a mach64 source just in case you think that would be of
use (i.e. someone else hasn't done that yet and the old ati driver has not been
converted to work yet).
There is an ati driver in 4.0 (not accelerated much though) it just needs
fbdev support and prabably some endian changes before its usable under ppc,
it shouln't be much harder than what you did to add fbdev support in r128
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/