Q: puzzle about the index of PrepareAccess

[fancy fang]

So, according to your explaination, the driver PrepareAccess can not know
exactly whether the pixmap is used to read or write. Well, what's the usage
of the index passed to driver PrepareAccess?

2010/12/3 fancy fang <fancyfly09 at gmail.com>

> So, according to your explaination, the driver PrepareAccess can not know
> exactly whether the pixmap is used to read or write. Well, what's the usage
> of the index passed to driver PrepareAccess?
>
> 2010/12/3 fancy fang <fancyfly09 at gmail.com>
>
> So, according to your explaination, the driver PrepareAccess can not know
>> exactly whether the pixmap is used to read or write. Well, what's the usage
>> of the index passed to driver PrepareAccess?
>>
>> 2010/12/2 Maarten Maathuis <madman2003 at gmail.com>
>>
>> On Thu, Dec 2, 2010 at 10:48 AM, fancy fang <fancyfly09 at gmail.com> wrote:
>>> > Dear all,
>>> >            In xserver 1.9.0, there is an access array to cache previous
>>> > results to reduce cost. Howver, this optimization would modify the
>>> original
>>> > index and give the wrong index to driver PrepareAccess. Also, sometimes
>>> > driver PrepareAccess need to know the pixmap is used to be read or
>>> written.
>>> > Now, nobody can confirm that the driver PrepareAccess can get the right
>>> > index now. Can someone exaplain this? Thanks!
>>> >
>>> > Best wishes,
>>> >
>>> > Fancy
>>> >
>>> > _______________________________________________
>>> > xorg-devel at lists.x.org: X.Org development
>>> > Archives: http://lists.x.org/archives/xorg-devel
>>> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
>>> >
>>>
>>> In principle any index can be used to read and write. Often SRC and
>>> MASK will only be read and DST will be read-write (this also goes for
>>> the AUX indices), but it is possible for a pixmap to get a random
>>> index. Does that answer your question?
>>>
>>> Maarten.
>>>
>>> Maarten.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101203/a0a14529/attachment.html>