In message: <[EMAIL PROTECTED]>
Christian Zander <[EMAIL PROTECTED]> writes:
: This summary makes an attempt to describe the kernel interfaces needed by
: the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with
: the Linux/Solaris graphics drivers, and/or required to make
In message: <[EMAIL PROTECTED]>
"Kip Macy" <[EMAIL PROTECTED]> writes:
: IIRC lack of per instance cdevs also limits Freebsd to one vmware instance.
Can you describe the proper semantics here? A cdev is a cdev, and
when we do things like dup we just copy the reference to that cdev.
Th
That's their commercial decision - as a result, if you
their cards, you may end up with a particularly expensive
paperweight the day they decide you need to buy a new card
for your new version of freebsd which has different
internals; or someone finds bugs in their drivers that
they wont fix.
Th
Ian Dowse wrote:
In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes:
But there is one problem, that has been overlooked, and that is High speed
isochronous transfers, which are not supported by the existing USB system. I
don't think that the EHCI specification was designed for scatt
On Sun, 2 Jul 2006, Michal Mertl wrote:
And - again - it will probably take a couple of very skilled
programmers' years' time to write good driver from scratch.
It took someone far less than that
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_nfe.c
http://www.openbsd.o
Miguel Mendez wrote:
> On Thu, 29 Jun 2006 13:12:31 +0200
> Christian Zander <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I just saw an article on OSNews about this, seems I missed it.
>
> > NVIDIA has been looking at ways to improve its graphics driver for the
> > FreeBSD i386 platform, as well as in
In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes:
>Ok. So the solution to my problem is to use scatter and gather. I will see
>about updating my USB system to do it like that.
>
>But there is one thing I do not understand yet. When you load a page that
>physically resides above 4GB, bec
On Sunday 02 July 2006 17:20, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Ian Dowse writes:
> >The trick is that if the 0x6000 bytes are contiguous in virtual
> >memory then they never span more than 6 pages so one iTD is enough.
>
> Sorry, I meant of course 6 page boundaries, which means no
On Sun, Jul 02, 2006 at 09:00:07AM -0700, Randall Hyde wrote:
>
> - Original Message -
> From: "Peter Jeremy" <[EMAIL PROTECTED]>
> To: "Randall Hyde" <[EMAIL PROTECTED]>
> Sent: Saturday, July 01, 2006 11:10 PM
> Subject: Re: FLEX, was Re: Return value of malloc(0)
>
> The following com
- Original Message -
From: "Peter Jeremy" <[EMAIL PROTECTED]>
To: "Randall Hyde" <[EMAIL PROTECTED]>
Sent: Saturday, July 01, 2006 11:10 PM
Subject: Re: FLEX, was Re: Return value of malloc(0)
The following compiles without error:
%{
typedef int YYSTYPE;
typedef int YYLTYPE;
/*
** Allo
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>The trick is that if the 0x6000 bytes are contiguous in virtual
>memory then they never span more than 6 pages so one iTD is enough.
Sorry, I meant of course 6 page boundaries, which means no more
than 7 pages. This is why the 7 physical address s
On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote:
> >I went wandering through the C Working Group archives for the heck of
> >it, and apparently a lot of people were confused over this, thinking
> >either as you did or that "unique" meant it would a value unique to
> >the usage of malloc(0)
On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote:
> Pat Lashley <[EMAIL PROTECTED]> writes:
>
> > BUT, that said, the safest and most portable coding practice would be:
> >
> >// The C standard does not require malloc(0) to return NULL;
> >// but whatever it returns MUS
In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes:
>On Sunday 02 July 2006 14:05, Ian Dowse wrote:
>> This data structure requires the associated data buffer to be
>> contiguous (relative to virtual memory), but allows the physical
>> memory pages to be non-contiguous. Seven page poi
On Sunday 02 July 2006 14:05, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Hans Petter Selasky
writes:
> >But there is one problem, that has been overlooked, and that is High speed
> >isochronous transfers, which are not supported by the existing USB system.
> > I don't think that the EHCI s
In message <[EMAIL PROTECTED]>, Hans Petter Selasky writes:
>But there is one problem, that has been overlooked, and that is High speed
>isochronous transfers, which are not supported by the existing USB system. I
>don't think that the EHCI specification was designed for scatter and gather,
>whe
On Thu, 29 Jun 2006 13:12:31 +0200
Christian Zander <[EMAIL PROTECTED]> wrote:
Hi,
I just saw an article on OSNews about this, seems I missed it.
> NVIDIA has been looking at ways to improve its graphics driver for the
> FreeBSD i386 platform, as well as investigating the possibility of adding
>
On Saturday 01 July 2006 21:44, David Malone wrote:
> On Sat, Jul 01, 2006 at 10:44:54AM +0200, Hans Petter Selasky wrote:
> > > The latest concensus seems to be that the USB system should make use of
> > > the scatter-gather facilities in the hardware to avoid the need to
> > > allocate large cont
18 matches
Mail list logo
