[Xpert]mach64 hw cursor bug in DRI
This is email regards the hw cursor garbling in mach64 based cards when
DRI is enabled.
The relevant parts of XFree86.0.log are:
(II) ATI(0): VESA VBE Total Mem: 4096 kB
...
(II) ATI(0): Storing hardware cursor image at 0xFD3FFC00.
(II) ATI(0): Using 8 MB linear aperture at 0xFD00.
(!!) ATI(0): Virtual resolutions will be limited to 4095 kB
due to linear aperture size and/or placement of hardware cursor image
area.
(II) ATI(0): Using Block 0 MMIO aperture at 0xFC100400.
(II) ATI(0): Using Block 1 MMIO aperture at 0xFC10.
(==) ATI(0): Write-combining range (0xfd00,0x40)
(II) ATI(0): MMIO write caching enabled.
(--) ATI(0): 4096 kB of SGRAM (2:1) 32-bit detected (using 4095 kB).
...
(II) ATI(0): [drm] framebuffer handle = 0xfd00
...
(II) ATI(0): Visual configs initialized
(II) ATI(0): Block 0 base at 0xfc100400
(II) ATI(0): Memory manager initialized to (0,0) (640,1587)
(II) ATI(0): Reserved back buffer from (0,480) to (640,960)
(II) ATI(0): Reserved depth buffer from (0,960) to (640,1440)
(II) ATI(0): Reserved 2112 kb for textures at offset 0x1eff00
After some calculations we have that:
start end
textures: 0x1eff000x3fff00
hw cursor: 0x3ffc000x40
Notice the overlap.
The relevant piece of code is from atiscreen.c:
int fbSize = pATI->VideoRAM * 1024;
> Here is the problem! It should be pScreenInfo->videoRam and not
pATI->VideoRAM. See below.
/* Try for front, back, depth, and one viewport's worth of
* pixmap cache. Should be enough for at least a fullscreen
* background image.
*/
pATIDRIServer->textureSize = fbSize - (3 * bufferSize +
ATI_DRI_XAA_LINES * widthBytes);
l = ATIMinBits((pATIDRIServer->textureSize-1) / MACH64_NR_TEX_REGIONS);
if (l < MACH64_LOG_TEX_GRANULARITY) l = MACH64_LOG_TEX_GRANULARITY;
/* Round the texture size up to the nearest whole number of
* texture regions. Again, be greedy about this, don't round
* down.
*/
pATIDRIServer->logTextureGranularity = l;
pATIDRIServer->textureSize =
(pATIDRIServer->textureSize >> l) << l;
> NOTE: Why round up if there's no memory for that? Anyway this code is
rounding down and not up...
total = fbSize - pATIDRIServer->textureSize;
scanlines = total / widthBytes;
if (scanlines > ATIMach64MaxY) scanlines = ATIMach64MaxY;
/* Recalculate the texture offset and size to accomodate any
* rounding to a whole number of scanlines.
* FIXME: Is this actually needed?
*/
pATIDRIServer->textureOffset = scanlines * widthBytes;
pATIDRIServer->textureSize = fbSize - pATIDRIServer->textureOffset;
...
else
#endif /* XF86DRI */
{
ScreenArea.x1 = ScreenArea.y1 = 0;
ScreenArea.x2 = pATI->displayWidth;
ScreenArea.y2 = pScreenInfo->videoRam * 1024 * 8 / pATI->displayWidth /
> The non-DRI code ^
pATI->bitsPerPixel;
if ((unsigned)ScreenArea.y2 > ATIMach64MaxY)
ScreenArea.y2 = ATIMach64MaxY;
xf86InitFBManager(pScreen, &ScreenArea);
}
And from atipreinit.c we have:
if (ServerVideoRAM < pATI->VideoRAM)
{
pScreenInfo->videoRam = ServerVideoRAM;
> ^
xf86DrvMsg(pScreenInfo->scrnIndex, X_NOTICE,
"Virtual resolutions will be limited to %d kB\n
due to"
" linear aperture size and/or placement of
hardware"
" cursor image area.\n",
ServerVideoRAM);
}
So the fix is rather simple. My question is why having different
variables with apparent same meaning and with different values?
In xf86str.h says:
/* Some of these may be moved out of here into the driver private
area */
...
int videoRam; /* amount of video ram (kb) */
Regards,
Jose Fonseca
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: How to setup DRI? Was: Bugfix for br0ken DMA on r128 andpossibly radeon DMA functions
On Tue, 2002-02-05 at 14:50, James Hawtin wrote: > Is there a guide on how to setup DRI? I have never managed to ... > ... to go to the DRI website and search for documentation? ;-) Check http://dri.sourceforge.net/doc.phtml It covers most of your questions! > James > Jose Fonseca ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XFree86 NDA documentation
On Thu, 2002-01-31 at 17:24, Mike A. Harris wrote: > On 30 Jan 2002, Jose Fonseca wrote: > > >... > > > >In the comments Mike makes strong reference to join as XFree86 developer > >as a mean to obtain NDA documentation that is shared to all XFree86 > >developers, but it was mentioned in the last IRC meeting that this is no > >longer true. > > Thats right. XFree86.org has documentation for some pieces of > video hardware that was obtained under NDA, and they are not able > to distribute that documentation to other people freely or else > that pretty much negates the whole point of an NDA. > > Just for clarification, NDA == > > > As such, in order to obtain access to this NDA information, > XFree86.org requires that you become a member of XFree86.org > first, and agree to the XFree86.org NDA. Once you've > agreed to the NDA, and have been accepted as a developer, then > you can access the documentation that XFree86.org has under NDA. ^^^ > > In order to be accepted into the project however, you need to > ... > (Thanks for your explanation about NDA and steps to be a XFree86 developer but I already had that understanding.) > > >The fact is that the XFree86 developer page > >(http://www.xfree.org/developer.html) makes no mention to this and I > >would like to know if this still holds true or not. > > Yes, it is still true. Unless every vendor that has given > XFree86.org documentation under NDA somehow decides the NDA is no > longer necessary, this process is not likely to change. > Perhaps I didn't explain myself. I was asking if XFree86 still gave access to NDA information to their _members_ or if each developer had now to get the information as a _individual_ from the hardware vendor. Anyway you answered this question already [^higlighted^]. > Please note, that the above process does NOT get you access to > the documentation of all of the ATI hardware. In order to get > ATI hardware documentation, you must become an ATI developer > relations member. If you're not an XFree86 member however, then > you wont likely be accepted into ATI developer relations unless > you meet some other criterion. > I had the impression that most of the (at least) ATI hardware documentation was available to XFree86 members since so many times ATI has declined giving documentation to more people stating that same reason [availability through the XFree86 and DRI projects]. But you seem to say otherwise here. > So, in summary: > > ... > > Out of all of the people interested in working on XFree86 or DRI, > I've noticed that people generally fall into two categories: > > 1) People who show initiative and do stuff, working with what >hardware, tools and documentation that _are_ available to >them, and asking questions about problems they encounter while >trying to fix a given bug or work on a piece of driver code. > > 2) People who have done nothing at all, but are interested in >doing so, but whom probably have not even looked at the source >code, or even tried to fix any bugs, assuming that they must >have the documentation first or it is not possible to >contribute to anything. Many of whom complain about lack of >documentation, having to agree to NDA's and whatnot. > > While #2 people often have legitimate complaints, many of the > things I have seen people complain about are static items, at > least for the time being. It is generally IMHO the #1 people who > show the most initiative, and hack away on their own, that end up > producing results, and also end up meeting the general > unofficial guidelines I've mentioned above. > > Summary of entire email: JUST DO IT > > I agree with your general picture. I just want to add that its not a black&white division between #1 and #2 people and that a good guidance from the existing projects developers can effectively change #2 people in #1... Regards, Jose Fonseca ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 NDA documentation
I've decided to add some pertinent comments from Mike Harris regarding the availability of documentation under NDA to the DRI Devel FAQ ( http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/html/hardware.html#ATI-SPECS ) In the comments Mike makes strong reference to join as XFree86 developer as a mean to obtain NDA documentation that is shared to all XFree86 developers, but it was mentioned in the last IRC meeting that this is no longer true. The fact is that the XFree86 developer page (http://www.xfree.org/developer.html) makes no mention to this and I would like to know if this still holds true or not. Regards, Jose Fonseca ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Ati Rage Mobility and X 4.1 won't resume from suspend
Frank, I also have a ATI Rage Mobility in my laptop with XFree 4.1.0 and the suspend/awake work properly. The difference is that I have RedHat 7.2 with Kernel 2.4.x. So the problem could be a side effect of a incompatibility of some kind... Best of luck, Jose Fonseca On Mon, 2002-01-21 at 10:39, Frank Steiner wrote: > Hi, > > I just upgraded from XFree 3.3.6 to 4.1 on my laptop which has a > Ati Rage Mobility chip. On 3.3.6, suspend and awake worked fine > by making the apmd switching to a text console before suspending, > using the chvt command in the apmd proxy. I'm working with SuSE > which uses a apmd_proxy script which is called from apmd and does > all this stuff. > > Now, with XFree 4.1, it doesn't work anymore. When I try to suspend > from X, the screen seems to switch to a console, because it goes black, > but half a second later it switches back to X and then suspends! Just as > if there was another "chvt 7" called just before the suspension. > I traced the apmd proxy script to make sure that the "chvt 1" is indeed > executed, but I could not find any hint about another chvt which switches > back to X. > > Neither kernel (2.2.19) nor apmd (3.0) have changed, just X, so I guess > it's a problem with X. I've found some messages in newsgroups describing > the same problem, but no solution. I also traced the xpert and newbie > list archives back to Jan 2000, but found nothing about this topic > (only recommendations to let apmd switch vt, which my apmd obviously does...) > > Does anyone have an idea what to do? > Anything else works just fine with XFree 4.1... > > Best regards, > Frank > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]code Compilation
Vikram, On Thu, 2002-01-10 at 05:19, vikram sutar wrote: > hi all, > I want to compile the XWindow Source code under VC++ 6.0. Is it > posible? How ? > Vikram > The X libraries (not the server) available from http://www.x.org compiles under VC++ for long time. With this you would have to get a X server for Win32. If you want to build the server check this site http://sources.redhat.com/win32-x11/ Hope this helps. Regards, Jose Fonseca ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Vertical lines on lower resolution modes in LCD screen
Hi. I have a ATI Rage Mobility P/M 4Mb with a 1024x768 TFT screen on my laptop with RHL 7.2 and XFree 4.1.0. For some applications (playing games and watching movies) I've found that is better to use lower screen resolutions to achieve a higher frame rate. First I tried to use a 512x384 mode to get integer scaling and better performance, but XFree complained that it was not a valid mode. My first question is if it's possible to configure a 512x384 mode for a LCD screen and how? Then I tried the standard 640x480 mode and for my surprise I didn't notice any downgrade in the speed. My second question is: What makes the rescaling after all: the graphics card itself or a dedicated LCD controller? Unfortunately not everything is a bed of roses.. Besides the expected blur due to the non-integer scaling there are two annoying green vertical lines placed 1/4 and 3/4 of the horizontal length of the screen. This must be a bug since this behavior isn't noted on Windows. Has anyone ever noticed this? Regards, Jose Fonseca ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Module stripping
I've just stripped the debugging info of XFree86 Version 4.1.99.1 (DRI mach64 branch) so that I wouldn't have to recompile everything just for cut down the file sizes (to send to someone who was limited and space and bandwidth to test), but the Xserver failed to load the libGLcore.a: (II) Loading sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/X11R6-DRI/lib/modules/extensions/libGLcore.a No symbols found in this module Failed to load debug_xform.o (EE) Failed to load /usr/X11R6-DRI/lib/modules/extensions/libGLcore.a (II) UnloadModule: "GLcore" (II) UnloadModule: "glx" (II) Unloading /usr/X11R6-DRI/lib/modules/extensions/libglx.a (EE) Failed to load module "glx" (a required submodule could not be loaded, -1073744008) All the modules that I provided to were stripped and only this particular library failed because replacing it for the non-stripped version solved the problem. >From what I've seen when peeking aroud in the Xpert mailing list and in the RHL XFree86 4.1.0 spec it's not safe to strip modules. It seems that the XFree86's module loader has some problems in loading stripped modules in certain architectures. Is this correct? But if it is so why only libGLcore.a failed to load? Regards, Jose Fonseca Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
