linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jorge Luis Zapata Muga" <jorgeluis.zapata@gmail.com>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: overlay support
Date: Tue, 12 Sep 2006 15:55:50 +0200	[thread overview]
Message-ID: <eb77d7060609120655l4df86d3cy8b3fc802b51ab48f@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0609121531120.27586@pademelon.sonytel.be>

On 9/12/06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 12 Sep 2006, Jorge Luis Zapata Muga wrote:
> > i coded a while ago a framebuffer driver for an old video card i have
> > (a SiS 6326, just for learning) but now i would like to support its
> > video extension (overlay support, this card can also capture from an
> > external input, but my version doesnt has the input connectors). ive
> > read on the mailing list and on external projects about how to support
> > overlay on the fb device, but i still dont find a good way to do it,
> > maybe you can help me out.
> >
> > one way is to add another fb device, but it is good only if the device
> > has a different memory space assigned to it, if you only have a chunk
> > of memory for both layers (the overlay and the normal rgb which is
> > this case) there should be a way to resize the memory space assigned
> > to each of them. i dont like this way because is adding a policy on
> > kernel space to manage the memory. am i correct with this assumptions?
>
> If there are just 2 users of the memory (i.e. 2 frame buffers), you can avoid
> adding a policy to the kernel by making the split dynamic.
> Let the first frame buffer `allocate' (based on xres_virtual, yres_virtual, and
> bits_per_pixel) from the bottom of memory, and the second frame buffer from the
> top of memory. Each frame buffer can shrink whatever it wants, or grow, as long
> as it doesn't conflict with the memory size of the other.

indeed, this is another solution, but what happens if the requested
size of the framebuffer will overlap the other framebuffer memory
space? wouldnt be better to manage the framebuffer memory from
userspace and use the v4l interface for the overlay?

>
> Gr{oetje,eeting}s,
>
>                                                 Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                                             -- Linus Torvalds
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

  reply	other threads:[~2006-09-12 13:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-12 13:27 overlay support Jorge Luis Zapata Muga
2006-09-12 13:34 ` Geert Uytterhoeven
2006-09-12 13:55   ` Jorge Luis Zapata Muga [this message]
2006-09-12 14:02     ` Geert Uytterhoeven
2006-09-12 14:49   ` Raphael Assenat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eb77d7060609120655l4df86d3cy8b3fc802b51ab48f@mail.gmail.com \
    --to=jorgeluis.zapata@gmail.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).