On Sun, Dec 13, 2015 at 09:43:11PM -0500, Amelia A Lewis wrote:
Heyo.
dmesg attached at end of email. Short version: I've got an Intel
D2500CCE mini-ITX board (Atom 2500; Atom D2000/N2000 Video; DVI and VGA
outputs; attached to DVI; driving an Apple Cinema Display). The machine
is mostly to be configured as a home (and work-from-home)
router/firewall, so virtual terminal only is fine, but I also wanted to
experiment with X figuring that I might bring some other machines up on
OpenBSD. I'm running 5.8 installed from CD, AMD64, multiprocessor
(matching the CPU).
My problem: I start X (startx), and it comes up fine (well, it hates
the Intel chipset, I think, but it comes up VESA, which is good enough
for getting on with), but it clobbers the virtual terminals. That is,
if I Ctrl-Alt-F1 (or -F2, etc.) from the X session, I have a "black"
screen (it's more a dark gray: there's some power in, because if that
display is up when I reboot, the change to no power is noticeable). The
same is true for all the virtual consoles if I quit X (from the menu,
or via Ctrl-Alt-Bksp, or ssh in and kill it by PID).
I haven't seen this happen on OpenBSD for some time, probably because
all of our hardware is now supported directly by the Intel driver.
However, when we had 5.1 installed on a machine with a, (then fairly new),
Ivybridge chipset, there was no support in the Intel driver, and running
with VESA we experienced the same problem - switching back to 80x25
text mode was impossible after starting X.
As far as I remember, the code is based on stuff from Linux, where there
is typically no return to text mode after switching to the graphical
console. I thought that that had been resolved, but our Ivybridge
hardware gained native support in the next release and worked perfectly.
From 5.4 onwards it gained support for the graphical console, so there
was never a return to 80x25 text mode anyway.
(Unfortunately, 5.5 onwards crippled the scrolling performance of the
graphics console due to the removal of a speedup hack that had been
working perfectly on our hardware, and was never put back).
Getting your board natively recognised and supported by the Intel driver
will almost certainly solve your problem.
I don't see mentions of exactly this on OpenBSD lists (MARC: misc,
tech, bugs), or googling, but I might not have come up with the right
search terms, so if there's an easy/obvious answer, please let me know,
okay?
I think the discussion must have been all off-list, because I certainly
spoke to other people with the same problem at the time, but can't find
anything in the archives now.
--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com
