"Matthew N. Dodd" wrote:
Agreed. I like what I see there. Maybe it is time to hoist something
like that into bus_subr.c
Lets define exactly what we want before we start our charge.
What should be printed?
device ID
attachment point
resource reservation
device
Surely if you don't want to see the boot messages for cosmetic
reasons a splash screen is the most cosmeticly pleasing solution.
Speaking of splash screens (a bit far from the thread's original
topic), I've got my laptop set up to show the daemon-and-sunset
picture on boot, but it
On Fri, 13 Aug 1999 09:48:47 EST, "Matt Crawford" wrote:
load kernel
load -t splash_image_data daemon_640.bmp
load vesa
load splash_bmp
boot
Why boot and not autoboot?
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
On Wed, 11 Aug 1999, Brian F. Feldman wrote:
What in the world would be the point of doing this? What would be so great
about not seeing the system boot up?
One might want minimal or no boot messages, just to look nice, while
still wanting the dmesg stuff around in case something goes wrong
On 12-Aug-99 Ben Rosengart wrote:
On Wed, 11 Aug 1999, Brian F. Feldman wrote:
What in the world would be the point of doing this? What would be so
great
about not seeing the system boot up?
One might want minimal or no boot messages, just to look nice, while
still wanting the dmesg
: Correct, but the nature of the kernel probe/attach messages is to convey
: information in a readable, consistent, useful manner.
Agreed. However, what's magical about 80 columns?
What's magical is that almost every text console is limited to 80
columns (think serial console), as well as
On Wed, 11 Aug 1999, Warner Losh wrote:
Then we disagree. There are several scripts floating around that use
them for purposes where there isn't a kernel interface... It would be
ideal if there were interfaces for all this info, but there isn't
always.
Fine. Due to flux in the bus-system
On Wed, 11 Aug 1999, Nate Williams wrote:
The most common case for a console is an 80 column wide console (this is
the default for the virtual terminals, most printers, most text
terminals, etc..)
Changing it is silly, and non-standard.
The line wrapping stuff I brought back for the EISA
In message [EMAIL PROTECTED] Nate Williams writes:
: And you plan on booting FreeBSD on your PDA?
Yes. I'm already booting NetBSD/hpcmips on it But that's another
thread all by itself...
: stty columns is only effective *AFTER* you have a shell and the box has
: booted.
Yes I know that,
: stty columns is only effective *AFTER* you have a shell and the box has
: booted.
Yes I know that, but you seem to be arguing that all terminals have 80
columns... This is not the case, although many of them do.
Most of them do. It is the 'least common denominator' that FreeBSD runs
Nate Williams scribbled this message on Aug 11:
: The line wrapping stuff I brought back for the EISA bus stuff in -current
: makes it easy to define the wrap point. If some small number of people
: want the ability to wrap at 132 or 40 or whatever, I don't think its
: unreasonable to
On Wed, 11 Aug 1999, Warner Losh wrote:
It also would allow one to kick the VGA display into 132 columns in
the boot loader and have more of a chance to get more of the boot
process on the screen. syscons already supports parts of this...
I was just reading through the thread again, and I
After taking a break from this discussion, I do think that I like the
idea of wrapping boot messages in a sane way at column n (= 80 by
default) so long as one knows where messages from one device end and
the next one begin.
I'd also oppose things like
foo0: .. irq
foo0: 9
as opposed to
On Wed, 11 Aug 1999, Warner Losh wrote:
No! At some point they should use a facility similar to solaris/sysv
where they don't display, but do make it into the dmesg buffer...
Warner
What in the world would be the point of doing this? What would be so great
about not seeing the system
On Wed, 11 Aug 1999, Warner Losh wrote:
After taking a break from this discussion, I do think that I like the
idea of wrapping boot messages in a sane way at column n (= 80 by
default) so long as one knows where messages from one device end and
the next one begin.
I'd also oppose things
On Wed, 11 Aug 1999, Brian F. Feldman wrote:
What in the world would be the point of doing this? What would be so
great about not seeing the system boot up?
The same reason that when you type 'cp foo /tmp/' it doesn't say '1 file
copied, 3425 bytes.' or other nonesense. If nothings wrong then
[[ cc trimmed. ]]
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: check out eisa_reg_print() and eisa_print_child() in
: sys/i386/eisa/eisaconf.c
:
: Sanity in output is a good thing.
Agreed. I like what I see there. Maybe it is time to hoist something
like that into bus_subr.c
On Wed, 11 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: check out eisa_reg_print() and eisa_print_child() in
: sys/i386/eisa/eisaconf.c
:
: Sanity in output is a good thing.
Agreed. I like what I see there. Maybe it is time to hoist something
In message [EMAIL PROTECTED] Peter Wemm writes:
: This still needs more work to handle line wraps etc. Matthew Dodd did some
: work in this area for the EISA code which should be able to be used.
I'd be very careful of line wrapping probe messages. I have scripts
that rely on them being on one
On Mon, 9 Aug 1999, Daniel O'Connor wrote:
You could do it something like the way boot -c stuff or the splash screen is
done, ie load a 'module' which is just a text file for the sound system to
parse..
Don't know how you'd go unload'ing and load'ing the file though.
Why that
Cameron Grant wrote:
to let newpcm out of the cage so you can all get your grubby little hands on
it.
http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz
this is a patch against a recent -current. if you have a pci or isapnp
soundcard, you should have pnp0 and pcm0 in your
Daniel O'Connor wrote:
On 09-Aug-99 Alex Zepeda wrote:
Actually at shutdown would be cool. So it could save the current
volumes,
and restore them at startup. Altho, at suspend and resume time
wouldn't
be a bad idea either.
You could do it something like the way boot -c stuff or
On Mon, 9 Aug 1999, Brian F. Feldman wrote:
You guys don't see the point. The point is a single, simple place to put
default mixer values for any number of devices, and fitting in with the
current configuration file scenario. rc is the natural place for this,
because _it_ gets run at
On 09-Aug-99 Brian F. Feldman wrote:
You guys don't see the point. The point is a single, simple place to put
default mixer values for any number of devices, and fitting in with the
current configuration file scenario. rc is the natural place for this,
because _it_ gets run at startup. I
On Tue, 10 Aug 1999, Daniel O'Connor wrote:
On 09-Aug-99 Brian F. Feldman wrote:
You guys don't see the point. The point is a single, simple place to put
default mixer values for any number of devices, and fitting in with the
current configuration file scenario. rc is the natural
On Mon, 9 Aug 1999, Alex Zepeda wrote:
One could stuff it into rc.conf, but this means it's harder to
automagically save the state upon shutdown/reboot. But something like:
Not really. You could do it with grep, awk, sed, or whatever you want,
easily. The only possible problem would be...
On 10-Aug-99 Brian F. Feldman wrote:
Sure.. but you still have window of time where the audio is at its default
level before the rc stuff is run..
Why... would audio be playing from rc? Bear in mind, it would be set
even before rc.local...
I have a radio connected to line in on my sound
On Tue, 10 Aug 1999, Daniel O'Connor wrote:
On 10-Aug-99 Brian F. Feldman wrote:
Sure.. but you still have window of time where the audio is at its default
level before the rc stuff is run..
Why... would audio be playing from rc? Bear in mind, it would be set
even before
On 10-Aug-99 Brian F. Feldman wrote:
I have a radio connected to line in on my sound card.
Then that would be playing during the entire bootup, wouldn't it? What,
does it play only after the card has been detected?
The sound card shuts up after reset, and only starts outputing noise again
to let newpcm out of the cage so you can all get your grubby little hands on
it.
http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz
this is a patch against a recent -current. if you have a pci or isapnp
soundcard, you should have pnp0 and pcm0 in your kernel config as
On Sun, 8 Aug 1999, Kenneth Wayne Culver wrote:
It works ok for me, but one nice feature of the sound system would be if
upon shutdown (I don't leave my machine on all the time right now) OS
somehow looked at a config file (call it /etc/soundvol.conf) for mixer
volumes, and set them to that
On Sun, 8 Aug 1999, Brian F. Feldman wrote:
It works ok for me, but one nice feature of the sound system would be if
upon shutdown (I don't leave my machine on all the time right now) OS
somehow looked at a config file (call it /etc/soundvol.conf) for mixer
volumes, and set them to that
On Sun, 8 Aug 1999, Brian F. Feldman wrote:
It works ok for me, but one nice feature of the sound system would be if
upon shutdown (I don't leave my machine on all the time right now) OS
somehow looked at a config file (call it /etc/soundvol.conf) for mixer
volumes, and set them to
On 09-Aug-99 Alex Zepeda wrote:
Actually at shutdown would be cool. So it could save the current volumes,
and restore them at startup. Altho, at suspend and resume time wouldn't
be a bad idea either.
You could do it something like the way boot -c stuff or the splash screen is
done, ie
On 09-Aug-99 Mike Smith wrote:
Gosh, let's see; at shutdown it could edit /etc/rc.conf. Wouldn't that
be handy? And so easy too. 8)
Ahh but then you have to put up with the default sound levels until
/etc/rc.conf is used :)
---
Daniel O'Connor software and network engineer
for Genesis
35 matches
Mail list logo
