Re: headless glass console looses colours on reboot
On 2015-04-23 Thu 08:11 AM |, Nick Holland wrote: On 04/23/15 04:34, Craig Skinner wrote: I haven't seen this in a while (and I'm trusting my memory more than I should), but on some older systems, back in the day of monochrome VGA monitors, the monochrome monitor only connected to the green video line. If the card saw no load on the red and blue lines, it would assume a monochrome monitor, and operate in monochrome mode only. I do recall having soldered a few 75ohm resistors in a mechanical KVM switch box to persuade the video card that there really was a monitor attached when there wasn't. Smart thinking. No idea if that could be reset in software. And it's been a loong time since I've seen (or noticed?) this behavior, so I suspect it isn't a common issue now. To be honest, I can't say if it is due to modern video cards being different, modern KVM boxes being smarter, the almost complete elimination of monochrome monitors, or the fact that when I run text, I don't care about color. Is the kernel behaviour different on boot with/without a monitor present? On new DRM capable cards, yes. And, looking at your dmesg ... oh wait, you haven't provided us one. http://marc.info/?l=openbsd-miscm=142952516106084w=2 Thanks. -- A bachelor is a selfish, undeserving guy who has cheated some woman out of a divorce. -- Don Quinn
Re: headless glass console looses colours on reboot
On 2015-04-20 Mon 11:18 AM |, Craig Skinner wrote: OK folks, Same results on a 3rd box with 5.6 release. Here's info on what various termcap entries produce: $ grep ^ttyC /etc/ttys | grep on$ ttyC0 /usr/libexec/getty std.9600 vt220 on ttyC1 /usr/libexec/getty std.9600 pccon on ttyC2 /usr/libexec/getty std.9600 pcvt25-coloron ttyC3 /usr/libexec/getty std.9600 wsvt25m on .--. |console has colours | | when monitor connected: | .---+---+-|-+| | tty | printenv TERM | tput colors | before boot | after boot | |---|---|-|-|| | ttyC0 | vt220 | -1 | no | no | |---|---|-|-|| | ttyC1 | pccon | 8 | yes | no | |---|---|-|-|| | ttyC2 | pcvt25-color | 8 | yes | no | |---|---|-|-|| | ttyC3 | wsvt25m | 8 | yes | no | '---+---+-+-+' Is there something in the boot process that enables console colours if a monitor is connected? Is the kernel behaviour different on boot with/without a monitor present? Cheers. -- I'd rather have a bottle in front of me than a frontal lobotomy.
Re: headless glass console looses colours on reboot
On 04/23/15 04:34, Craig Skinner wrote: ... Is there something in the boot process that enables console colours if a monitor is connected? on some video cards, yes. I haven't seen this in a while (and I'm trusting my memory more than I should), but on some older systems, back in the day of monochrome VGA monitors, the monochrome monitor only connected to the green video line. If the card saw no load on the red and blue lines, it would assume a monochrome monitor, and operate in monochrome mode only. I do recall having soldered a few 75ohm resistors in a mechanical KVM switch box to persuade the video card that there really was a monitor attached when there wasn't. No idea if that could be reset in software. And it's been a loong time since I've seen (or noticed?) this behavior, so I suspect it isn't a common issue now. To be honest, I can't say if it is due to modern video cards being different, modern KVM boxes being smarter, the almost complete elimination of monochrome monitors, or the fact that when I run text, I don't care about color. Is the kernel behaviour different on boot with/without a monitor present? On new DRM capable cards, yes. And, looking at your dmesg ... oh wait, you haven't provided us one. Nick.
Re: headless glass console looses colours on reboot
OK folks, Same results on a 3rd box with 5.6 release. This machine's dmesg below, if that's of any relevance. On 2015-04-10 Fri 14:12 PM |, Craig Skinner wrote: 2 x i386 boxes, each with 2 serial cables cross connected from com1 to com0 on his neighbour. Normally used without monitor, nor keyboard. When ssh'ing, colours work fine (man pages, vim, mutt, lynx, etc.) After connecting a spare VGA CRT monitor logging in locally, there were no colours. But when I rebooted with the monitor keyboard connected, colours were back. When I connect the monitor keyboard to the other box reboot over the serial line, then replug the monitor back into the origianl box, colours are gone, until I reboot it with the monitor connected (even though the boot output is over com0 to the other machine). Setup: $ uname -srvm OpenBSD 5.6 GENERIC#274 i386 $ cat /etc/boot.conf stty com0 9600 set tty com0 $ ls -l /etc/boot.conf -r--r--r-- 1 root wheel 28 Aug 25 2007 /etc/boot.conf $ grep ^ttyC /etc/ttys | grep on$ ttyC0 /usr/libexec/getty std.9600 pccon on ttyC1 /usr/libexec/getty std.9600 pccon on ttyC2 /usr/libexec/getty std.9600 pccon on ttyC3 /usr/libexec/getty std.9600 pccon on $ grep -v ^# /etc/wsconsctl.conf keyboard.encoding=uk # Use United Kingdom keyboard encoding display.vblank=on # Enable vertical sync blank for screen burner display.screen_off=30 # Set screen burner timeout to 5 minutes display.msact=off # Disable screen unburn with mouse display.kbdact=on # Restore screen on keyboard input display.outact=off# Restore screen on display output $ printenv TERM pccon $ tput colors 8 Any ideas on how to have console colours when connecting a monitor after booting? OpenBSD 5.6 (GENERIC) #274: Fri Aug 8 00:05:13 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 349 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF real mem = 133644288 (127MB) avail mem = 119042048 (113MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 07/19/99, BIOS32 rev. 0 @ 0xfd861, SMBIOS rev. 2.1 @ 0xf7d95 (32 entries) bios0: vendor IBM version PDKT27AUS date 07/19/99 bios0: IBM 6275500 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP acpi0: wakeup devices PCI0(S5) PS2K(S1) PS2M(S1) COM1(S5) COM2(S5) USB0(S1) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0: (uniprocessor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xec00, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 1 function 0 S3 Trio3D AGP rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) piixpcib0 at pci0 dev 2 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 2 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: Maxtor 90320D2 wd0: 16-sector PIO, LBA, 3079MB, 6306048 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) uhci0 at pci0 dev 2 function 2 Intel 82371AB USB rev 0x01: irq 10 piixpm0 at pci0 dev 2 function 3 Intel 82371AB Power rev 0x02: SMI iic0 at piixpm0 spdmem0 at iic0 addr 0x50: 32MB SDRAM non-parity PC100CL3 spdmem1 at iic0 addr 0x51: 32MB SDRAM non-parity PC100CL3 spdmem2 at iic0 addr 0x52: 64MB SDRAM non-parity PC100CL3 spdmem3 at iic0 addr 0x55: 1GB DDR2 SDRAM PC2-5000CL4 xl0 at pci0 dev 16 function 0 3Com 3c905B 100Base-TX rev 0x64: irq 15, address 00:50:04:62:35:f8 bmtphy0 at xl0 phy 24: 3C905B internal PHY, rev. 0 xl1 at pci0 dev 18 function 0 3Com 3c905B 100Base-TX rev 0x30: irq 11, address 00:10:5a:f1:9d:b1 exphy0 at xl1 phy 24: 3Com internal media interface isa0 at piixpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 vscsi0 at root scsibus1 at vscsi0: 256 targets
Re: headless glass console looses colours on reboot
On 04/10/15 20:19, Craig Skinner wrote: On 2015-04-10 Fri 17:06 PM |, Alexei Malinin wrote: ttyC0 /usr/libexec/getty std.9600 pccon on I use this: ttyC0 /usr/libexec/getty Pc pccon on secure ^^ Thanks Alexei. I've changed to that non-parity 9600 baud entry. No change to missing colours on boot without monitor present. Hello, Craig. Could you try the following (vga(4)): /usr/sbin/wsconscfg -d -F 1 /usr/sbin/wsconscfg -t 80x25bf -e vt100 1 and compare the results for ttyC0 (16 different colors by default) ttyC1 (8 colors now)? -- Alexei
Re: headless glass console looses colours on reboot
On 2015-04-14 Tue 14:56 PM |, Alexei Malinin wrote: No change to missing colours on boot without monitor present. Hello, Craig. Could you try the following (vga(4)): /usr/sbin/wsconscfg -d -F 1 /usr/sbin/wsconscfg -t 80x25bf -e vt100 1 and compare the results for ttyC0 (16 different colors by default) ttyC1 (8 colors now)? Hi Alexei, 1) Machine booted with monitor present, colours at glass consoles. 2) Remove monitor reboot over serial line. 3) Connect monitor, no colours at glass console (Ctrl+Alt+F1-4) $ tput colors 8 4) On ttyC2 do: $ cat /tmp/am wsconscfg -d -F 1 wsconscfg -t 80x25 -e vt100 1 $ sudo ksh /tmp/am (80x25bf gave errors about ttyC1 device not configured) 5) Login on ttyC1 (Ctrl-Alt-F2), no colours $ tput colors 8 6) Reboot it. 7) Login on ttyC1 (Ctrl-Alt-F2), has colours again. Could it be a hardware thing about VGA port resistance when it boots? Thanks. -- I generally avoid temptation unless I can't resist it. -- Mae West
Re: headless glass console looses colours on reboot
On 2015-04-10 Fri 14:12 PM |, Craig Skinner wrote: 2 x i386 boxes, each with 2 serial cables cross connected from com1 to com0 on his neighbour. Normally used without monitor, nor keyboard. When ssh'ing, colours work fine (man pages, vim, mutt, lynx, etc.) After connecting a spare VGA CRT monitor logging in locally, there were no colours. But when I rebooted with the monitor keyboard connected, colours were back. When I connect the monitor keyboard to the other box reboot over the serial line, then replug the monitor back into the origianl box, colours are gone, until I reboot it with the monitor connected (even though the boot output is over com0 to the other machine). $ grep -v ^# /etc/wsconsctl.conf keyboard.encoding=uk # Use United Kingdom keyboard encoding display.vblank=on # Enable vertical sync blank for screen burner display.screen_off=30 # Set screen burner timeout to 5 minutes display.msact=off # Disable screen unburn with mouse display.kbdact=on # Restore screen on keyboard input display.outact=off# Restore screen on display output Any ideas on how to have console colours when connecting a monitor after booting? Would changing any of these help? $ sudo wsconsctl | fgrep display display.type=vga-pci display.emulations=vt100 display.screentypes=80x25,80x25bf,80x40,80x40bf,80x50,80x50bf display.focus=3 display.screen_on=250 display.screen_off=30 display.vblank=on display.kbdact=on display.msact=off display.outact=off -- Time is nature's way of making sure that everything doesn't happen at once.
