Re: [Linux-fbdev-devel] Feature Freeze?

[Antonino D. <ad...@po...>]

On Thu, 2003-03-06 at 15:03, Carlo E. Prelz wrote:
> I see there currently is much activity on the list. I would like to
> present the point of view of a heavy framebuffer user: I write
> multimedia code for artists, and I generally generate video via the
> framebuffer layer, and trusted old matrox cards (from the Millennium
> II to the G550). The general process is:
> 
> - open the framebuffer unit
> - FBIOGET_VSCREENINFO
> - change the appropriate values in fb_var_screeninfo
> - FBIOPUT_VSCREENINFO
> - mmap
> - happily write pixels to the memory area

All of the above should still work with the 2.5.  Care was taken to
prevent user application breakage. 

> 
> This, multiplied for all the video heads that I use within the same
> program (up to 5 per PC, up to now, *including* the console screen -
> in this case I control the machine from a network connection).
> 
> I am especially in need to change the BPP value (often using 16BPP
> mode), and in a couple of occasions (the latest 2 weeks ago) I had to
> feed the output of old G200's to large monitors who are only capable
> of TV resolution. This means setting the framebuffer to 768x576 (PAL)
> and *interlaced*. The framebuffer model that still survives in 2.4
> allows me to obtain all this. 

You can still do it for the 2.5, except that the matroxfb is not ported
yet.

> 
> I am not much familiar with all the terminology that is used for the
> new layer. Actually, this framebuffer revolution is what keeps me from
> enjoying (!) the kernel bleeding edge, as I used to do since almost 10
> years ago. 
> 
> Can I poll the list's huge knowledge to find out if and how I can
> obtain the same result with the new layer?
> 

You still can, in general, use the framebuffer as you would use it in
the 2.2.- 2.4 versions.  The main difference is console window
resizing.  As you probably know, in 2.4, resizing was done through the
fbdev layer and then the information is transmitted to the console.  In
2.5, it is currently the opposite way, from the console to fbdev.  The
only application that I know of that is able to do that is stty, which
in its current incarnation has very limited capability.  However, you
can still use fbset to change other parameters (color depth,
acceleration, etc), anything that will not affect the window size.

So the debate really is, should fbset support for console resizing be
reimplemented? Or should console resizing through stty be made more
powerful, at least to create a video mode that is usable, and then just
use fbset later on to fine tune the new video mode? The former is easy,
the latter is saner but more difficult to code.

The matroxfb on the other hand, is the most complicated fb driver
around, so it is perfectly understandable that rewriting the driver for
the 2.5 will take some time.  Temporarily, you can use Petr's patches
until it is ported over to 2.5.  

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz


The new layer may not produce something tangible in terms of user
experience (except perhaps for a faster console), but it should pave the
way for better things in the future.

Tony