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

[tea a. <th...@vi...>]

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.