Re: [Dri-devel] New gatos API: Crashes with radeon on driver change.

[Keith W. <ke...@tu...>]

Mike Mestnik wrote:
> --- Michel D=E4nzer <mi...@da...> wrote:
>=20
>>On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
>>
>>>--- Michel Dnzer <mi...@da...> wrote:
>>>
>>>>On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
>>>>
>>>>>I have something to add to this.  Recently I tested gatos drivers go=
ing=20
>>>>>from dri to gatos was painless.  However when I went back my compute=
r=20
>>>>>locked up. =20
>>>>
>>>>That's because they have made incompatible changes to the DRM but
>>>>haven't changed its major version number to reflect that.
>>>>
>>>
>>>I think I understand what your saying.  I did a full build (make World=
 && make install),
>>>overwriting all of DRI, hopefully.  Then I did the same to get back.  =
I also updated and
>>>rmmod/modprobe the DRM, bothways.  I think what is going on here is th=
at there is some state
>>
>>that
>>
>>>needs to be cleared on init, and deinit also(in gatos and fiergl).  Th=
ats why I think there
>>
>>should
>>
>>>be a merge for the difference in state changes made on init/deinit.  I=
 don't think this should
>>>change the API, and would seem to be more of a bug fix. =20
>>
>>They use a different memory layout on the card, on which all components
>>(X server, DRM and clients) have to agree, so it's very much an API
>>issue.
>>
>>We want to move to their memory layout for several reasons, but there
>>has to be a transition which preserves backwards compatibility. That
>>provided, the problems on switching between DRMs may be gone as a bonus
>>with some luck, or it will just be a detail to work out hopefully.
>>
>=20
> I think I could tackle this.  What's needed is a dual memory layout set=
tup for the next minor
> version.  This would payve the way to release the next major version, i=
f minor >=3D x will be
> forward compatible to the new major.  I would say to have dual memory l=
ayout support for the DRM
> would be a gross wast of kernel resorces.  So it will be up to X server=
 and clients to carry the
> burdon of having the new configuration.  I know there is allready a dis=
patch table for clients,
> could we have  2 radeon drivers?  For the ONE(currently active) Xserver=
 it seams as thought just a
> select for dispatching would be a temporary solution.  How long would w=
e need to maintain the
> proposed hack?  Would all the developers be willing to switch to the ne=
w major version once it's
> working front and back?  Is gatos's DRM up to the challenge or dose it =
need work so it can replace
> the current?
>=20
> By dual memory layout I'm saying that the client/X would have 2 drivers=
 one for the old kernel and
> one for the new.

I doubt you'd need two whole new drivers -- just a couple of things that =
are=20
constants now would have to be set on the fly.  Most addresses get set up=
 by=20
the X server and everyone follows from there.

Maybe the easiest thing would be to hack up a non-backwards-compatible ve=
rsion=20
of X, kernel and client drivers, and post the diff to the list.  Then we =
can=20
see how to trim that down & make it backwards compatible.

Keith