Anyone objections to pulling over the ttm interface ioctl changes?
These are going to be annoying no matter when I do it .. so I'd like
to get it out of the way..
Dave.
-
This SF.net email is sponsored by DB2 Express
Downloa
Dave Airlie wrote:
> Anyone objections to pulling over the ttm interface ioctl changes?
>
> These are going to be annoying no matter when I do it .. so I'd like
> to get it out of the way..
>
> Dave.
Dave,
can you give me a day or so to review?
/Thomas
-
Dave Airlie wrote:
> Anyone objections to pulling over the ttm interface ioctl changes?
>
> These are going to be annoying no matter when I do it .. so I'd like
> to get it out of the way..
>
> Dave.
OK, so I've pushed some changes, the most important of which are ioctl
arg support for tiled buffe
On 6/12/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Dave Airlie wrote:
> Anyone objections to pulling over the ttm interface ioctl changes?
>
> These are going to be annoying no matter when I do it .. so I'd like
> to get it out of the way..
>
> Dave.
OK, so I've pushed some changes, the most
Kristian Høgsberg wrote:
> On 6/12/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> Dave Airlie wrote:
>> > Anyone objections to pulling over the ttm interface ioctl changes?
>> >
>> > These are going to be annoying no matter when I do it .. so I'd like
>> > to get it out of the way..
>> >
>> > D
On 6/12/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Kristian Høgsberg wrote:
...
> > I was reviewing the xf86mm.h interface, and I was wondering, do we
> > really need to put the structs in the header? Could we get away with
> > just adding a couple of accessor functions and then keeping the
> > > cheers,
> > > Kristian
> > >
> > Kristian,
> > This is OK with me. It will add an extra malloc / free for every buffer
> > object creation / destruction,
> > but will make it easier to maintain in the future, (and we can get rid
> > of the padding for future expansion).
>
> Exactly, I took ou
Dave Airlie wrote:
>> > > cheers,
>> > > Kristian
>> > >
>> > Kristian,
>> > This is OK with me. It will add an extra malloc / free for every
>> buffer
>> > object creation / destruction,
>> > but will make it easier to maintain in the future, (and we can get rid
>> > of the padding for future exp
On 6/14/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
> >> > > cheers,
> >> > > Kristian
> >> > >
> >> > Kristian,
> >> > This is OK with me. It will add an extra malloc / free for every
> >> buffer
> >> > object creation / destruction,
> >> > but will make it easier to maint
Kristian Høgsberg wrote:
> On 6/14/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>> Dave Airlie wrote:
>> >> > > cheers,
>> >> > > Kristian
>> >> > >
>> >> > Kristian,
>> >> > This is OK with me. It will add an extra malloc / free for every
>> >> buffer
>> >> > object creation / destruction,
>> >
On 6/14/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Kristian Høgsberg wrote:
...
> > True. And if we bump libdrm major version, we can drop the hash table
> > and skip lists too. With DRI interface changes, I moved the hash
> > table implementation into libGL, the only place it's used.
> >
Kristian Høgsberg wrote:
> On 6/14/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
>> Kristian Høgsberg wrote:
>
> ...
>
>> > True. And if we bump libdrm major version, we can drop the hash table
>> > and skip lists too. With DRI interface changes, I moved the hash
>> > table implementation in
On 6/10/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Dave Airlie wrote:
>
> > Anyone objections to pulling over the ttm interface ioctl changes?
> >
> > These are going to be annoying no matter when I do it .. so I'd like
> > to get it out of the way..
> >
> > Dave.
>
> Dave,
> can you give me
Kristian Høgsberg wrote:
> On 6/10/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
>> Dave Airlie wrote:
>>
>> > Anyone objections to pulling over the ttm interface ioctl changes?
>> >
>> > These are going to be annoying no matter when I do it .. so I'd like
>> > to get it out of the way..
>> >
14 matches
Mail list logo
