On Saturday, September 29, 2007 6:47:51 am Dave Airlie wrote: > > 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..
Yeah, that sounds like a better way to handle driver migration. > > 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. So we'd just expose modesetting and TTM ioctls from new style drivers? > > 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 :-) Yeah, I was thinking the same thing. Just careful refactoring and updating will be required. Jesse ------------------------------------------------------------------------- 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
