Re: New DRM model
Benjamin Herrenschmidt <[email protected]>
| Newsgroups | gmane.comp.freedesktop.xserver |
|---|---|
| Message-ID | <1076375818.770.6.camel@gaston> |
> 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.