On Oct 28, 2010, at 6:10 PM, Pauli Nieminen wrote:
I think we should have some way for the drivers to back out of this
gracefully or at least cover their tails. E.g., allow the ddx to set
a hard upper limit for the swap_limit, in a new field max_swap_limit.
Your patch could make sure that swap_limit is never set to a value
higher than that. Then the intel and radeon ddx could set
max_swap_limit = 1 unless users somehow (xorg.conf option? dri.conf?)
opt into risky higher max_swap_limits.
True.
I intended DRI2SwapLimit to be called from DDX only. DDX only entry
wouldn't
need any checks for limit changes.
If we assume that all calls to DRI2SwapLimit are anyway driver
initiated then
max_swap_limits would only guard driver against it self.
I can add the max_swap_limit if there is real need for it.
Or some part of the implementation (your patch? the ddx itself?)
should output some warning in the x log if a value is selected that
it can't reliably handle, so app developers aren't confused to death
about weird behaviour.
DDX would have to implement the option and warning.
Ok, sounds good. As long as the ddx has control over the settable
swap_limit, i'm perfectly fine with it.
Good point. I wasn't aware of that. So something like sketched above
should/could be implemented inside the ddx instead of the common
server code. But there, where it can already exchange to the new
front, it should work, right?
yes. It would work.
Good. So that's one way to do it in the ddx.
Thanks,
-mario
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
