Re: ioremap problem on highmem

[Jon Smirl <jonsmirl@yahoo.com>]

--- James Simmons <jsimmons@infradead.org> wrote:
> 
> > I just think the whole concept
> > of mapping the framebuffer in to kernel space needs to be eliminated. 
> 
> I agree. That is why I moved the api over to a accelerated api. The idea 
> was to get people to write accelerated drivers. Drivers using acceleration 
> don't need to map the framebuffer in kernel space.
> 
> > 1) System boots using VGA mode or whatever BIOS provides.
> 
> On x86 platforms this fine but for the rest of the world this is not.
> 
I'm looking at this as more of a choice. If you have DRI supported hardware
pick the DRI scheme, otherwise continue with existing framebuffer.  DRI only
supports about 10% of existing graphics cards, but these 10% are used in 90% of
current general purpose systems. 

DRI doesn't exist on most embedded device, PDA's, etc. so stick with the
current framebuffer. The ioremap is only causing problems on systems with over
1GB memory so this eliminates most smaller devices.

My main motivation for this is to have a single driver controlling the graphics
hardware on DRI supported systems. This will eliminate the problem with saving
hardware state between VT's. 

Another issue I am having trouble with is having mode setting/EDID code in a
device driver. That is a lot of seldom used code sitting in a device driver.
I'd rather see it in a user space library. Some hardware (Rage128) can only
read EDID info from user space becuase of real mode INT10 problems.


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php