> MD> The depth in X is independent from the one in console (at
> MD> least if the fbdev can change modes, which seems to be the
> MD> case with yours). Have you tried depth 8 in console? This is
> MD> recommended, as the console has only 16 colors anyway.
>
> I tried this, and, ye
> "MD" == Michel Dänzer <[EMAIL PROTECTED]> writes:
> "HK" == Hartmut Koptein
HK> BTW: add this to your script:
HK> # fbset --all 1024x768-75 ${FBSET} -a -x -depth 16 1152x864-80
HK>
HK> /etc/init.d/gpm restart
HK>
HK> echo "done."
Me> I think Hartmut meant
[...]
>>So there's no way to format diskettes on a PowerMac system? That
>>seems wrong
>
>is there any reason to not just do:
>
>dd if=/dev/zero of=/dev/fd0 bs=512 count=2880
IIRC this won't actually format the disk, it'll just zero all the data in an
existing format. I don't think this woul
[...]
>This is wrong. The most recent rant by Linus on the topic is available
>in a recent Kernel Traffic newsletter.
Mmm. I stand corrected. I'll look it up.
--
+- David Given ---McQ-+ "Hydrogen fusion, the sun makes shine
| Work: [EMAIL PROTECTED] | Vascular pressure mak
--- "C.M. Connelly" <[EMAIL PROTECTED]> wrote:
>HK> BTW: add this to your script:
>
>HK> # fbset --all 1024x768-75
>HK> ${FBSET} -a -x -depth 16 1152x864-80
>HK>
>HK> /etc/init.d/gpm restart
>HK>
>HK> echo "done."
>
> I think Hartmut meant gdm here, rather than g
On 6/1/2000 C.M. Connelly wrote:
So there's no way to format diskettes on a PowerMac system? That
seems wrong
is there any reason to not just do:
dd if=/dev/zero of=/dev/fd0 bs=512 count=2880
and to do an extra read verify:
cat /dev/fd0 > /dev/null
then:
mke2fs /dev/fd0
works pretty
(I'm going to do a mass reply here -- please bear with me. Also,
thanks for the responses!)
GU> Geert Uytterhoeven <[EMAIL PROTECTED]>
HK> [EMAIL PROTECTED] (Hartmut Koptein)
KP> Kevin Puetz <[EMAIL PROTECTED]>
MD> Michel "Dänzer" <[EMAIL PROTECTED]>
NO> Nathan Olsen <[EMAIL PROTECTED]>
1. gdm
On Thu, Jan 06, 2000 at 08:06:08AM -0500, Buddha Buck wrote:
> His rational is that /usr/include/linux headers are intended for
> userspace, so glibc had better know what they are. Userspace programs
> don't interact with the kernel directly, but go through glibc. The
> kernel headers are for
On Thu, 6 Jan 2000, Kevin Puetz wrote:
> [EMAIL PROTECTED] said:
> > To compile the kernel itself, you don't need the symlinks. The
> > Makefiles are set up in such a way that they always use the includes
> > in the kernel source tree.
>
> Hmm. As I said, this fixed some warnings, as well as some
[EMAIL PROTECTED] said:
> To compile the kernel itself, you don't need the symlinks. The
> Makefiles are set up in such a way that they always use the includes
> in the kernel source tree.
Hmm. As I said, this fixed some warnings, as well as some of the fatal errors
in the compile. If the kerne
> [...]
> >Hmm... well, doing it fixed several build errors and numerous warnings in
> >the
> >USB drivers (due to changes in which headers include which other headers).
> >Oh
> >well, maybe it's just the funky back-ported USB driver that incorrectly
> >references the system headers. How else
> There's a seperate kernel-headers package which installs all the exported
> headers into /usr/include/linux. Quite a lot of glibc relies on these at the
no, /usr/include/linux is not a sym-link and it comes from the glibc package.
The 'seperate kernel-headers package' is to be installed in /u
[...]
>Hmm... well, doing it fixed several build errors and numerous warnings in the
>USB drivers (due to changes in which headers include which other headers). Oh
>well, maybe it's just the funky back-ported USB driver that incorrectly
>references the system headers. How else am I supposed to k
On Wed, 5 Jan 2000, Kevin Puetz wrote:
> Also, Debian for some reason does not have /usr/include/linux a symlink into
> the kernel source (linux/include/linux). You'll also have to fix that for the
> kernel to build correctly.
To compile the kernel itself, you don't need the symlinks. The Makefi
At 10:11 -0600 2000-01-05, Kevin Puetz wrote:
>Also, Debian for some reason does not have /usr/include/linux a symlink into
>the kernel source (linux/include/linux). You'll also have to fix that for the
>kernel to build correctly.
That is false, /usr/include/linux has nothing whatsoever to do with
On 5/1/2000 Kevin Puetz wrote:
Hmm... well, doing it fixed several build errors and numerous warnings in the
USB drivers (due to changes in which headers include which other headers). Oh
well, maybe it's just the funky back-ported USB driver that incorrectly
references the system headers. How el
[EMAIL PROTECTED] said:
> >Also, Debian for some reason does not have /usr/include/linux a
> symlink into >the kernel source (linux/include/linux). You'll also
> have to fix that for the >kernel to build correctly.
> no you don't in fact that symlink is no longer correct, go read the
> kernel lis
On 5/1/2000 Kevin Puetz wrote:
Also, Debian for some reason does not have /usr/include/linux a symlink into
the kernel source (linux/include/linux). You'll also have to fix that for the
kernel to build correctly.
no you don't in fact that symlink is no longer correct, go read the
kernel list
I got it to compile by adding #include to the file that fails, but it
had the keymap from hell (and I couldn't figure out which keymap that was).
i386/qwerty/defmap was close and made the letters work, but other things were
not right :-(
Also, Debian for some reason does not have /usr/include/
--- Hartmut Koptein <[EMAIL PROTECTED]> wrote:
> > 1. gdm locks up the keyboard when started at boot time.
> >
> >X starts, gdm comes up, the mouse works, but you can't type.
> >Which also means you can't switch to a virtual terminal to stop
> >and restart gdm. (Luckily we have thr
--- "C.M. Connelly" <[EMAIL PROTECTED]> wrote:
>When my machine starts up, the text is red on a black screen.
>We run fbset from a script in /etc/rc.boot to correct this
>problem. The text turns to white on black (hooray), but the
>cursor is invisible.
This sounds like a frameb
On Tue, 4 Jan 2000, C.M. Connelly wrote:
> 1. gdm locks up the keyboard when started at boot time.
>
>X starts, gdm comes up, the mouse works, but you can't type.
>Which also means you can't switch to a virtual terminal to stop
>and restart gdm. (Luckily we have three Unix machines in
>1. gdm locks up the keyboard when started at boot time.
>
> X starts, gdm comes up, the mouse works, but you can't type.
> Which also means you can't switch to a virtual terminal to stop
> and restart gdm. (Luckily we have three Unix machines in our
> house, so it's only annoying to have
> Before I file more bug reports, I thought I'd see whether other
> people are having the same issues I'm having.
Wow, many problems :-)
> 1. gdm locks up the keyboard when started at boot time.
>
>X starts, gdm comes up, the mouse works, but you can't type.
>Which also means you can't s
24 matches
Mail list logo
