New DRM model

Benjamin Herrenschmidt benh@kernel.crashing.org
Tue, 10 Feb 2004 12:17:20 +1100


> I was going to write an IOCTL for actually setting the mode into the card but
> I'm not that far along yet. 

Ok, well, it's more than just an ioctl that we need here, and it's more
than just one mode. Also, there is the whole problem of properly dealing
with the engine reset triggered by a mode switch, since the mode setting
library will be completely independant from whatever clients are
currently sending 2D or 3D commands to the card.

We need not only a kind of futex, but also a way, for the GL client,
to know right away after getting ownership of the futex, that a reset
did occur since it's last ownership, and thus some state may need to be
restored. (Or current operations just canceled, I don't know what is the
proper policy here).

The mode switch itself isn't trivial, I've been spending a signficant
time experimenting various setups that even xfree doesn't deal with
properly etc... I suggest you don't bother with that part at the moment,
at least for radeon, I think I now have the necessary bit to make that
happen.

One thing is that that whole part (card probing, mode setting, etc...)
is basically just duplication of radeonfb. I think we should cooperate
better on this.

>  There are a bunch of other places where the Xfree
> driver touches the Radeon registers; I'm slowing working through them. So far I
> have fixed VBIOS reset, reading the VBIOS, I2C, getting the PCI ID, mem size,
> register locations, plus everything DRM already did. I'm not far along enough
> yet to know if is is reasonable for the user space library to not touch the
> registers directly.

Why not work on xserver rather than XFree code base ? :)

> I haven't seen these discussions but I'm on the same page here. I just want to
> extend use of this library to replace the VC/TTY/FB subsystem too. That way
> there will only be a single library that touches the hardware.

No. A library that touch the hardware is no good for security if it
can be used within a non trusted process. At one point, the HW has to
be touched by the kernel driver only.

Depending on how I can spare time (difficult but I'll try), I'll look
at your code more closely and see how we can converge a	bit better on
this. 

Ben.