Re: [Xpert]Re: [Linux-fbdev-devel] On i810/i815 fb issues

[Anda M. <a_m...@ho...>]

hi tea age,

License is GNU.

Muni Reddy Anda

>From: tea age <th...@vi...>
>To: Jeff Hartmann <jha...@va...>,        "Sottek, Matthew J" 
><mat...@in...>,        Anda MuniReddy 
><a_m...@ho...>
>CC: Xp...@xf...,        "'Lin...@li...'" 
><Lin...@li...>
>Subject: Re: [Xpert]Re: [Linux-fbdev-devel] On i810/i815 fb issues
>Date: Wed, 11 Jul 2001 18:42:56 +0200
>
>Concerning the licence I agree from my point of view with GNU. But the 
>author
>of i810fb is Anda MuniReddy.
>
>Today I uploaded version 1.07 of i810fb. It contains the i810e patch from
>Sottek, Matthew J, (sorry, I rewrote it - it was buggy) and some minor
>changes regarding the hint from Geert Uytterhoeven (not all ID's are define
>in pci_ids.h!).
>
>Pleas check the following link:
>
>http://www.visuelle-maschinen.de/ctfb/i810/
>
>Concerning the issue discussion I like the idea of Jeff Hartmann. I still
>think Sottek, Matthew J's solution is just a workaround. Also I prefer high
>resolutions on the console.
>
>Please, who knows how to put the i180fb source into a public CVS, or better
>into the kernel sources, if the licence question is clear.
>
>Here is some of the discussion again, because not all mails went also to 
>the
>Linux-fbdev-devel list:
>-----------------------------------------------------------------------------------------------------------------
>Jeff Hartmann wrote:
>
> >
> > The only way to properly solve that is to have some sort of mechanism in
> > the Xserver which tells the fbdriver to release agpgart and unbind its
> > memory during Xserver initialization.  Then at VT switch and Xserver
> > close we can call fbdev telling it that it can use the memory again.  If
> > someone gives me an interface to do this, I will add it to the Xserver
> > code.  I know nothing about the fbdev API, so if it already has this
> > sort of thing, then enlighten me.
> >
> > I will not make the agpgart driver into a general allocation API, it
> > just adds cruft to the kernel, and wastes memory which can not be
> > swapped out.  Its the wrong solution.  Any generalized allocator belongs
> > in user space, not in the kernel.
> >
>
>Sottek, Matthew J wrote:
>
> >>> I've read over some of the discussion of the i810/i815
> >>> framebuffer discussion, and given the code a cursory look. I
> >>> currently work for an embedded development group at Intel
> >>> and I've been doing X work for quite a while on these
> >>> chipsets, so I thought I would jump into the conversation.
> >>>
> >>> First, looking at the code it seems the main reason this
> >>> fb driver hasn't received more support is due to the
> >>> competition between X and the fb driver for the gart
> >>> resources. Why don't we just make a version of this driver
> >>> that makes use of stolen memory only (1MB) and does not use
> >>> the ringbuffer. This would give us all modes under 1MB in
> >>> size (10x7 at 8bit, 8x6 at 16bit) which is the way the
> >>> chipset is supported in all non AGP environments. (OS2, Dos
> >>> etc.) This would remove all competition between X and the
> >>> fb driver for resources...makes everyone's life easier.
> >>>
>
>Jeff Hartmann wrote:
>
> >> I think this is also a more then satisfactory solution.
> >> Anyone want to
> >> implement it?
>
>Sottek, Matthew J wrote:
>
> > I'll look at it as soon as I get a spare second. I think the
> > current driver is probably pretty close already.
> >
> > Jeff, do you remember what the current status of the Stolen
> > memory is? Do you map it into the Gtt or just leave it alone?
>
>
>Jeff Hartmann wrote:
>
> > The I810/I815 drivers don't touch stolen memory at this time.
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.