[Xorg-driver-geode] FreeBSD patch for xf86-video-geode 2.11.12

Gaetan Nadon memsize at videotron.ca
Wed Nov 16 10:55:31 PST 2011


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 <mbalmer at netbsd.org>:
> >>> Am 14.11.11 02:10, schrieb Martin-Éric Racine:
> >>>> 2011/11/14 Gaetan Nadon <memsize at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-geode/attachments/20111116/6ed21f6b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-driver-geode/attachments/20111116/6ed21f6b/attachment.pgp>


More information about the Xorg-driver-geode mailing list