Graham Gower schrieb: > Peter Wehrfritz wrote: > >> Graham Gower schrieb: >> >>> Peter Wehrfritz wrote: >>> >>>> I committed it without the @EVAS_LIBS@, because Vincent told me that >>>> it is not needed. Can you check please if it works now? Since I don't >>>> have ecore_fb installed, I cannot test it myself. >>>> >>> Yes, this works fine. >>> >> Nice :) >> >>> One other issue which may require attention is >>> ewl/src/engines/evas_fb/ewl_engine_evas_fb.c: ee_canvas_setup(), line 190 >>> >>> ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, 240, 320); >>> >>> This hardcoded size 240x320 is a problem on our 480x272 framebuffer. It >>> causes evas to try to access mmap()ed framebuffer memory outside the >>> size that is actually mmap()ed. Hardcoding the geometry request to >>> 480x272 >>> made the problem go away. >>> >>> Perhaps this value can be obtained from the size of the framebuffer >>> instead? I didn't see a 'struct fb_var_screeninfo' lying around, or I'd >>> have used that and sent a patch. >>> >> Indeed, hardcoding the value is very bad. As I said before I've never >> used the evas_fb engine, so I have no experience with it. Maybe it is >> possible to query the size with ecore_fb_size_get(). >> > > Cool, I tested this and it works for me (with ewl_simple_test). > > --- /home/ggower/ewl_engine_fb.c 2008-12-15 09:06:40.000000000 +1030 > +++ ewl/src/engines/evas_fb/ewl_engine_evas_fb.c 2008-12-15 > 09:06:25.000000000 +1030 > @@ -165,6 +165,7 @@ > Evas_Engine_Info *info = NULL; > Evas_Engine_Info_FB *fbinfo; > Ewl_Object *o; > + int w, h; > > DENTER_FUNCTION(DLEVEL_STABLE); > DCHECK_PARAM_PTR(win); > @@ -187,7 +188,9 @@ > fbinfo->info.refresh = 0; > fbinfo->info.rotation = 0; > evas_engine_info_set(evas, (Evas_Engine_Info *)fbinfo); > - ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, 240, 320); > + > + ecore_fb_size_get(&w, &h); > + ewl_object_geometry_request(EWL_OBJECT(win), 0, 0, w, h); > > o = EWL_OBJECT(win); > evas_engine_info_set(evas, info); >
Thanks, in svn. > > ewl_test, on the other hand, still tries to write past the end of the > framebuffer (it did with a hardcoded value too). > Something is adding 4 pixels to the x and y dimensions. > 4 pixels sound like inset or padding pixels. Since the size request happens before the realization some pixels for the inset will be added later, when the theme data is loaded. I think for the framebuffer, unlike to the x11 engine, the engine should take care of resizing evas and not the window. Unfortunately I have not much time before Christmas to look on it. Maybe I'll find the time after the holidays. In order that you report keeps in mind I put it into bugzilla: http://bugs.enlightenment.org/show_bug.cgi?id=553 Thanks Peter ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
