Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2001-05-21 20:43:13
|
On 21 May 01 at 22:21, Otto Wyss wrote:
> What's the reason for this? It might be that the lilo kernel parameters
> won't get routed to the modularized drivers but why weren't options read
> from modules.conf?
Drivers do not read options from modules.conf, modprobe does. When built
into kernel, fbdev drivers support unified 'video=<fbdevname>:options'
kernel cmdline argument, but when they are built as modules, it differs
from driver to driver (f.e. matroxfb supports all these options,
instead of video=matrox:a:b you write 'insmod matroxfb_base a=b')
> It seems the the frame buffer drivers gets started rather late in the
> startup process. What defines this order, could frame buffer drivers be
> moved more to the beginning?
I do not understand. Of course that if you compiled these drivers as modules
then they are started after / is mounted r/w. What else do you expect
from modules? And if you are talking about fbdev drivers in kernel, then
I think that they are started too early. Currently my kernel initializes
all device drivers after all other subsystems were initialized, just before
mounting root read-only, and I'm very happy from this. Only problem is that
I had to do some hotplugging fixes in some code.
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Petr V. <VAN...@vc...> - 2001-05-21 21:46:21
|
On 21 May 01 at 23:09, Otto Wyss wrote:
> > Drivers do not read options from modules.conf, modprobe does. When built
> > into kernel, fbdev drivers support unified 'video=<fbdevname>:options'
> > kernel cmdline argument, but when they are built as modules, it differs
> > from driver to driver (f.e. matroxfb supports all these options,
> > instead of video=matrox:a:b you write 'insmod matroxfb_base a=b')
> >
> And what if drivers gets loaded if the kernel module loader calls
> modprobe?
modprobe reads modules.conf and creates correct insmod line.
> As far as I understand, in the atyfb, aty128fb the option processing are
> disabled through a compile time option (#ifndef MODULE).
someone have to change types for curblink, noaccel and default_vram to
int and then add
MODULE_PARM(curblink, "i"); MODULE_PARM(noaccel, "i") ... and so on.
If you compiled driver as module, then mode database is not available
(it is __init thing), so there is no way how to get non-default resolution.
But you can add
post-install atyfb fbset 1280x1024@100 -a
into modules.conf.
> > I do not understand. Of course that if you compiled these drivers as modules
> > then they are started after / is mounted r/w. What else do you expect
> > from modules? And if you are talking about fbdev drivers in kernel, then
> >
> Why do they have to wait after / is mounted r/w? If a driver doesn't
> write to the drive there is no need. What's the difference between a
> linked and a modularized driver besides just store in different places.
/etc/modules is usually parsed after / remounted r/w. If you trigger
module load by accessing /dev/fb*, then it is different, of course.
Difference between built in and modularized driver is that builtin
driver can get options from kernel commandline and is initialized before
system comes up. Modularized drivers can be loaded only after / filesystem
was mounted (at least read-only), so couple of things have to happen
before. You should built-in all drivers for hardware your machine has into
kernel unless you are just developing that drivers. It saves you from
couple of troubles...
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Otto W. <ott...@bl...> - 2001-05-22 18:46:29
|
> someone have to change types for curblink, noaccel and default_vram to > int and then add > > MODULE_PARM(curblink, "i"); MODULE_PARM(noaccel, "i") ... and so on. > I'm not a kernel/driver developer and have not enough time to get used to it. > If you compiled driver as module, then mode database is not available > (it is __init thing), so there is no way how to get non-default resolution. > But you can add > > post-install atyfb fbset 1280x1024@100 -a > > into modules.conf. > I tried it and the post-install works on the first console but not on others. Besides fbset needs HHHHxVVVV-RR (note the "-" before the refresh rate). What's the meaning of the "-a" at the end? Neither man modules.conf nor man fbset shows its meaning. > > Why do they have to wait after / is mounted r/w? If a driver doesn't > > write to the drive there is no need. What's the difference between a > > linked and a modularized driver besides just store in different places. > > /etc/modules is usually parsed after / remounted r/w. If you trigger > module load by accessing /dev/fb*, then it is different, of course. > Difference between built in and modularized driver is that builtin > driver can get options from kernel commandline and is initialized before > system comes up. Modularized drivers can be loaded only after / filesystem > was mounted (at least read-only), so couple of things have to happen > before. You should built-in all drivers for hardware your machine has into > kernel unless you are just developing that drivers. It saves you from > couple of troubles... > [OFF TOPIC ON] With only 3 different graphics card I could easily compile all into the kernel. But I thought it might be a good time to try the modularized versions. It's just a matter of time until all drivers where able to run as modules and only the absolute essentials will be kept in the kernel. With the introduction of the hotplug feature drivers slowly will be uses as modules and than made hotplugable even if the never get plugged/unplugged. So it might be a good idea to care about it as well. [OFF TOPIC OFF] O. Wyss |
|
From: Otto W. <ott...@bl...> - 2001-05-22 19:09:20
|
> post-install atyfb fbset 1280x1024@100 -a >=20 > into modules.conf. >=20 I just discovered that at the first console (the one this command get executed) uses a wrong font, any "=E4=F6=FC" gets printed like "*=F7=FF". O. Wyss |
|
From: Petr V. <VAN...@vc...> - 2001-05-22 19:11:40
|
On 22 May 01 at 20:46, Otto Wyss wrote:
> > someone have to change types for curblink, noaccel and default_vram to
> > int and then add
> >
> > MODULE_PARM(curblink, "i"); MODULE_PARM(noaccel, "i") ... and so on.
> I'm not a kernel/driver developer and have not enough time to get used
> to it.
Then build driver into kernel.
> I tried it and the post-install works on the first console but not on
> others. Besides fbset needs HHHHxVVVV-RR (note the "-" before the
Sorry.
> refresh rate). What's the meaning of the "-a" at the end? Neither man
> modules.conf nor man fbset shows its meaning.
Set resolution on all consoles ;-)
> [OFF TOPIC ON]
> With only 3 different graphics card I could easily compile all into the
> kernel. But I thought it might be a good time to try the modularized
> versions. It's just a matter of time until all drivers where able to run
> as modules and only the absolute essentials will be kept in the kernel.
> With the introduction of the hotplug feature drivers slowly will be uses
> as modules and than made hotplugable even if the never get
> plugged/unplugged. So it might be a good idea to care about it as well.
> [OFF TOPIC OFF]
It looks like that it is trivially fixable (except modedb):
remove all #if[n]def MODULE, create
static const char* opt = NULL;
MODULE_PARM(opt, "s");
and add atyfb_setup(opt) at the beginning of its init_module()
function, just before atyfb_init() - then atyfb will understand
opt="font:VGA8x16,noblink,noaccel,vram:123,pll:456,mclk:789" (do not
forget " around the string, otherwise insmod splits string at commas).
Just something to think about...
Petr Vandrovec
van...@vc...
|
|
From: Otto W. <ott...@bl...> - 2001-05-22 19:23:53
|
> > refresh rate). What's the meaning of the "-a" at the end? Neither man > > modules.conf nor man fbset shows its meaning. > > Set resolution on all consoles ;-) > Not on my system (currently aty128fb), I tried with and without "-a", same effect. O. Wyss |
|
From: Petr V. <VAN...@vc...> - 2001-05-22 19:13:08
|
On 22 May 01 at 21:09, Otto Wyss wrote:
> > post-install atyfb fbset 1280x1024@100 -a
> >
> > into modules.conf.
> >
> I just discovered that at the first console (the one this command get
> executed) uses a wrong font, any "=E4=F6=FC" gets printed like "*=F7y".
You have to reload your translation tables after each mode switch
afaik.
Petr Vandrovec
van...@vc...
|
|
From: Petr V. <VAN...@vc...> - 2001-05-22 19:29:08
|
On 22 May 01 at 21:23, Otto Wyss wrote:
> > > refresh rate). What's the meaning of the "-a" at the end? Neither man
> > > modules.conf nor man fbset shows its meaning.
> >
> > Set resolution on all consoles ;-)
> >
> Not on my system (currently aty128fb), I tried with and without "-a",
> same effect.
Then you have either broken system or broken fbset:
bash:/tmp# fbset --help
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
...
-a, --all : change all virtual consoles on this device
...
and of course it works here with matroxfb, atyfb and vga16fb. As it
is done on fbcon layer, fbdev type should not matter.
Petr Vandrovec
van...@vc...
|
|
From: Otto W. <ott...@bl...> - 2001-05-22 20:03:30
|
> Then you have either broken system or broken fbset: > > bash:/tmp# fbset --help > Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999) > ... > -a, --all : change all virtual consoles on this device > ... > I should have used fbset --help beside man fbset, so I don't had to ask about "-a". I've the same version and "fbset 800x600-72 -a" works. But the post-install in modules.conf options aty128fb 800x600@72 post-install aty128fb fbset 800x600-72 -a doesn't. Modprobe is version 2.4.6 and my system is an uptodate Debian woody with kernel 2.4.3. O. Wyss |
|
From: Petr V. <VAN...@vc...> - 2001-05-22 20:21:51
|
On 22 May 01 at 22:03, Otto Wyss wrote:
> I should have used fbset --help beside man fbset, so I don't had to ask
> about "-a". I've the same version and "fbset 800x600-72 -a" works. But
> the post-install in modules.conf
>
> options aty128fb 800x600@72
> post-install aty128fb fbset 800x600-72 -a
>
> doesn't. Modprobe is version 2.4.6 and my system is an uptodate Debian
> woody with kernel 2.4.3.
Try post-install aty128fb -- fbset 800x600-72 -a
Otherwise you have to create shell script...
Petr
|
|
From: Otto W. <ott...@bl...> - 2001-05-21 21:09:31
|
> > What's the reason for this? It might be that the lilo kernel parameters > > won't get routed to the modularized drivers but why weren't options read > > from modules.conf? > > Drivers do not read options from modules.conf, modprobe does. When built > into kernel, fbdev drivers support unified 'video=<fbdevname>:options' > kernel cmdline argument, but when they are built as modules, it differs > from driver to driver (f.e. matroxfb supports all these options, > instead of video=matrox:a:b you write 'insmod matroxfb_base a=b') > And what if drivers gets loaded if the kernel module loader calls modprobe? As far as I understand, in the atyfb, aty128fb the option processing are disabled through a compile time option (#ifndef MODULE). > > It seems the the frame buffer drivers gets started rather late in the > > startup process. What defines this order, could frame buffer drivers be > > moved more to the beginning? > > I do not understand. Of course that if you compiled these drivers as modules > then they are started after / is mounted r/w. What else do you expect > from modules? And if you are talking about fbdev drivers in kernel, then > Why do they have to wait after / is mounted r/w? If a driver doesn't write to the drive there is no need. What's the difference between a linked and a modularized driver besides just store in different places. O. Wyss |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X