New DRM model

[Jon Smirl]

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 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.

If the clients are restricted from direct card access and required to use a
supplied library then the 2D/3D issue can be avoided by just leaving the card in
3D mode. All of the 2D commands have parallels on the 3D side. The library will
hide whether 2D or 3D comannds are begin sent. 3D commands also work better from
user space since the don't need to play with the registers. Even though I'm
pushing OpenGL as the main graphics API, the DRM API is always there too. For
example my planned terminal emulator was going to use the DRM API directly.

A more important point is restricting access to the framebuffer. There really,
really needs to be a global entity controlling the contents of this buffer. 
It's just going to be impractical when we get 1GB graphics cards to rebuild the
state of the framebuffer on each VT switch. I'd vote to shut off direct app
access to it entirely  and require the use of the library to manipulate it. It
might even be possible to shut direct access down to it completely and do
everything via the 3D queue.

> 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.

Right now my goal is to just to get a single monitor into it's EDID detailed
timing mode. That will be enough to let me start playing with the user space
console idea.

EDID from user space turns out to be very simple. I just lifted Luca's I2C code
out of radeonfb and loaded the I2C eeprom driver. Bingo, my EDID data is sittng
there for userspace to see. It is also easy to tell what ports have monitors
attached, they're the ones with EDID data.

It's a lot of work supporting non-EDID monitors. Are they common enough anymore
to bother? I retired all of mine about four years ago.

> 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 am just referencing XFree. XFree knows how to do a lot of things that xserver
doesn't.


> > 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.

I slowly working through all of the places where Xfree touches the hardware. I
haven't come to a conclusion on this yet -- whether to use IOCTLs or a daemon.
I'm not too enthused about adding 100 IOCTLs if that's what it takes.

> 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. 

I'm all for this. It's a big project.

> 
> Ben.
> 
> 


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html