linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Reinauer <stepan@suse.de>
To: James Simmons <jsimmons@infradead.org>
Cc: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Re: atyfb in 2.5.51
Date: Sun, 15 Dec 2002 12:45:28 +0100	[thread overview]
Message-ID: <20021215124528.A5347@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.33.0212110709030.2617-100000@maxwell.earthlink.net>; from jsimmons@infradead.org on Wed, Dec 11, 2002 at 07:16:04AM -0800

* James Simmons <jsimmons@infradead.org> [021211 16:16]:
> 
> > I've always stated that the whole fbdev model was flawed, it makes
> > basic assumptions about how a video card's memory and registers are
> > accessed (ie. the programming model) and many popular cards absolutely
> > do not fit into that model.
> 
> I agree that the design of the /dev/fbX interface is not the best.
> Unfortunely we are stuck with it. Changing it would break userland apps.

One thing I was wondering: Is there a proper way to make sure that 
acceses to the framebuffer end up only on one specific virtual console?
I have an application that runs on one virtual console, but when
switching I do not want the screen to be trashed by writing just into
the framebuffer memory. My solution was to check whether the current
console is the console the application started on, but this looks a
bit bloated to me and I had some weird effects when switching to X and
back - like one frame still got painted into graphics memory while X was
already shown.
  
  Any ideas?
  Stefan

-- 
Laissez Faire Economics is the theory that if each acts like a vulture,
all will end as doves.



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

  parent reply	other threads:[~2002-12-15 11:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-10 22:31 atyfb in 2.5.51 Paul Mackerras
2002-12-10 23:11 ` Benjamin Herrenschmidt
2002-12-11  6:18   ` James Simmons
2002-12-11  8:42     ` David S. Miller
2002-12-11 15:16       ` James Simmons
2002-12-11 20:43         ` David S. Miller
2002-12-11 21:35           ` Alan Cox
2002-12-12 20:23             ` Pavel Machek
2002-12-13  8:53             ` Geert Uytterhoeven
2002-12-13 10:26               ` Alan Cox
2002-12-22 13:40                 ` Geert Uytterhoeven
2002-12-11 21:06         ` Paul Mackerras
2002-12-15 11:45         ` Stefan Reinauer [this message]
2002-12-13  8:49       ` Geert Uytterhoeven
2002-12-11 12:49   ` [Linux-fbdev-devel] " Antonino Daplas
2002-12-11 15:46     ` 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=20021215124528.A5347@suse.de \
    --to=stepan@suse.de \
    --cc=jsimmons@infradead.org \
    --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).