All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Panin <pazke@orbita1.ru>
To: James Simmons <jsimmons@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Q] is framebuffer console code in 2.5.4x functional ?
Date: Fri, 22 Nov 2002 13:02:15 +0300	[thread overview]
Message-ID: <20021122100215.GA4998@pazke.ipt> (raw)
In-Reply-To: <Pine.LNX.4.33.0211210753100.9540-100000@maxwell.earthlink.net>

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

On Thu, Nov 21, 2002 at 05:24:44PM +0000, James Simmons wrote:
> 
> 
> > > > console doesn't show a single pixel.
> > > 
> > > :-( Can you post your .config file. 
> > 
> > Attached.
> 
> Hm. Strange. It should work. Can you get serial console working? 

Forgot to mention, I've seen message:
	fbcon_setup: No support for fontwidth 8
in /var/log/dmesg. 

I found this printk() in fbcon_setup(), but i can't even imagine 
why it happens.

Sorry for not providing full info, but when i wrote first letter 
my head was full of gory thoughts about visws legacy irq handling :(
I can post complete log tomorrow.
   
> > I did some changes to sgivwfb.c to make it compilable, patch attached.
> > Can you take a look at it ?
> 
> Applied your patch to the BK tree. 
Good.
  
> > > I will be posting a new fbdev patch today against 2.5.48 today. Giev it a 
> > > try.
> > 
> > Didn't see proposed fbdev patch yet :(
> 
>     Sorry about that. You are not the only one that has asked me. Also I 
> keep getting lots of error reports about drivers being broken. The problem 
> is having enough time. For example I haven't found the time to create this 
> patch. This brings up a serious point which I have been wrestling with. The 
> framebuffer layer has been broken for a long time durning the 2.5.X cycle 
> The problem is both maintainers of this subsystem, Geert and I, both have 
> very little time to work on it. For both of us we don't work on the 
> framebuffer code for a living. I work with wireless networking cards. I 
> work 8 hours a day on networking code and travel 3 hours total every day 
> to work. Including eating a sleeping and I have at most 1 to 2 hours a day 
> to work on the framebuffer stuff. Weekends I have to do other survial 
> things like buy food. So the framebuffer developement has gone at a 
> snail pace and will continue to do so unless things change. I estimate 
> about 20+ more versions before the framebuffer layer properly works. 
>     It pains me that this is happening. I really enjoy working on the 
> framebuffer and console layer. So I have been thinking about what to 
> do ? One which is the most likely is to step down from maintaintership 
> and hope someone else who can devote there full time and energy to it 
> can take over. Will someone else take over? I seriously doubt it. We all 
> have to make a living and that means working on things the linux industry 
> cares about which is only server stuff. So I except the framebuffer layer 
> will go into serious code decay. So the best situtation which I except to 
> happen is that I finish as much as I can for the fbdev layer and then 
> step down. 
>     I have tried to look for work locallly (can't really affored to move 
> cross country very few years) relating to the framebuffer layer. In my 
> search I only found one company that seemed interested in this developement, 
> strangeberry (http://www.strangeberry.com). I sent them my resume but 
> never heard from them. As for funding I serious doubt that would happen 
> since it isn't server related. The reality is for proper maintiance of any 
> subsystem you need people hired to solely work to keep it going. 
> Unfortunely the framebuffer layer is one of those few ones that doesn't 
> have that.

I understand this situation perfectly, looks like it's almost common for
developers working in "not so importatnt for servers" subsystems :(

-- 
Andrey Panin            | Embedded systems software developer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

  reply	other threads:[~2002-11-22  9:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-18 12:54 [Q] is framebuffer console code in 2.5.4x functional ? Andrey Panin
2002-11-18 18:11 ` James Simmons
2002-11-20  9:46   ` Andrey Panin
2002-11-21 17:24     ` James Simmons
2002-11-22 10:02       ` Andrey Panin [this message]
2002-11-26 23:22         ` Fbdev 2.5.49 BK fixes James Simmons
2002-11-27  8:44           ` Andrey Panin
2002-11-27 17:44             ` James Simmons
2002-11-27 11:04           ` Helge Hafting
2002-11-27 17:49             ` James Simmons
2002-11-27 17:49               ` James Simmons
2002-11-27 18:08               ` Helge Hafting
2002-11-27 23:18                 ` James Simmons
2002-11-27 23:18                   ` James Simmons
2002-11-28  8:32                   ` Joseph Fannin
2002-12-02 21:11                     ` [Linux-fbdev-devel] " James Simmons
2002-12-02 21:11                       ` James Simmons
2002-11-28  8:35                   ` Joseph Fannin
     [not found] <E18FK3w-0002YH-00@sc8-sf-list2.sourceforge.net>
2002-11-25 14:46 ` [Q] is framebuffer console code in 2.5.4x functional ? Kyrian

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=20021122100215.GA4998@pazke.ipt \
    --to=pazke@orbita1.ru \
    --cc=jsimmons@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.