On Tuesday 26 June 2012 16:33:44 Adam Jackson wrote: > The following series, when combined with appropriate DDX driver fixes, > allows X to initialize without a config file even when iopl/ioperm are > unavailable on an architecture which otherwise has them. This is useful > when the system security policy forbids it, for example for UEFI Secure > Boot compliance. > > The requisite driver changes, assuming you're not trying to work against > arbitrary server ABIs, amount to "if xorgHWAccess is exported at build > time, check it early in probe". This happens to be source-compatible > with a fairly long range of servers due to xf86Priv.h inexplicably being > an SDK header despite the name. That's a mistake we ought to fix, so > subsequent to this series the declaration moves to xf86.h. > > Tested with a KMS radeon config on F17. > > common/xf86.h | 1 > common/xf86Bus.c | 11 ----- > common/xf86Configure.c | 27 ------------- > common/xf86Init.c | 23 +++++------ > common/xf86Priv.h | 1 > os-support/linux/lnx_video.c | 89 ++++++++++++++++++++++++------------------- > 6 files changed, 63 insertions(+), 89 deletions(-) > For the whole series: Reviewed-by: Simon Farnsworth <[email protected]>
I twice thought I'd seen bugs, but a closer look showed me wrong - the huge chain of "#if !defined(<arch>) || !defined(<arch>)" in lnx_video.c being replaced by a smaller chain of "if defined(<arch>) || defined(<arch>)" caught me at first, but appears to be what was actually intended. The sequence by which xorgHWAccess is changed from meaning "we want access" to "we have access" between InitOutput and the driver probe function wasn't immediately obvious. It might be nice to mention in the comment in xf86Init.c where you say 'this is "do we want it" at this point' that xf86BusConfig() will call xf86EnableIO() when xorgHWAccess is TRUE, or move the call of xf86EnableIO() into InitOutput. But that's nit-picking, so feel free to ignore me. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
