Hi folks!!
On to the massive fbdev cleanup. The second patch requires the first
patch. The first patch is the currcon one that I posted earlier. Every
driver makes use of the currcon field in struct fb_info. The second patch
makes every driver start to use fbgen. The first function that is mass
reproduced in every driver do_install_cmap is removed to one spot. I like
people to test this before it is sent off to Dave Jones. The patches are
big so here is the link to them:
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
http://www.transvirtual.com/~jsimmons/fbcurrcon.diff
http://www.transvirtual.com/~jsimmons/doinstallcmap.diff
Have fun. I have tested on my local machine. Works like a charm.
On Tue, Jan 15, 2002 at 05:07:00PM -0800, James Simmons wrote:
>
> Hi folks!!
>
> On to the massive fbdev cleanup. The second patch requires the first
> patch. The first patch is the currcon one that I posted earlier. Every
Mmm, what is the current status on all this.
How does the new fbdev api compare with ruby, is it the same thing or not, and
how does the ruby tree compare with the -dj one ?
And what is the current status of fbdev in 2.5.x ? 2.5.1 + ruby hang my box
early in the boot process, but that is probably because pm3fb is not working
yet for ruby. Does matroxfb work ? i have an older pci matrox board that i
could install to test and do some pm3fb work if needed (and if i get the time
for it :(((0
Friendly,
Sven Luther
> > On to the massive fbdev cleanup. The second patch requires the first
> > patch. The first patch is the currcon one that I posted earlier. Every
>
> Mmm, what is the current status on all this.
Right now the cleanup of the massive code duplication for the color map
handling is happening. I have fbgen.c compiled in by default for every
driver and I'm gradually moving everything over to it.
> How does the new fbdev api compare with ruby, is it the same thing or not,
It pretty much is the same thing. The only difference will be hooks for
fb_read and fb_write. Some framebuffers like the i810 or the epson 1385
are not the run of the mill linear framebuffers. So they need special
hooks. Also the addition of EDID/DDC and othe rrelated protocols. The
third difference will be something that has been discussed in public with
Scott from intel. At present most fbdev drivers reset the accel engine
even when you do something like increasing the refresh rate. This is not
needed. Most sane hardware has the timings seperate from the accel engine.
Now change the color depth or resolution does effect it. So that will be
cleared up.
> and how does the ruby tree compare with the -dj one ?
I gradually placing the ruby stuff into the -dj tree. This way it gets
more testing. Plus I can see what is really a bug in ruby. For example
their is a nasty bug in the new console locking. So it has been removed
from the dj tree. I need to break it up more and slowly put it into place.
This way I can see what the problem is.
> And what is the current status of fbdev in 2.5.x ? 2.5.1 + ruby hang my box
> early in the boot process, but that is probably because pm3fb is not working
> yet for ruby. Does matroxfb work ? i have an older pci matrox board that i
> could install to test and do some pm3fb work if needed (and if i get the time
> for it :(((0
Only a hand full of drivers have truly been converted over in the console
CVS. The hanging is most likely due to the new console lock. I have
decided that the ruby tree will be used for code deposting and the DJ tree
will be the real testing ground.
On Fri, Jan 18, 2002 at 09:20:47AM -0800, James Simmons wrote:
>
> > > On to the massive fbdev cleanup. The second patch requires the first
> > > patch. The first patch is the currcon one that I posted earlier. Every
> >
> > Mmm, what is the current status on all this.
>
> Right now the cleanup of the massive code duplication for the color map
> handling is happening. I have fbgen.c compiled in by default for every
> driver and I'm gradually moving everything over to it.
Ok, ...
> > How does the new fbdev api compare with ruby, is it the same thing or not,
>
> It pretty much is the same thing. The only difference will be hooks for
> fb_read and fb_write. Some framebuffers like the i810 or the epson 1385
> are not the run of the mill linear framebuffers. So they need special
> hooks. Also the addition of EDID/DDC and othe rrelated protocols. The
> third difference will be something that has been discussed in public with
> Scott from intel. At present most fbdev drivers reset the accel engine
> even when you do something like increasing the refresh rate. This is not
> needed. Most sane hardware has the timings seperate from the accel engine.
> Now change the color depth or resolution does effect it. So that will be
> cleared up.
Ok, ...
> > and how does the ruby tree compare with the -dj one ?
>
> I gradually placing the ruby stuff into the -dj tree. This way it gets
> more testing. Plus I can see what is really a bug in ruby. For example
> their is a nasty bug in the new console locking. So it has been removed
> from the dj tree. I need to break it up more and slowly put it into place.
> This way I can see what the problem is.
Ok, ...
> > And what is the current status of fbdev in 2.5.x ? 2.5.1 + ruby hang my box
> > early in the boot process, but that is probably because pm3fb is not working
> > yet for ruby. Does matroxfb work ? i have an older pci matrox board that i
> > could install to test and do some pm3fb work if needed (and if i get the time
> > for it :(((0
>
> Only a hand full of drivers have truly been converted over in the console
> CVS. The hanging is most likely due to the new console lock. I have
> decided that the ruby tree will be used for code deposting and the DJ tree
> will be the real testing ground.
Mmm, ...
So what is the best place to look at if one wants to do some driver work. Not
that i really have that much time, but i may look into porting the pm3fb
driver to the new scheme, but ruby + 2.5.1 hangs hopelessly for me, and if it
is not the latest stuff around, it would not be the best place to work from.
Also, i suppose there is no documentation whatsoever yet, apart from the
source and the mailing list archive here ?
Friendly,
Sven Luther
> Mmm, ...
>
> So what is the best place to look at if one wants to do some driver work. Not
> that i really have that much time, but i may look into porting the pm3fb
> driver to the new scheme, but ruby + 2.5.1 hangs hopelessly for me, and if it
> is not the latest stuff around, it would not be the best place to work from.
The best tree to work with is the Dave Jones tree for 2.5.X. DJ tree
provides a better testing ground. Eventually when stuff goes from DJ to
Linus tree ruby and 2.5.X will look alot more alike :-)
> Also, i suppose there is no documentation whatsoever yet, apart from the
> source and the mailing list archive here ?
That is my fault :-( I have been so busy coding I haven't written any
docs.
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
On Sat, Jan 19, 2002 at 02:50:09PM -0800, James Simmons wrote:
>
> > Mmm, ...
> >
> > So what is the best place to look at if one wants to do some driver work. Not
> > that i really have that much time, but i may look into porting the pm3fb
> > driver to the new scheme, but ruby + 2.5.1 hangs hopelessly for me, and if it
> > is not the latest stuff around, it would not be the best place to work from.
>
> The best tree to work with is the Dave Jones tree for 2.5.X. DJ tree
> provides a better testing ground. Eventually when stuff goes from DJ to
> Linus tree ruby and 2.5.X will look alot more alike :-)
Mmm, any timeline for the DJ->linus move ?
And if i understood you right, ruby is now obsolet, and we should all work
with the -dj tree ? Does it even make sense to do some work on the older (well
2.4 and current 2.5) drivers, or is it not adviseable ?
BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
changing, and the new info.node, which needed to be changed to
info.node.values.
Also, i tried Petr's suggestions for the corruption while changing from vgacon
to pm3fb, but it didn't work, i will have to look more in detail about it, i
remember X had some similar problems with textmode, where the switching to X
and back corrupted the fonts, which were supposed to be saved.
I think this is because in the pm3 board i use, the vga reading/writing is
corrupt, at least in one of the two (pio or mmio) modes, i think it is mmio
ones, but i don't remember right. I think in the X driver we solved this by
hand copying the whole 64k or such of vga stuff, but i don't remember right,
and i didn't write the code anyway, since i have no knowledge whatsoever of
the vga stuff.
> > Also, i suppose there is no documentation whatsoever yet, apart from the
> > source and the mailing list archive here ?
>
> That is my fault :-( I have been so busy coding I haven't written any
> docs.
... I imagined such. What is the best why to understand how all this works in
order to port the pm3fb driver to the new setup (well there is already
something in there, but it does not work, and romain has only a ppc box, on
which ruby did not work anyway, i guess once pm3fb + new fbdev works on i386,
it would be easier for him to look at the ppc particularities.
Friendly,
Sven Luther
> > The best tree to work with is the Dave Jones tree for 2.5.X. DJ tree
> > provides a better testing ground. Eventually when stuff goes from DJ to
> > Linus tree ruby and 2.5.X will look alot more alike :-)
>
> Mmm, any timeline for the DJ->linus move ?
At the moment no. I guess when Linus will take patches :-)
> And if i understood you right, ruby is now obsolet, and we should all work
> with the -dj tree ? Does it even make sense to do some work on the older (well
> 2.4 and current 2.5) drivers, or is it not adviseable ?
I wouldn't say obsolete. The input stuff just got syned to the -dj tree.
So ruby and -dj tree are almost the same in this case. I'm going to work
on drivers/char/keyboard.c today to make it work with the input layer
directly instead of going threw keybdev.c in drivers/input then pc_keyb.c
as it does now. It still will work the old way tho as well. Thsi is for
the keyboard drivers not ported over to the input api.
NOTE: keyboard maintainers please move your drivers over to the input api.
It will speed up the transition.
As for the fbdev layer. Their was way to much code to cleanup and maintain
in sync. So ruby had hardly any fbdev ported over :-( Now I'm spending the
time to port every single fbdev driver over. Alot of work but it is
needed.
> BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> changing, and the new info.node, which needed to be changed to
> info.node.values.
The correct fix is to do something like fb_info.node = NODEV;
> Also, i tried Petr's suggestions for the corruption while changing from vgacon
> to pm3fb, but it didn't work, i will have to look more in detail about it, i
> remember X had some similar problems with textmode, where the switching to X
> and back corrupted the fonts, which were supposed to be saved.
Oh. That will not be fixed for awhile in the upper console layers. I did
have a fix for those sort of problems.
> > That is my fault :-( I have been so busy coding I haven't written any
> > docs.
>
> ... I imagined such. What is the best why to understand how all this works in
> order to port the pm3fb driver to the new setup (well there is already
> something in there, but it does not work, and romain has only a ppc box, on
> which ruby did not work anyway, i guess once pm3fb + new fbdev works on i386,
> it would be easier for him to look at the ppc particularities.
Right now the changes have been the moving of fb_blank from struct fb_info
to struct fb_ops. I placed xxfb_setcolreg into struct fb_ops. I just sent
a patch in to remove struct fbcon_cmap and use instead pseudo_palette in
struct fb_info. I now have every driver compiled with fbgen.c. This allows
us to use one function at a time in fbgen.c. Right now most drivers use
do_install_cmap and fbgen_set_cmap in fbgen.c instead of their own
functions.
On Mon, 21 Jan 2002, James Simmons wrote:
> > > The best tree to work with is the Dave Jones tree for 2.5.X. DJ tree
> > > provides a better testing ground. Eventually when stuff goes from DJ to
> > > Linus tree ruby and 2.5.X will look alot more alike :-)
> > Mmm, any timeline for the DJ->linus move ?
> At the moment no. I guess when Linus will take patches :-)
I'm pushing Linus some of the small bits right now (though no
feedback, so I'm backing off simultaneously)
I'm staying clear of the fbdev/console code for two reasons.
1. I'd rather James/Vojtech did this so that a, they get it right
and b, it gives me more time to push Linus other bits.
2. Several Framebuffer driver authors want to push their relevant
bits to Linus themselves. which is fine by me. (See 1b)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
>
> As for the fbdev layer. Their was way to much code to cleanup and maintain
> in sync. So ruby had hardly any fbdev ported over :-( Now I'm spending the
> time to port every single fbdev driver over. Alot of work but it is
> needed.
Ahem, ...
If you would take a little bit of time to write some doc or ruby howto, maybe
you would not need to port them all by yourself ...
BTW, the matrox driver don't build on ruby + 2.5.1
> > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > changing, and the new info.node, which needed to be changed to
> > info.node.values.
>
> The correct fix is to do something like fb_info.node = NODEV;
And not info.node.value = -1 ?
Ok, will do.
Friendly,
Sven Luther
On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
>
> > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > changing, and the new info.node, which needed to be changed to
> > info.node.values.
>
> The correct fix is to do something like fb_info.node = NODEV;
And not B_FREE ?
I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
value assigned to .node was -1, which correspond to B_FREE and not NODEV
(which is 0).
That said, since it is almost never used, it would maybe be best to move it
out of the fbdevs and into some of the more generic layers.
Also, since when does the B_FREE or NODEV exists ? I did put the changes into
a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
remove this check altogether if the NODEV was present from the begining. And
what about 2.2 kernels ?
Mmm, maybe i would have to check myself, will do that tomorrow, when i get
access to my work box again.
Romain, what is the earliest kernel you think pm3fb is able to run on, so i
can check it out.
BTW, does someone know how i can get information about the hardware on a SGI
indy runing IRIX, i plan to do a linux install on it next week, but would like
to inspectr the box some before doing that. Is there any kind of fbdev working
for this kind of hardware ?
Friendly,
Sven Luther
On Wed, 23 Jan 2002, Sven wrote:
> On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
> >
> > > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > > changing, and the new info.node, which needed to be changed to
> > > info.node.values.
> >
> > The correct fix is to do something like fb_info.node = NODEV;
>
> And not B_FREE ?
>
> I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
> value assigned to .node was -1, which correspond to B_FREE and not NODEV
> (which is 0).
>
> That said, since it is almost never used, it would maybe be best to move it
> out of the fbdevs and into some of the more generic layers.
>
> Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> remove this check altogether if the NODEV was present from the begining. And
IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
this problem.
> what about 2.2 kernels ?
No idea. Ask Alan :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 23 Jan 2002, Sven wrote:
> On Wed, Jan 23, 2002 at 06:34:03PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 23 Jan 2002, Sven wrote:
> > > Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> > > a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> > > remove this check altogether if the NODEV was present from the begining. And
> >
> > IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
> > this problem.
> >
> > > what about 2.2 kernels ?
> >
> > No idea. Ask Alan :-)
>
> Ok, so the best thing would be to keep the #ifdef then.
>
> or maybe i could try an :
>
> #ifdef NODEV
> ..node = NODEV
> #else
> ..node = -1
> #endif
>
> ?
Or even shorter (and cleaner, IMHO):
#ifndef NODEV
#define NODEV -1
#endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Jan 23, 2002 at 06:41:38PM +0100, Geert Uytterhoeven wrote:
> On Wed, 23 Jan 2002, Sven wrote:
> > On Wed, Jan 23, 2002 at 06:34:03PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 23 Jan 2002, Sven wrote:
> > > > Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> > > > a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> > > > remove this check altogether if the NODEV was present from the begining. And
> > >
> > > IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
> > > this problem.
> > >
> > > > what about 2.2 kernels ?
> > >
> > > No idea. Ask Alan :-)
> >
> > Ok, so the best thing would be to keep the #ifdef then.
> >
> > or maybe i could try an :
> >
> > #ifdef NODEV
> > ..node = NODEV
> > #else
> > ..node = -1
> > #endif
> >
> > ?
>
> Or even shorter (and cleaner, IMHO):
>
> #ifndef NODEV
> #define NODEV -1
> #endif
yes, ...
Friendly,
Sven Luther
On Wed, Jan 23, 2002 at 06:34:03PM +0100, Geert Uytterhoeven wrote:
> On Wed, 23 Jan 2002, Sven wrote:
> > On Mon, Jan 21, 2002 at 09:03:25AM -0800, James Simmons wrote:
> > >
> > > > BTW, romain, i have built pm3fb with 2.5.2, there were some modifications
> > > > needed, the major of them was the testing for 2.2 or 2.4 kernels that needed
> > > > changing, and the new info.node, which needed to be changed to
> > > > info.node.values.
> > >
> > > The correct fix is to do something like fb_info.node = NODEV;
> >
> > And not B_FREE ?
> >
> > I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
> > value assigned to .node was -1, which correspond to B_FREE and not NODEV
> > (which is 0).
> >
> > That said, since it is almost never used, it would maybe be best to move it
> > out of the fbdevs and into some of the more generic layers.
> >
> > Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> > a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> > remove this check altogether if the NODEV was present from the begining. And
>
> IIRC, Marcelo added NODEV to 2.4.x in one of his latest releases, just to solve
> this problem.
>
> > what about 2.2 kernels ?
>
> No idea. Ask Alan :-)
Ok, so the best thing would be to keep the #ifdef then.
or maybe i could try an :
#ifdef NODEV
..node = NODEV
#else
..node = -1
#endif
?
Friendly,
Sven Luther
> > The correct fix is to do something like fb_info.node = NODEV;
>
> And not B_FREE ?
>
> I am unsure about this, but i notice that in the 2.4.17 kernel + pm3fb, the
> value assigned to .node was -1, which correspond to B_FREE and not NODEV
> (which is 0).
Looking at it your right. It should be B_FREE.
> That said, since it is almost never used, it would maybe be best to move it
> out of the fbdevs and into some of the more generic layers.
I agree. In fact it is already does set it. Form rgeister_framebuffer
fb_info->node = mk_kdev(FB_MAJOR, i);
So why does any fbdev driver touch it?
> Also, since when does the B_FREE or NODEV exists ? I did put the changes into
> a #ifdef kernel 2.5, and kept the -1 for kernels 2.4, but i guess i could
> remove this check altogether if the NODEV was present from the begining. And
> what about 2.2 kernels ?
It is a 2.5.X thing.