RE: [Linux-fbdev-devel] API prototype doc

[<cw...@so...>]

> No PC hardware I know (*) interlaces framebuffer with some non-fb related 
> data. And if fbdev driver decides to put some special data inside - it is 
> buggy fbdev driver then.

true.  though some other application might be using it, or the card might have 
alignment information or something.  just a thought.  (agreed, no modern 
hardware would do this).
 
> No. All OSes I know - although they maybe started with some bright ideas -
> - sooner or later just gave direct access to videoram for apps - DirectX
> for Windows, DGA for XFree. 
> 
> What I see here is that useful parts of fbdev are removed in the name of 
> supporting some obsolete or nonfunctional hardware, or in the name of 
> supporting remote fbdev. Well, make mmap optional, but do not remove it.

exactly.  it may be optional, but the added benefits of it are so immense that 
any other way is just a limit to app developers.  removing that just for the 
sake of simplicity over a network connection is, imho, a junk idea.  

there is no shorter way to put it, it just isn't realistic any other way =(
some clever middle steps would be interesting and useful for day to day usage, 
but any useful interface will just hand out a pointer and a configuration 
structure.  network transparency neatly divides this topic in two, one side 
which is really neat to use over networks, but sucks all around (speedwise), 
and one that is not network transparent, but usable on the local machine.  
trying to combine these seems more and more mutually exclusive, without putting 
some responsibility on the client.

in some cases it is difficult to add support for older devices (which do not 
support linear addresing of video memory).  middle ground which supports these 
devices would be great for people who have such devices, but a way to impliment 
that functionality w/o making it harder for modern hardware is difficult.  this 
further complicates the problem.

chris

--- moc.lexiptfos@thgirwc ---