Jose Fonseca <jfons...@vmware.com> writes: >[...] >> In my >> understanding it's a set of primitives that abstract the platform >> specific details of the implementation, where "details" include: >> - device binding >> - memory management >> - command submission > >> My proposal boils down to including "device enumeration" among these >> categories, because the implementation to use is going to be highly >> dependent on the specific platform and display architecture we're >> running on, e.g. it's not going to be the same when running on X/DRI, >> on >> the bare DRM device, on other operating systems... > > I think the big disconnect here is that a "winsys" has the details you > mention but is HW specific. > > Therefore a module that loads something depending on the HW cannot possibly > be a winsys. > > Given your module talks about pipe_screen, it's either a state tracker, or a > helper module that's used by state trackers. > > Granted, the "winsys" name is not very en-lighting -- maybe "pipe driver > backend" would be better --, but its role is clear nevertheless. > Hmm, okay. If we don't want to think about it as part of the winsys API I'm also changing its name back to pipe-loader. Updated patches coming in a moment.
> Jose
pgpuap6sHKGJ0.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
