[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree86
Subject:    Re: [XFree86] XFree86: ati driver problem
From:       Marc Aurele La France <tsi () ualberta ! ca>
Date:       2008-02-01 20:57:32
Message-ID: Pine.WNT.4.64.0802011355220.1832 () cluij ! ucs ! ualberta ! ca
[Download RAW message or body]

On Fri, 1 Feb 2008, Anton 'FaioN' Mayorov wrote:
> Marc Aurele La France wrote:
>>> I'm not sure if this bug is connected with XFree86 at all. There are 
>>> several bits of information that it is a kernel bug. It seems to me that 
>>> affected kernel versions are 2.6.22 and 2.6.23. Check this:
>>> http://lkml.org/lkml/2007/6/21/216 .

>> atyfb has __ALWAYS__ been broken, especially for laptops or adapters not 
>> initialised by BIOS/firmware.  And it is unfixable primarily because its 
>> maintainers over the years don't really know what they're doing.  That 
>> sounds harsh, but it is true.  On ix86, I recommend you use vesafb instead, 
>> or (better) no kernel framebuffer at all.

> Sorry, I've rather misled you. I don't use atyfb at all.

>> However, now that you have some kind of display, please send me a 
>> "-logverbose 5" log, and I'll see what I can do to mitigate atyfb's latest 
>> brain damage.
> "XFree86 -logverbose 5" lock my system entirely. Even SysRq magic doesn't 
> work. I've failed to trace the reason out.

> BTW, I've managed to synchronize my screen. I've overridden pATI->LCDClock 
> and used "Option "LCDSync"" in XF86Config (although I don't know for certain 
> what it means). It seems to work, but XFree86 still corrupts console mode 
> (i.e. after X server shutdown, all local ttys are in unusable state). And I 
> haven't found the reason why clock values are set wrong.

> And one more question. This is the part of atimode.c:
> -----------------------------------------------------------------
> static void
> ATISwap
> (
>    int      iScreen,
>    ATIPtr   pATI,
>    ATIHWPtr pATIHW,
>    Bool     ToFB
> )
> {
>    pointer save, *from, *to;
>    unsigned int iPlane = 0, PlaneMask = 1;
>    CARD8 seq2, seq4, gra1, gra3, gra4, gra5, gra6, gra8;
>
>    /*
>     * This is only done for non-accelerator modes.  If the video state on
>     * server entry was an accelerator mode, the application that 
> relinquished
>     * the console had better do the Right Thing (tm) anyway by saving and
>     * restoring its own video memory contents.
>     */
>    if (pATIHW->crtc != ATI_CRTC_VGA) 	        return;
> -----------------------------------------------------------------

> I don't use kernel framebuffer, so I think my console mode isn't accelerated. 
> But at this point, pATIHW->crtc is ATI_CRTC_MACH64. May it be the reason that 
> my console is not restored on exit? Is this the only method to restore video 
> state?

That pATIHW->crtc == ATI_CRTC_MACH64 at that point is proof positive that 
you are lying to me WRT to not using atyfb.

Marc.

+----------------------------------+----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310          |
|  Academic Information and        |  fax:    1-780-492-1729          |
|    Communications Technologies   |  email:  tsi@ualberta.ca         |
|  352 General Services Building   +----------------------------------+
|  University of Alberta           |                                  |
|  Edmonton, Alberta               |    Standard disclaimers apply    |
|  T6G 2H1                         |                                  |
|  CANADA                          |                                  |
+----------------------------------+----------------------------------+
_______________________________________________
XFree86 mailing list
XFree86@XFree86.Org
http://XFree86.Org/mailman/listinfo/xfree86
[prev in list] [next in list] [prev in thread] [next in thread]