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

[Martin-Éric Racine]

2011/11/13 Gaetan Nadon <memsize at videotron.ca>:
> On Sun, 2011-11-13 at 18:45 +0200, Martin-Éric Racine wrote:
>
> 2011/11/13 Gaetan Nadon <memsize at videotron.ca>:
>> On Sun, 2011-11-13 at 16:09 +0200, Martin-Éric Racine wrote:
>>
>> 2011/11/13 Mart Raudsepp <leio at gentoo.org>:
>>> I don't have any particular idea about the FreeBSD side of things (does
>>> BSD really not have separate 64bit largefile offset handling routines?).
>>
>> Apparently not. 64-bit variants of everything seem to be defined via
>> sys/types.h, but neither lseek or off_t seem to have any defined.
>
> I don't fully understand, but the issue is explained here:
> http://freecode.com/articles/largefile-support-problems
>
> FreeBSD has dropped 32bit support unlike Linux. So off_t is always 64 bit.
>
> Who ever wants to port the code to FreeBSD should look at the X server code
> which runs on several platforms. It does not use lseek64 or off64_t. It does
> use AC_SYS_LARGEFILE in configure.ac which provides some support that I
> don't really understand. It will probably affect the z4l.c file as well.
>
> So what we did with __FreeBSD__ is just plain wrong.
>
> One question that pops to my mind is what happens to the 32 bit AMD
> assembler code in durango.c? I recall seeing places where the code makes
> assumptions that the size is 32 when it turns out to be 64 on AMD64. I think
> there will be some 32/64 sanitizing done. Perhaps a good place to start
> would be to get a clean compile on AMD64. I am assuming here that FreeBSD is
> a 64 bit OS. I don't have real answers, just raising relevant questions!

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

Martin-Éric