Re: [Linux-fbdev-devel] vga256fb

[antirez <an...@in...>]

On Mon, May 14, 2001 at 03:45:51PM +0000, Petr Vandrovec wrote:
> ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
>   vga.gz => vga16fb patch;
>       fbset -depth 8 -nonstd 0 => up to 320x200/256 colors, linear
>       fbset -depth 8 -nonstd 1 => up to 360x480/256 colors, planes
>       fbset -depth 4 -nonstd 0 => up to 720x480/16 colors, planes
>       fbset -depth 4 -nonstd 1 => up to 720x182/16 (or 320x480/16), linear
>       (due to some VGA incompatibilites last mode works either on
>        ATI or on Matrox... you have to change code to switch behavior,
>        ATI needs 'xoffset--' in vga16fb_pan_var, while Matrox does not,
>        or vice versa...)
>   fbset-through-tty.gz => patch to get 'fbset -fb /dev/tty* ...' to work
>             (not tested with other fbdev than matroxfb)
>   tabstop.gz => patch for fatal kernel memory corruption and TAB not working
>             beyond column 160

I downloaded the patch, it seems your 256 color driver works
in 360x480 only to provide a graphic console, but not with
other userspace software that mmap() the video memory.
Am I right?

> > I haven't a clue about how to implement this without something
> > like a virtual framebuffer. So my idea was: until I have to map
> > the framebuffer in the PC ram, it's better to emulate even the
> > PACKED_PIXEL type to increase userspace software compatibility.
> 
> fbtv uses busmastering transfers when fbdev reports reasonable values.
> I have no idea what it checks, but on all my packed_pixels hardware
> it does busmastering, even on 320x200 VGA.

I read the source code of fbtv, and it seems to perform a quite
usual memory mapped I/O. Unfortunatelly I can't test it, I
lacks a TV-card...

> This buffer is not physically continuous and maybe that bttv driver
> does not expect videomemory to be nonlinear...

Again, It *seems* to mmap the fbdev, so every mmaped page contains a
proper entry. I may assume that fbtv will work just as all the
other applications. I tryed the 360x480 mode with GGI, SDL and so
on, that also works doing memory mapped I/O (of course).

> to remap videoram pages and change hardware state. On other side, fbtv
> has switch to do busmastering to main memory and then memcpy to videoram.
> But it is very slow.

No I can't use the no-page trick to remap the videoram pages and change
the hardware state, unfortunatelly: it seems not possible.
I used it just to mmap the vmalloc()ed "virtual"-fb memory to userspace. There
is a different kernel timer that updates the video memory and
switches the registers to write to the proper video plane.

BTW, I'm starting to think that my version isn't so advanced,
it is the one shipped with xawtv-3.46. My version of fbtv does just
memory mapped I/O that's supported by vga256fb.

Maybe I'll buy a TV-card: now that Mr. Berlusconi is the italian's
leader It's better to check what he is doing :(

thanks for the patch,
antirez

-- 
Salvatore Sanfilippo <an...@in...>
http://www.kyuzz.org/antirez
finger an...@te... for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF