Marc Aurele La France wrote:
apertureSize is indeed in bytes, but in xf86Modes.c, xf86InitialCheckModeForDriver() has this check. This is in XFree86 4.2.0.On Mon, 4 Nov 2002, Luugi Marsan wrote:There's a problem when validating a given mode. The board I have has 256 megs and it fails crying that it has insufficient memory for the given mode. This happens because the videoRam in bits is equal to 2^31 ( 256 megs). The number passes the numerical limit of an "int". I believe that the videoRam should be an "unsigned int" instead of a signed "int". What do you think? Will this change create other problems?Y2K all over again. :)sorry, but your number theory has some error.2^1 = 2 (1 bit, counting from 0 to 1 => 2 values) 2^2 = 4 (2 bits, counting from 0 to 3 => 4 values) 2^4 = 8 (3 bits counting from 0 to 7 => 8 values) [...] 2^31 = 2 GB 2^32 = 4 GBan integer with 32 bits has 1 bit sign and 31 bits for numeric value. this is (-2GB) to (+2GB-1). so your 256 MB limit must arise from somewhere else.for your case you should better starting the printf debugger or real debugging. maybe PCI or AGP config caps, or MTRR caps are the limiting factor, or its just a driver bug. (wild guessing)I understand, but 256 megs = 256 * 1024 * 1024* 8 bits = 2^ 31 bits= 2147483648. The Xserver calculates the memory in bits when validating the mode.No, it doesn't. apertureSize is in bytes.Marc.
--
if (mode->HDisplay * mode->VDisplay * scrp->fbFormat.bitsPerPixel > scrp->videoRam * (1024 * 8))
return MODE_MEM;
--
where:
scrp ->videoRam = 256 * 1024 ( since videoRam is in Kbytes)
When calculating the right hand side of the comparison, the right hand side is equal to 256*1024*1024*8 = 2^31. The left hand side is also calculated in bits, since it multiplies the display by the number of bits per pixel.
Luugi
