Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@tr...> - 2002-01-16 01:07:11
|
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.
|
|
From: Sven <lu...@dp...> - 2002-01-18 10:26:56
|
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 |
|
From: James S. <jsi...@tr...> - 2002-01-18 17:20:59
|
> > 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. |
|
From: Sven <lu...@dp...> - 2002-01-19 17:21:28
|
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 |
|
From: James S. <jsi...@tr...> - 2002-01-19 22:50:23
|
> 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!!!! (| | ) /'_ _/`\ ___)=(___/ |
|
From: Sven <lu...@dp...> - 2002-01-21 08:29:12
|
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 |
|
From: James S. <jsi...@tr...> - 2002-01-21 17:03:40
|
> > 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. |
|
From: Dave J. <da...@su...> - 2002-01-21 17:18:52
|
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 |
|
From: Sven <lu...@dp...> - 2002-01-21 21:12:41
|
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 |
|
From: Sven <lu...@dp...> - 2002-01-23 17:31:31
|
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 |
|
From: Geert U. <ge...@li...> - 2002-01-23 17:34:33
|
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 -- ge...@li...
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
|
|
From: Sven <lu...@dp...> - 2002-01-23 17:40:28
|
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 |
|
From: Geert U. <ge...@li...> - 2002-01-23 17:42:01
|
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 -- ge...@li...
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
|
|
From: Sven <lu...@dp...> - 2002-01-23 17:43:03
|
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 |
|
From: Carl W. S. <ch...@re...> - 2002-01-23 17:42:58
|
> 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 ? 'hinv' (Hardware INVentory) is the irix command you're looking for. I know there's some sort of framebuffer support for it; since it doesn't have a VGA mode. dunno anything more about it than that. the Indy also has the distinction of being the only SGI to have an XFree86 driver for its video (newport). we had one here for a while; and I saw it boot linux; but don't know any more than that. Carl Soderstrom. -- Network Engineer Real-Time Enterprises (952) 943-8700 |
|
From: Sven <lu...@dp...> - 2002-01-23 17:50:42
|
On Wed, Jan 23, 2002 at 11:42:50AM -0600, Carl Wilhelm Soderstrom wrote: > > 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 ? > > 'hinv' (Hardware INVentory) is the irix command you're looking for. Yes, that is what i am looking for, as a result, i now know it has a r4600 processor, and an 'indy 8-bit' graphic board :))) > I know there's some sort of framebuffer support for it; since it doesn't > have a VGA mode. dunno anything more about it than that. > the Indy also has the distinction of being the only SGI to have an XFree86 > driver for its video (newport). Is this newport the same as indy 8-bit ? I had the impressoion that there were multiple possibilities about it. > we had one here for a while; and I saw it boot linux; but don't know any > more than that. Anyway, thanks for the info ... Friendly, Sven Luther |
|
From: Carl W. S. <ch...@re...> - 2002-01-23 17:57:41
|
> > I know there's some sort of framebuffer support for it; since it doesn't > > have a VGA mode. dunno anything more about it than that. > > the Indy also has the distinction of being the only SGI to have an XFree86 > > driver for its video (newport). > > Is this newport the same as indy 8-bit ? I had the impressoion that there were > multiple possibilities about it. maybe. the two video board models I know about, are the 8-bit, and the 24-bit. dunno which is supported, or how well. we had one of each kind of board, but I don't remember ever actually running linux/X on the Indy we had; tho we did use the console. we just used SGI's X server for any GUI stuff. Carl Sodertstrom. -- Network Engineer Real-Time Enterprises (952) 943-8700 |
|
From: Sven <lu...@dp...> - 2002-01-23 18:08:46
|
On Wed, Jan 23, 2002 at 11:57:34AM -0600, Carl Wilhelm Soderstrom wrote: > > > I know there's some sort of framebuffer support for it; since it doesn't > > > have a VGA mode. dunno anything more about it than that. > > > the Indy also has the distinction of being the only SGI to have an XFree86 > > > driver for its video (newport). > > > > Is this newport the same as indy 8-bit ? I had the impressoion that there were > > multiple possibilities about it. > > maybe. the two video board models I know about, are the 8-bit, and the > 24-bit. dunno which is supported, or how well. we had one of each kind of Ok, ... > board, but I don't remember ever actually running linux/X on the Indy we > had; tho we did use the console. if fbdev works, then it is fine with me. altough X would have been nice, i suppose X with the fbdev driver would work on such a setup anyway, but may be real slow, but not slower than on my 68030 amiga back then. > we just used SGI's X server for any GUI stuff. Under IRIX i guess ... Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2002-01-24 08:43:31
|
On Wed, 23 Jan 2002, Sven wrote:
> On Wed, Jan 23, 2002 at 11:57:34AM -0600, Carl Wilhelm Soderstrom wrote:
> > we just used SGI's X server for any GUI stuff.
>
> Under IRIX i guess ...
I _think_ Linux/MIPS provides an IRIX-compatible /dev/graphics...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: James S. <jsi...@tr...> - 2002-01-24 17:53:13
|
> > 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. |
Thanks for helping keep SourceForge clean.
X