On Wed, 2011-11-16 at 08:36 +0100, Marc Balmer wrote: > 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.
That is what I was suggesting we should avoid. It not a big issue, as it works either way, and I won't be the one writing the code. > > > > > > >> #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