> > > > Because it probably wasn't noticed, feel free to resend it. > > > > I'm not sure why you need a version inside the via_drm.h but I'm > > willing to accept that the via driver development process is messed up > > enough to require it. No other driver has needed it. > > How do graphics drivers tell whether they are building or running > against a compatible drm driver? Is any driver attempting to handle both > building and running against compatible drm versions in a graceful > manner?
They shouldn't have to. At build time they just require a certain version, you shouldn't be building half the features into the driver because it has an old _drm.h file. In an ideal world we would have all this stuff hidden at the libdrm level but that never happened. So generally drivers now do one of two things. a) get a copy from kernel/libdrm, if its not new enough get a newer one installed, i.e. normal dependencies. b) ship a copy of the header file with the driver to build against it. The kernel API is runtime compatible it shouldn't have incompatible changes, so at driver startup it asks the kernel the version and does the right thing for that version, again this versioning has no use. So if VIA drivers were developed in a reasonable fashion none of this would be necessary really, its seems like a technical workaround to a social issue, since no other DRI driver has required it. > This versioning code btw, has been sitting in drm master since 2006. Why > is this not present in the kernel tree? Are you telling me that, at no > time in between, there has been a point where both the kernel and some > stable branch away from drm master have been in complete sync? Never, one of the many reasons drm.git has been put out to pasture. I probably missed this patch the first time, and then just wasn't sure what it was actually doing after that. > > It was discussed on unichrome-lists, but not on dri-devel where normally > > decisions like that would be done, but whatever, be paranoid, if you > > really can't be useful then please don't bother being here at all. > > Eh? > > This patch here was i believe passed around before, according to > mail-archive, it was originally sent to dri-devel on the 6th of january, > and nobody cared. I have later seen this code included in the openSUSE > kernel, without any communication with the SUSE X developers. And this > code breaks the build of unichrome (because unichrome tries to be smart > and checks, whereas openchrome just blindly continues), and where it > regresses under both openchrome and unichrome. > > Because it was included in opensuse, and because i have seen what effect > this code has, i do care about pointing out the issues with this code > now. > > What is your reason to care all of a sudden? When someones sends patches to this list, I generally try to review them as I'm the kernel maintainer. Since VIA patches have been known to either a) languish b) be ignored c) spat on d) end up being political, I'd like to try and have some sort of actual technical input rather than, my 15th branch, once removed VIA driver will break if you do this. And VIA have requested I look at patches to help them figure out the process, you know actually be useful instead of bitch about the way things were 4 years ago every time anyone tries to move forward. Dave. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
