I think we'll see distro schedules and kernel schedules gradually align themselves so that non-enterprise distros will automatically pick up the most recent kernel release while it's still fresh. Right now kernel packagers need to plan around both X and kernel release schedules in order to pick up new hardware, but as hardware-specific code moves out of the X drivers and into either the kernel or Gallium3D this should become a lot easier for everyone to manage.
I'm not sure if the Gallium3D code is built as a separate library or is linked into the state tracker, but there's a good argument for having it independent of the state trackers so that only the Gallium3D library needs to be updated. This is all "next year" stuff of course; there aren't enough drivers using Gallium3D yet for this to be a practical solution for distros today.
I'm not sure if the Gallium3D code is built as a separate library or is linked into the state tracker, but there's a good argument for having it independent of the state trackers so that only the Gallium3D library needs to be updated. This is all "next year" stuff of course; there aren't enough drivers using Gallium3D yet for this to be a practical solution for distros today.
Comment