Re: [Linux-fbdev-devel] [PATCH] aty128fb 15/16 bit cleanup

[Sven L. <lu...@dp...>]

On Wed, Jun 27, 2001 at 11:44:55PM +0200, Michel D=E4nzer wrote:
> Sven LUTHER wrote:
> >=20
> > On Wed, Jun 27, 2001 at 11:18:07PM +0200, Michel D=E4nzer wrote:
> > > Sven LUTHER wrote:
> > > > But again, X actually thinks that they are responsible for handli=
ng the
> > > > card, and the DRI follows their lead. It is the X driver who hand=
les the
> > > > switch between the 2D and various 3D contexts.
> > >
> > > That's not correct. In the DRI context, the X server is one of many
> > > clients the DRM mediates hardware access between.
> >=20
> > mmm, but itis the X driver which fournish the register save/restore r=
outins,
> > at least that is how i see it. True it is the drm who calls them, i t=
hink,
> > but still, if you have no X running, i don't know how the save/restor=
e stuff
> > is handled.
>=20
> This is also getting shaky ground for me, but AFAIK each client of the =
DRM is
> responsible to maintain its own context.

At least in the glint driver, in the glint_dri.c function, there is a fun=
ction
called glint_switch_context or something such, which can save and restore=
 both
2D and 3D contextes.

I have not seen any such thing in the openGL/mesa code, but then i did no=
t
look yet much at it.

From what i see, the X glint driver fills in the function in the dRI
structure, and later on, dri/drm can call it when switching context.

> > I suppose you could have any user app initializing the drm with the
> > contec=3Dxt swithc function, but X and drm are very thigly intertwine=
d.
>=20
> There must be special communication between the X server and its client=
s
> because they need to know where the windows are etc.

Yes, but it is much more than that, i have the feeling.

> > Also, it seems the drm modules (or builtins) know really nothing abou=
t the
> > underlaying hardware, it is the X server who tells them where the chi=
p is,
> > and what kind of chip to use.
>=20
> Nope, the DRM finds the chip on its own. Just load the module and watch=
 its
> output.

No, i was able to load the gamma module on a matrox G400 equiped system. =
Am
sure if i provided it with the right values, it would have happily tried =
to
write to the G400 as it was a gamma chip. Have'nt tried though, and could=
 have
missed some identification stuff.

Anyway, the kernel part of the drm is rather dumb. Not much more than dma
handling and interrupt stuff, or so it seems to me.

Friendly,

Sven Luther