Re: [slackware-sparcdevel] New updates, progress with X

From: David Cantrell (david@slackware.com)
Date: Tue Nov 28 2000 - 02:21:42 PST


On Tue, Nov 28, 2000 at 12:44:43AM -0600, Phil Howard wrote:
> David Cantrell wrote:
>
> > On Tue, Nov 28, 2000 at 12:08:31AM -0600, Phil Howard wrote:
> > > David Cantrell wrote:
> > >
> > > > Right now I'm working on getting X to go on the new Ultra 60. I've
> > > > discovered quite a few interesting things. Like you don't even need an
> > > > XF86Config file if you use the Xsun, XsunMono, or Xsun24 servers. Plus
> > >
> > > But that also means no opportunity to configure things that would be
> > > configured in there. That's what I ran into back when I was running
> > > Redhat on a Sparc 5. I wanted to change the mouse configuration. But
> > > there was no config file even being read in to do this.
> >
> > That's true, but with the way those devices work is they boot up in exactly
> > one mode and color depth. To change that, you use fbcontrol, or something
> > like that under Solaris and reboot. There are similar tools under Linux to
> > set the framebuffer mode and color depth.
> >
> > As for the mouse, as far as I know it's an on/off type setting. If anyone
> > knows otherwise, do tell.
>
> There are other things like font paths and such.

Oooh...good point, back to the drawing board. :)

...but wait, there are alternatives. You could have an xinitrc file run xset
commands to create the font path. Bad example, I know, but there are other ways
to go about the non-video card non-monitor settings. Perhaps this would be a
better route to take than XF86Config?

> > There's plenty of stuff that needs testing that's not under X. The serial
> > console problem is definitely something that needs fixing. It's something
> > that I'm working while other stuff builds, but I can't seem to figure out
> > the best way to handle that. I suppose it could always spawn a getty on
> > /dev/ttyS0 and maybe /dev/ttyS1, but that could lead to other issues.
> > Know of a way to detect whether there's a real console or just a serial
> > console?
>
> I have an Intel ISP1100 with a serial console (BIOS also accessed via the
> serial console. My lilo.conf for it looks like:
>
> image=/boot/linux-2.4.0-test10-00
> label=linux
> append="ide0=dma console=tty0 console=ttyS1,9600"
> root=/dev/hda2
> read-only
>
> Then my inittab has:
>
> # define serial port logins
> s1:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
> s2:12345:respawn:/sbin/agetty 9600 ttyS1 vt100
>
> To bring up a login prompt on the serial port. I'd recommend even the Intel
> version of Slackware have this in the install CD so that it's easier to do
> an install on the ISP1100 if there's no video card in the machine. Since
> the serial port may be unsafe on other hardware, there should be a separate
> boot option to choose "serial" instead of the default "linux" for serial
> ports.
>
> Back to Sparc. A serial port, AFAIK, can be assumed to be present on a Sun
> Sparc machine, so I think it is safe. What I'm not sure about is what will
> happen if the video card is absent, and virtual consoles are also used, as
> in console=tty0 and inittab entries. So even here, it may be best to have
> a separe boot option named "serial" which boots with kernel parameters to
> use the serial console.

I'll bring that up...the serial console for Intel release. For the SPARC,
I think it may be safe to just always spawn extra gettys on the serial
ports. The regular console gettys should be able to exist too, even with
no real console. I'll try this out tomorrow.

--
David Cantrell | david@slackware.com                                      *
        KG6CII | Slackware Linux Project



This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT