And of course that time I missed the Reply All button....<div> </div><div>Thanks,</div><div>Kevin ---------- Forwarded message ---------- From: Kevin Murphy Date: Thursday, May 10, 2012 Subject: [PATCH] drm: fixed bug regarding minimal buffer size To: Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> Ah, I thought I pasted it in.... My mistake. Here it is, for real this time :) Thanks, Kevin On Thu, May 10, 2012 at 3:22 AM, Dave Airlie <<a href="javascript:;" onclick="_e(event, 'cvml', 'airlied@gmail.com')">airlied@gmail.com</a>> wrote: > On Thu, May 10, 2012 at 6:15 AM, Ray Strode <<a href="javascript:;" onclick="_e(event, 'cvml', 'halfline@gmail.com')">halfline@gmail.com</a>> wrote: >> Hey, >> >> On Wed, May 9, 2012 at 3:43 PM, Kevin Murphy <<a href="javascript:;" onclick="_e(event, 'cvml', 'kemurphy.cmu@gmail.com')">kemurphy.cmu@gmail.com</a>> wrote: >>> If we ask for a buffer of size 0 when testing for 32bpp framebuffer >>> support, we trigger a condition in the kernel that will cause the >>> test to fail, ultimately causing a fallback to the framebuffer >>> driver. >>> See <a href="http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_bo.c#L1193" target="_blank">http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_bo.c#L1193</a> >>> for the block of code that gets triggered. >> >> Oh, bummer. So ttm drivers report a min_width that's less than they support? >> >>> Compiz ran into a similar >>> issue at some point and they just forced each minimum dimension to 2 >>> if it detected it was about to ask for a 0, so that's the approach I >>> took. >> Sounds fine. I think you forgot to attach the patch though? > > Yeah a size > 0 is probably a good plan, I'll fix the kernel to not > report 0 as well. > > Dave. </div>