Jesse Barnes wrote: > At XDS and on IRC we've been discussing how to deal with backward > compatibility (i.e. old Mesa & X on new DRM) once we have things like > full TTM and modesetting support in the kernel. > > 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. > > 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? > > 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. > > Any thoughts here? I can start refactoring this stuff in the > modesetting tree assuming we have agreement on some of the major > portions. > > Thanks, > Jesse >
I am for hiding "old" drm ioctl so it can be killed in the future. For the ioctl i think it's best to make driver call into drm as an helper (wasn't this the original purpose of core drm ? :)). Also if driver want to work around some drm things it can easily do that. This are my feeling based on my limited understanding of the whole drm beast, so i can be deadly wrong (hope i am not :)). Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
