linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Michael Kaufmann <kaufmann@sohard.de>
Cc: Linux-fbdev-devel@lists.sourceforge.net
Subject: Re: Mirrored Display?
Date: 29 Dec 2002 23:59:38 +0800	[thread overview]
Message-ID: <1041175846.1210.10.camel@localhost.localdomain> (raw)
In-Reply-To: <200212231204.39625.kaufmann@sohard.de>

On Mon, 2002-12-23 at 21:04, Michael Kaufmann wrote:
> Antonino has also answered to my question. And he said that there is nothing 
> i can do, because user apps will directly acces the framebuffer via read/write 
> or nmap. I can only patch the console and the show _logo to write the data 
> mirrored to the videobuffer (a lot of work).
> So my user apps (like nanoX or directfb/GTK+) must know about the mirrored 
> display and should write the picturedata mirrored in the framebuffer. 
> 
> I'm know a litte bit amazed about a rotation feature in next versions. Does 
> this mean, that the buffer where user apps (or also the console) are writing 
> there picture data is not directly the videobuffer anymore? Or how does this 
> rotation feature works?
I think the rotation hooks are console specific.  

> 
> I think it would be a good feature to have 'something' between the framebuffer 
> and the physical videobuffer to be able to manipulate the picture data (like 
That is the job of fb libraries.  You can use X (which already has
support for rotation, so mirroring should be easy to add), or modify
DirectFB.

> rotation, mirroring, etc.). But i don't know how this peace of software 
> should detect, changed data in the 'framebuffer' to e.g. mirror in the 
> videobuffer? Writing the whole buffers from time to time whould be a very
> bad solution (performance).
You can probably implement something similar to a shadow framebuffer. 
You expose this instead of the actual framebuffer (fix->smem_start, and
info->screen_base), then just refresh the contents of the actual
framebuffer, say during vsync.  You will have to set up a vsync
irq_handler or something similar.

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2002-12-29 16:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-13 18:33 Mirrored Display? Michael Kaufmann
2002-12-15  0:29 ` Antonino Daplas
2002-12-15 17:03   ` Michael Kaufmann
2002-12-15 20:57     ` Antonino Daplas
2002-12-16  0:40       ` Michel Dänzer
2002-12-20 19:49 ` James Simmons
2002-12-23 13:04   ` Michael Kaufmann
2002-12-29 15:59     ` Antonino Daplas [this message]
2003-01-07 21:18       ` James Simmons

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=1041175846.1210.10.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=Linux-fbdev-devel@lists.sourceforge.net \
    --cc=kaufmann@sohard.de \
    /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).