On Sat, 2002-07-06 at 23:43, Michel Lanners wrote: > Since nobody seems tempted to reply ;-), I'll add a bit more info > myself... > > On 3 Jul, this message from To: [EMAIL PROTECTED] echoed through cyberspace: > > I've come across a probelm with X 4.1 and 4.2 (4.0 was fine). I'm trying > > to avoid using shadowfb for performance reasons. > > > > Anyway, upon initialization, I get a segfault whn not using shadowfb. > > Here's the backtrace: > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x10253c9c in fbBlt (srcLine=0x10af2f68, srcStride=4, srcX=0, > > dstLine=0x30545010, dstStride=1536, dstX=0, width=128, height=0, alu=3, > > pm=4294967295, bpp=32, reverse=0, upsidedown=0) at fbblt.c:174 > [snip] > > > > dstLine in fbBlt() points to nowhere. > > More hard looking revealed that the framebuffer line length is > calculated wrong (too big), making the framebuffer access go horribly > out of bounds. In drivers/fbdev/fbdev.c, FBDevPreInit(), line 528: > > pScrn->displayWidth = fbdevHWGetLineLength(pScrn)/(fbdevHWGetDepth(pScrn,NULL) >> >3); > > fbdevHWGetLineLength() is OK; but fbdevHWGetDepth() returns 24. This is running > depth 24, but the framebuffer is 32 bpp. So, to get the line length in > pixels, the calculation should be done with fbbpp instead of depth. > > Now, the question is: how? > > fbdevHWGetDepth() has a second argument, an int *. If provided, it is > filled with the fbbpp as: fPtr->var.bits_per_pixel. Wouldn't this be the > better choice for calculating the line length? > > I'll test this as soon as the recompile finishes... Comments?
Looks good to me, and I think I'm guilty of writing that code. :) I still wonder though if this will work the first time if the console is run at a different bpp. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
