Am 14.11.11 15:14, schrieb Gaetan Nadon: > 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.
That would be a mistake, please leave the "__OpenBSD__" symbol. The amdmsr(4) driver is actually only available on OpenBSD, the other BSDs don't have it and it is unsure whether they ever will (maybe NetBSD on day, but it's unlikely). Someone in NetBSD tries to use some sort of DRI, KMS stuff for the mode setting. If another BSD should get amdmsr, we can still change the symbol. > > >> #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 _______________________________________________ Xorg-driver-geode mailing list Xorg-driver-geode@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-geode