Hi all,
I'm trying to resurrect SGI Visws support in 2.5 kernels and have two
problems: frambuffer console doesn't show anything and legacy device
interrupts not working. It's difficult to debug second problem without
console :(
Framebuffer driver sets needed video mode (checked with monitor's ods)
and starts display dma engine successfuly (i can even draw lines on the
screen using memset()'s). But the beautifull linux logo doesn't apear and
console doesn't show a single pixel.
Simple(silly) questions:
- is 2.5.4x framebuffer console code really functional ?
- if yes, where to start debugging this issue ?
Best regards.
--
Andrey Panin | Embedded systems software developer
[email protected] | PGP key: wwwkeys.eu.pgp.net
> Framebuffer driver sets needed video mode (checked with monitor's ods)
> and starts display dma engine successfuly (i can even draw lines on the
> screen using memset()'s).
So the driver is functional. I assume also a cat /dev/urandom > /dev/fb
works as well.
> But the beautifull linux logo doesn't apear and
Fixed in the fbdev BK tree.
> console doesn't show a single pixel.
:-( Can you post your .config file.
> Simple(silly) questions:
> - is 2.5.4x framebuffer console code really functional ?
If the driver has been ported to the new api then yes it works. I did port
the SGIVW driver some time ago bit didn't have the hardware to test it.
I will be posting a new fbdev patch today against 2.5.48 today. Giev it a
try.
On Mon, Nov 18, 2002 at 06:11:34PM +0000, James Simmons wrote:
>
> > Framebuffer driver sets needed video mode (checked with monitor's osd)
> > and starts display dma engine successfuly (i can even draw lines on the
> > screen using memset()'s).
>
> So the driver is functional. I assume also a cat /dev/urandom > /dev/fb
> works as well.
Yes, it fills screen with fancy patterns.
>
> > But the beautifull linux logo doesn't apear and
>
> Fixed in the fbdev BK tree.
>
> > console doesn't show a single pixel.
>
> :-( Can you post your .config file.
Attached.
>
> > Simple(silly) questions:
> > - is 2.5.4x framebuffer console code really functional ?
>
> If the driver has been ported to the new api then yes it works. I did port
> the SGIVW driver some time ago bit didn't have the hardware to test it.
I did some changes to sgivwfb.c to make it compilable, patch attached.
Can you take a look at it ?
> 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 :(
--
Andrey Panin | Embedded systems software developer
[email protected] | PGP key: wwwkeys.eu.pgp.net
> > > 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?
> 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.
> > 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.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
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
[email protected] | PGP key: wwwkeys.eu.pgp.net
> > 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.
Perfect. I found the problem and I'm about to commit to BK. I posted the
latest patch against 2.5.49 at
http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> I understand this situation perfectly, looks like it's almost common for
> developers working in "not so importatnt for servers" subsystems :(
:-( Some day that attitude will change.
P.S
Several drivers have been ported but not all. NVIDIA is still broken
but I will fix it tonight.
On Tue, Nov 26, 2002 at 11:22:07PM +0000, James Simmons wrote:
>
> > > 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.
>
> Perfect. I found the problem and I'm about to commit to BK. I posted the
> latest patch against 2.5.49 at
>
>
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
>
I see some harmless crap slipped into the patch again :))
Add these file into /home/jsimmons/dontdiff:
vmlinux.lds.s
gen_init_cpio
initramfs_data.cpio.gz
I'll test the patch this eveninig.
> > I understand this situation perfectly, looks like it's almost common for
> > developers working in "not so importatnt for servers" subsystems :(
>
> :-( Some day that attitude will change.
>
Lets hope so.
> P.S
>
> Several drivers have been ported but not all. NVIDIA is still broken
> but I will fix it tonight.
I can test the fix on my riva128.
--
Andrey Panin | Embedded systems software developer
[email protected] | PGP key: wwwkeys.eu.pgp.net
James Simmons wrote:
> Perfect. I found the problem and I'm about to commit to BK. I posted the
> latest patch against 2.5.49 at
>
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
I tried this patch, but it crashed during boot.
I have a
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
1X/2X (rev 5c)
and use this in lilo.conf:
image=/boot/2.5.49fb
label=2.5.49fb
append="video=atyfb:1280x1024-16@85"
This got me a 160x64 framebuffer with yellow text on
blue background. Nice, but only got about 10 lines before
the kernel hung. The disk light got stuck on and there were
no response to things like sysrq.
The few lines displayed was about the fb, drm, and finally
the 3com network adapter. Then nothing more.
2.5.49 without this patch works. I use devfs & preempt,
the machine is UP and I use gcc-2.95.4 for compiling.
Helge Hafting
> > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> >
> I see some harmless crap slipped into the patch again :))
>
> Add these file into /home/jsimmons/dontdiff:
> vmlinux.lds.s
> gen_init_cpio
> initramfs_data.cpio.gz
Oops. Added.
> I'll test the patch this eveninig.
How did it work for you?
> Lets hope so.
It will :-)
> > Several drivers have been ported but not all. NVIDIA is still broken
> > but I will fix it tonight.
>
> I can test the fix on my riva128.
Still broken. I didn't get a chance to port it last night :-(
> I tried this patch, but it crashed during boot.
Any oops info?
> I have a
> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
> 1X/2X (rev 5c)
>
> and use this in lilo.conf:
> image=/boot/2.5.49fb
> label=2.5.49fb
> append="video=atyfb:1280x1024-16@85"
Hm. Are you using a PPC or ix86 box? I will test this tonight.
> This got me a 160x64 framebuffer with yellow text on
> blue background. Nice, but only got about 10 lines before
> the kernel hung. The disk light got stuck on and there were
> no response to things like sysrq.
> The few lines displayed was about the fb, drm, and finally
> the 3com network adapter. Then nothing more.
Sounds like panning flipped put.
> 2.5.49 without this patch works. I use devfs & preempt,
> the machine is UP and I use gcc-2.95.4 for compiling.
James Simmons wrote:
>
> > I tried this patch, but it crashed during boot.
>
> Any oops info?
No. The machine froze solid. No oops, no sysrq.
The reset button worked.
>
> > I have a
> > 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
> > 1X/2X (rev 5c)
> >
> > and use this in lilo.conf:
> > image=/boot/2.5.49fb
> > label=2.5.49fb
> > append="video=atyfb:1280x1024-16@85"
>
> Hm. Are you using a PPC or ix86 box? I will test this tonight.
i386. Specifically, a pentium II, compiled for pentium II.
> > This got me a 160x64 framebuffer with yellow text on
> > blue background. Nice, but only got about 10 lines before
> > the kernel hung. The disk light got stuck on and there were
> > no response to things like sysrq.
> > The few lines displayed was about the fb, drm, and finally
> > the 3com network adapter. Then nothing more.
>
> Sounds like panning flipped put.
>
Perhaps. It didn't look like it ended at the bottom of the
screen, but then it might have been panning at the wrong moment.
> > 2.5.49 without this patch works. I use devfs & preempt,
> > the machine is UP and I use gcc-2.95.4 for compiling.
Helge Hafting
> No. The machine froze solid. No oops, no sysrq.
> The reset button worked.
VESA fbdev did this to me. I have no trouble with neofb. Strange???
I will track it down tonight.
> > Hm. Are you using a PPC or ix86 box? I will test this tonight.
> i386. Specifically, a pentium II, compiled for pentium II.
Hm. I have that same card and a similar machine.
> Perhaps. It didn't look like it ended at the bottom of the
> screen, but then it might have been panning at the wrong moment.
I have a MDA monitor and card. So I can setup mdacon and turn on
debugging in fbcon and trace threw it.
> > > 2.5.49 without this patch works. I use devfs & preempt,
> > > the machine is UP and I use gcc-2.95.4 for compiling.
>
> Helge Hafting
>
On Wed, Nov 27, 2002 at 11:18:22PM +0000, James Simmons wrote:
>
> > No. The machine froze solid. No oops, no sysrq.
> > The reset button worked.
>
> VESA fbdev did this to me. I have no trouble with neofb. Strange???
> I will track it down tonight.
aty128fb works for me here with:
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS
Thank you!
There are a few glitches, but I've been unable to pin down
anything serious as the fbdev patch's fault. I'm still playing with
things (like Antonio Daplas' patches). I'll give a more full report
later.
FWIW, the fbdev patch applies with a few minor offsets to 2.5.50
except for the attached patch, which I extracted from bk. So if you
apply this patch in *reverse* to a clean 2.5.50 tree, the fbdev patch
should then apply okay (patch complained about a reversed hunk in
fbcon.c, but it should be harmless, I think.)
--
Joseph Fannin
[email protected]
"Anyone who quotes me in their sig is an idiot." -- Rusty Russell.
Whoops, I forgot to attach the patch.
--
Joseph Fannin
[email protected]
"For future reference - don't anybody else try to send patches as vi
scripts, please. Yes, it's manly, but let's face it, so is bungee-jumping
with the cord tied to your testicles." -- Linus Torvalds
> aty128fb works for me here with:
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS
>
> Thank you!
Great. I made more inprovements with my latest patch. Give it a try.
> There are a few glitches, but I've been unable to pin down
> anything serious as the fbdev patch's fault. I'm still playing with
> things (like Antonio Daplas' patches). I'll give a more full report
> later.
I just intergrated a bunch of his work. The subsystem is starting to
really take shape.
> FWIW, the fbdev patch applies with a few minor offsets to 2.5.50
> except for the attached patch, which I extracted from bk. So if you
> apply this patch in *reverse* to a clean 2.5.50 tree, the fbdev patch
> should then apply okay (patch complained about a reversed hunk in
> fbcon.c, but it should be harmless, I think.)
I noticed. My new patch fixes that.