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

Gaetan Nadon memsize at videotron.ca
Sun Nov 13 18:12:44 PST 2011


On Mon, 2011-11-14 at 03:10 +0200, Martin-Éric Racine wrote:

> 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.
> 

I ?think? I have figured out part of it. It is relatively simple.

Geode driver should use AC_SYS_LARGEFILE. It's job is to test the size
off_t. If 64, it defines #define _FILE_OFFSET_BITS 64 on system where it
can be set. With this being set, lseek will become lseek64 and off_t
will become off64_t. This behaviour is described in Linux man page
http://linux.die.net/man/3/lseek64. 

The geode_msr.c code should not hard code lseek64 or off64_t as these
are not defined by all OS such as FreeBSD.

        ret = lseek64(fd, (off64_t) addr, SEEK_SET);

This is what prompted FreeBSD to define lseek64 and off64_t.
With this fix, which is trivial to test, FreeBSD will work and so will
any platform.

Another thought. Perhaps FreeBSD was a 32 bit version (with 64 bit,
durango.c would fail). In this case AC_SYS_LARGEFILE is not needed and
we just need to replace lseek64 with lseek. Comes to think of it, it's
strange to code lseek64 on code that only compiles on 32 bit OS.

It looks like you have found more porting issues, I'd be surprised if
there were only one.


> Martin-Éric


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-geode/attachments/20111113/a1a365fa/attachment.html>
-------------- 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/20111113/a1a365fa/attachment-0001.pgp>


More information about the Xorg-driver-geode mailing list