On Fri, Feb 06, 2015 at 05:38:55PM -0800, Bryce Harrington wrote:
> On Fri, Feb 06, 2015 at 04:01:51PM -0800, Jon A. Cruz wrote:
> > On 02/06/2015 03:50 PM, Bryce Harrington wrote:
> > > On Fri, Feb 06, 2015 at 12:29:02PM -0800, Jon A. Cruz wrote:
> > >>
> > >> My initial concern with this is that
On Fri, Feb 06, 2015 at 04:01:51PM -0800, Jon A. Cruz wrote:
> On 02/06/2015 03:50 PM, Bryce Harrington wrote:
> > On Fri, Feb 06, 2015 at 12:29:02PM -0800, Jon A. Cruz wrote:
> >>
> >> My initial concern with this is that it changes from one hardcoding to
> >> two hardcodings. Is 565 the only othe
On 02/06/2015 03:50 PM, Bryce Harrington wrote:
> On Fri, Feb 06, 2015 at 12:29:02PM -0800, Jon A. Cruz wrote:
>>
>> My initial concern with this is that it changes from one hardcoding to
>> two hardcodings. Is 565 the only other format that will need to be
>> supported? Could XRGB888 or others als
On Fri, Feb 06, 2015 at 12:29:02PM -0800, Jon A. Cruz wrote:
>
> My initial concern with this is that it changes from one hardcoding to
> two hardcodings. Is 565 the only other format that will need to be
> supported? Could XRGB888 or others also be needed?
>
> If this needs changing it might be
My initial concern with this is that it changes from one hardcoding to
two hardcodings. Is 565 the only other format that will need to be
supported? Could XRGB888 or others also be needed?
If this needs changing it might be good to be sure it is comprehensive.
On 02/03/2015 02:52 PM, Dongwon Ki
In current code, color format is always hardcoded to __DRI_IMAGE_FORMAT_ARGB
when buffer or DRI image is allocated in function calls, get_back_bo and
dri2_get_buffers,
regardless of current target's color format. This problem may leads to
incorrect render
pitch calculation, which eventually e
