"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
>
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 t
> 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 see
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 th
> 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 somethi
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 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 so
[[ 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, 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 the
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 thin
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 sy
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
fo
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
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
> > : unreasonabl
Warner Losh wrote in list.freebsd-current:
> 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...
As a small sidenote: Most PDAs can be used
> : 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 run
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,
> : 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 provide them the knob to tweak in the boot loader.
In message <[EMAIL PROTECTED]>
"Matthew N. Dodd" writes:
: 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 p
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 EI
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-syst
> : 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
In message <[EMAIL PROTECTED]> "Matthew N.
Dodd" writes:
: On Tue, 10 Aug 1999, Warner Losh wrote:
: > I'd be very careful of line wrapping probe messages. I have scripts
: > that rely on them being on one line to get a list of irqs, etc.
:
: I would consider information from the kernel probe/a
On Tue, 10 Aug 1999, Warner Losh wrote:
> I'd be very careful of line wrapping probe messages. I have scripts
> that rely on them being on one line to get a list of irqs, etc.
I would consider information from the kernel probe/attach to be useful
only for humans.
An interface to query the resou
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 on
On Tue, 10 Aug 1999, Alex Zepeda wrote:
:* an rc.audio or rc.multimedia (this could perhaps contain some bt484
:related things).
:
:But if it goes into "the" rc.conf, that would mean that whenever it runs
:at shutdown, it edits rc.conf; this isn't IMO a real great idea.
:Anything automated (eve
"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 y
On Mon, 9 Aug 1999, Brian F. Feldman wrote:
> 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
On Tue, 10 Aug 1999, Daniel O'Connor wrote:
> The sound card shuts up after reset, and only starts outputing noise again
> after the sound card has been probed/attached.
Perhaps the attach routine (or rc.something) should explicitly zero all
the volumes, so that the card will remain silent until
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 ag
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 befor
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
>
> 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 ru
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... G
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 natu
[EMAIL PROTECTED] wrote:
>>
>> As far as I know, rc.shutdown doesn't get run unless you go to single
>> user mode (for example, 'shutdown -h now' will not cause init to run
>> rc.shutdown).
I think FreeBSD-current was fixed and everytime run rc.shutdown.
SEE GNATS DB bin/12093.
http://www.fr
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
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 star
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
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
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 just need to find somewhere to put
this instea
> 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.
>
>
On Mon, 9 Aug 1999, Daniel O'Connor wrote:
> > Why that complex? Couldn't I just drop in a small script using awk and
> > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a
> > small C program would suffice if scripting isn't your cup of tea.
>
> Hmm.. true.. so have a sh
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 complex?
On 09-Aug-99 Alex Zepeda wrote:
> Why that complex? Couldn't I just drop in a small script using awk and
> sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a
> small C program would suffice if scripting isn't your cup of tea.
Hmm.. true.. so have a shell script to write t
On Sun, 8 Aug 1999, Mike Smith wrote:
> > 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 i
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
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 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, an
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 t
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 th
> 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
>
According to Cameron Grant:
> the list of supported cards is as for luigi's driver, with the addition of a
> couple more mss-clones, and trident 4dwave. there is a part done aureal
Can someone with access to a Sony VAIO Z505S(X) laptop try this ? According to
Sony it is supposed to be MSS compat
53 matches
Mail list logo
