On Mon, 2011-11-14 at 09:13 +0200, Martin-Éric Racine wrote: > 2011/11/14 Marc Balmer <mbal...@netbsd.org>: > > Am 14.11.11 02:10, schrieb Martin-Éric Racine: > >> 2011/11/14 Gaetan Nadon <mems...@videotron.ca>: > >>> On Sun, 2011-11-13 at 23:51 +0200, Martin-Éric Racine wrote: > >>> > >>> It just occured to me that Marc Balmer once contacted the list with an > >>> announce that he was maintaining the OpenBSD port of xf86-video-geode. > >>> Let's see if he can participate in this discussion and provide some of > >>> the answers. Who knows, he might already have a usable diff to provide > >>> us with as a starting point. :) > >>> > >>> > >>> Great. > >>> > >>> http://www.openbsd.org/i386.html#hardware > >>> > >>> Geode listed as being supported. > >>> > >>> http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-video-geode/ > >>> > >>> I could not really see any code changes having been done. > >> > >> Try the diff to these two, for starters: > >> > >> --- xf86-video-geode/src/Makefile.am > >> +++ OpenBSD/xenocara/driver/xf86-video-geode/src/Makefile.am > >> > >> --- xf86-video-geode/src/geode_msr.c > >> +++ OpenBSD/xenocara/driver/xf86-video-geode/src/geode_msr.c > >> > >> There's also some interesting changes to *_driver.c and to lx_exa.c as > >> well. A worrisome number of #ifdef, rather than > >> autoconf/automake/libtool magic, but it's still a nice start. > >> > >>> on OpenBSD/i386 (32 bit) and not 64 bit which would be OpenBSD/amd64 > >>> (Intel > >>> EMT64 is considered a clone of AMD64). If I see this correctly, the > >>> OpenBSD > >>> geode driver does not run on 64 bit and therefore would not be of a great > >>> help. > >> > >> It does help us see how OpenBSD dealt with the lack of V4L2 capability > >> and with finding the MSR on their platform, among other things. That's > >> a good start for adding BSD support in general. > > > > What I did to make xf86-video-geode usable on OpenBSD was to write an > > amdmsr(4) driver which handles the MSR access. So the driver is > > different from the Linux variant in how it accesses MSRs, the rest is > > more or less unchanged. > > > > See > > > > http://www.openbsd.org/cgi-bin/man.cgi?query=amdmsr&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html > > > > for the manual page, or > > > > http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/i386/i386/amdmsr.c?rev=1.9;content-type=text%2Fplain > > > > for the code. > > > > This way, lseek is not needed to access MSRs. > > Marc, > > Thank you for your reply. > > I'm currently trying to merge all changes performed by non-Linux > distributions into GIT. Ideally, we'd prefer changes to be as > unintrusive as possible i.e. autoconf magic rather than hardcoded
I had a look at the diff C code, nothing stands up as being able to be handled by autoconf. I would suggest to Marc that the code using the amdmsr method should be wrapped with something other than __OpenBSD__. This is to separate "OS porting differences" vs "alternate implementation differences". This amdmsr could very well be used on NetBSD for example. Something like #ifdef USE_AMDMSR perhaps. In configure.ac we could have a --enable-amdmsr and/or auto-detection. This would leave __OpenBSD__ for strict OS porting issues. This new define could be added in the xorg geode driver now, even if only used a little later. > #ifdef, but we'll take what we can get our hands on anyhow, just as > long as the changes are properly documented and won't prevent building > on Linux. > > Others: FYI, I attached a diff between GIT and what OpenBSD currently > has, for your convenience. > > Best Regards, > Martin-Éric
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xorg-driver-geode mailing list Xorg-driver-geode@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-geode
