linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Zielinski <grim@undead.cc>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: fbdev upstream
Date: Wed, 24 Dec 2003 15:40:35 -0500	[thread overview]
Message-ID: <3FE9F9C3.20605@undead.cc> (raw)
In-Reply-To: <1072254049.739.61.camel@gaston>

Benjamin Herrenschmidt wrote:

>Good catch. I merged that in my tree (I use a different version of
>the client notification mecanism though, I don't like much the
>version that James pushed).
>  
>

Yeah.  That has caused a lot of headaches for me as well.  The fact that 
a vt row/col change triggers a fb resolution change which calls the vt  
resize routine again is just begging for an infinite loop.  Just one 
calculation mistake of just one pixel in one of  a dozen equations will 
trigger this loop.  That's what the above bug does as well.  The other 
major problem with it is that it only changes var.xres and var.yres and 
none of the other timings so the monitor won't sync anymore.

One item on my to do list is to make a separate fb_var_screeninfo for 
each vt so that we know what mode to switch back to when we switch vt's 
or come back from X or a fb graphical program.

>Since James vanished, I intend to take the most obvious bug fixes
>and driver updates from his tree into mine, test them, and then
>submit them one by one to Andrew Morton for 2.6.x inclusion.
>  
>

I'll keep posting any bugs I discover.  Maybe you can post a message 
here whenever you've got a new version to test so that the other testers 
on the list and myself can try it out.  I'm running fbcon on the radeon 
machine but I went back to VGA for the nvidia machines as the hardware 
cursor bug makes it unusable for any kind of text editing work.  I'll 
switch back on those machines when that bug is squashed.

>I do not intend, at least in a first step, to take the sysfs
>stuffs as the structure lifetime changes are fairly invasive and
>happened to break a bunch of things. Once all the rest is merged
>up, we can look into it again in more detail, isolated from the
>other bunch of changes.
>  
>

Agreed.  Let's get what we have rock solid before we try to break it 
again.  :)

John




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

  parent reply	other threads:[~2003-12-24 20:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-10  7:03 Changing modes with fbset John Zielinski
2003-12-14  1:14 ` John Zielinski
2003-12-24  8:20   ` fbdev upstream (was: Changing modes with fbset) Benjamin Herrenschmidt
2003-12-24  8:26     ` Carlo E. Prelz
2003-12-24 20:40     ` John Zielinski [this message]
2003-12-24 22:42       ` fbdev upstream Benjamin Herrenschmidt
2003-12-25  0:45         ` John Zielinski
2003-12-25  0:57           ` Benjamin Herrenschmidt
2003-12-25  1:53             ` John Zielinski
2003-12-25 10:46               ` Benjamin Herrenschmidt
2003-12-25 16:53                 ` John Zielinski
2004-01-05 14:41         ` Geert Uytterhoeven
2004-01-06  0:51         ` James Simmons
2004-01-06  1:03           ` Benjamin Herrenschmidt
2004-01-06 10:08             ` Geert Uytterhoeven
2004-01-09 20:05               ` James Simmons
2004-01-06  0:47       ` James Simmons
2004-01-08  2:17         ` John Zielinski
2004-01-08 20:37           ` James Simmons
2004-01-06  0:06   ` Changing modes with fbset James Simmons
2004-01-06  0:28     ` Otto Solares
2004-01-06  0:35       ` Benjamin Herrenschmidt
2004-01-06  1:08         ` Otto Solares
2004-01-06  1:09           ` Benjamin Herrenschmidt
2004-01-06  1:44             ` Otto Solares
2004-01-06  1:44               ` Benjamin Herrenschmidt
2004-01-06  2:06                 ` Otto Solares
     [not found]                   ` <1073354986.761.208.camel@gaston>
2004-01-06  2:24                     ` Otto Solares
2004-01-06 11:38         ` Michel Dänzer
2004-01-06 15:23           ` Geert Uytterhoeven
2004-01-09  0:03       ` James Simmons
2004-01-09  1:31         ` Otto Solares
2004-01-06  0:33     ` Benjamin Herrenschmidt
2004-01-06  0:38       ` James Simmons
2004-01-08  2:06     ` John Zielinski
2004-01-08 20:38       ` 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=3FE9F9C3.20605@undead.cc \
    --to=grim@undead.cc \
    --cc=benh@kernel.crashing.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).