----- Original Message ----- > Christian König <deathsim...@vodafone.de> writes: > >[...] > > On 26.03.2012 17:20, Francisco Jerez wrote: > >> Essentially it's an interface to enumerate the graphic devices > >> that are > >> present in the system (and by extension to create screens on them, > >> enumeration alone is useless without having a way to do something > >> with > >> the devices you find). > >> > >> You're right that traditionally this hasn't been part of the > >> winsys API, > >> but the task is very tightly coupled with the underlying window > >> system: > >> to my innocent eyes it seems that it would make more sense to > >> extend the > >> winsys API with something like this. > > > > Well, they key point is that even if it is closely related to the > > different window systems, it isn't a window system of its own! > > Hm, I think we should first settle on what a winsys is.
Kind of dated, but still relevant to this discussion: http://jrfonseca.blogspot.co.uk/2008/04/gallium3d-introduction.html A lot changed since, but the layering concept has become even stronger than it was then. On top of that, there is now the concept of a "target" (src/gallium/targets/foo), which is typically a dynamic library that links together consecutive layers (e.g., state tracker + pipe driver + winsys; or pipe driver + winsys) > 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. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
