thanks for the clarification .. i have tested .. it works will you please commit this to the git ? i was planning to post a kernel bug anyway
On Thu, Mar 6, 2008 at 4:19 PM, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > On Thu, Mar 06, 2008 at 02:39:24PM +0530, Sriram Neelakandan wrote: > > Hi all, > > > > > > I think i have found the root cause of all the problems > > > > In dfb_fbdev_set_mode called from primaryInitLayer (fbdev.c1108) as > > > > Listing from fdbdev.c : 1102 > > > > tmp.format = DSPF_RGB16; > > tmp.buffermode = DLBM_FRONTONLY; > > tmp.source.x = 0; > > tmp.source.y = 0; > > tmp.source.w = config->width; > > tmp.source.h = config->height; > > if (dfb_fbdev_set_mode( NULL, NULL, &tmp )) > > > > NOTE: config->width & height have been setup in tmp.source.w & > tmp.source.h > > > > But the code inside dfb_fbdev_set_mode (Line fbdev.c:1647) > > > > vxres = config->width; > > vyres = config->height; > > > > var.xoffset = source->x; > > var.yoffset = source->y; > > > > uses config->width & height for vxres & vyres ! > > > > Please note that "config", which is "tmp" in the caller has width & > height > > uninitialized. > > But only tmp.source.w & h initialized. > > > > This was the reason for the huge vxres & vyres values, > > Yes, that looks like a genuine bug. > > > which led to the KERNEL PANIC > > I don't think that should happen even if you pass totally bogus stuff to > the ioctls(). It seems i810fb doesn't properly check some of the input. > You might want to report the oops to the fbdev-devel list and/or file > a bug in the kernel bugzilla. I have a feeling i810fb isn't actively > maintained these days but at least it's good to have a record of such > bugs. > > > It was also the reason for the SurfaceCreate failure > > > > I donot know what is the right way to call this API...but changing the > lines > > to this fixes the issues > > > > vxres = source->w; > > vyres = source->h; > > > > i have attached a patch for tracking the exact change. > > Please accept the patch in case if required. > > The correct way to fix this would be to initialize tmp.width and > tmp.height in primaryInitLayer(). They specify the virtual resolution > whereas source.w/h specify the size of the visible part. I made a patch > but I can only compile test it right now. Here it is: > > diff --git a/systems/fbdev/fbdev.c b/systems/fbdev/fbdev.c > index ba6dd74..4096c39 100644 > --- a/systems/fbdev/fbdev.c > +++ b/systems/fbdev/fbdev.c > @@ -1098,7 +1098,10 @@ primaryInitLayer( CoreLayer > *layer, > config->buffermode = DLBM_FRONTONLY; > config->width = default_mode->xres; > config->height = default_mode->yres; > - > + > + memset( &tmp, 0, sizeof(CoreLayerRegionConfig) ); > + tmp.width = config->width; > + tmp.height = config->height; > tmp.format = DSPF_RGB16; > tmp.buffermode = DLBM_FRONTONLY; > tmp.source.x = 0; > > -- > Ville Syrjälä > [EMAIL PROTECTED] > http://www.sci.fi/~syrjala/ <http://www.sci.fi/%7Esyrjala/> > -- Sriram Neelakandan Author - Embedded Linux System Design And Development ( http://tinyurl.com/2doosu)
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
