linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hendricks <khendricks@ivey.uwo.ca>
To: Ani Joshi <ajoshi@shell.unixbox.com>
Cc: Kostas Gewrgiou <gewrgiou@imbc.gr>, linuxppc-dev@lists.linuxppc.org
Subject: Re: Some issues to resolve with XFree 4.0 yet
Date: Thu, 23 Mar 2000 13:16:37 -0500	[thread overview]
Message-ID: <00032313263100.01328@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.10.10003230911180.6826-100000@shell.unixbox.com>


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/

       reply	other threads:[~2000-03-23 18:16 UTC|newest]

Thread overview: 26+ 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 ` Kevin Hendricks [this message]
2000-03-25  3:54   ` Found bug in mode switching but who is at fault...XFree86 or aty128fb.c? Kevin Hendricks
2000-03-25  7:57     ` 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
     [not found] <Pine.LNX.4.05.10003240806290.5355-100000@callisto.of.borg>
2000-03-24  8:58 ` Michael Schmitz
2000-03-15 14:09 patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128 Kostas Gewrgiou
2000-03-23  4:46 ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks

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=00032313263100.01328@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).