> > The preferred option at this point seems to be to add a new kernel > config option, e.g. CONFIG_DRM_MODESETTING or similar. Enabling the > option would prevent old X servers and Mesa from working with the DRM, > but they'd be otherwise unaffected. Disabling it would retain full > compatibility at the expense of the kernel features.
We would actually have an option per driver as I can't see all the drm drivers growing modesetting at once.. and some of them may never grow it.. so I'd consider this a driver option not a drm core option.. We would build all the code into the core the whole time if any driver selects it, non-using drivers should do things like they do now.. > Assuming we go in that direction, it seems like we'll want to hide some > of the existing (possibly dangerous) ioctls behind the new config > option. Looking at the list, it seems like we'd want to hide map > manipulation and probably the old buffer ioctls? Per-driver the core ioctls would get disabled, so if you have two cards old/new should work fine in combination.. essentially the flag per driver denotes to the drm, that it can trust that it owns the HW and a DDX won't kick it in the nuts later when X starts.. if a DDX later does something bad, the machine dying is quite acceptable. > Taking the changes even further, we could also control whether drivers > use a new-style load function or the old style (i.e. DRM core calls > into the driver or the driver calls DRM helpers to do things). This is > already partly necessary since the map ioctls can't really be supported > with a modesetting driver, so we may as well go all the way. Yes I can see for modesetting why we might want to do things with help functions, but we should be able to refactor even old drivers to a helper function model if we require it as long as it doesn't break the userspace visible abi... this will increase the per-driver per-OS code which is one reasons it is done like it is now (the other due to it being inherited from the brutal template system of old :-) Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
