On Mon, May 11, 2020 at 09:40:30AM -0700, Dirk Praet wrote:
> Hi Matthieu,
> 
> It would seem I'm a bit (too) late to this party. In short: I'm running a
> high security environment leveraging the combined power of contemporary
> OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all
> kinds of modern BIOS/EFI/processor "management" technology. My recent
> upgrade to 6.6 has crippled several machines using the Trident video
> chipset, which I then found out was removed from both the 6.6 binary
> distribution and the Xenocara tree. Which begs the following questions:
> 
> - Is it possible to bring the Trident-module back ?

No. At least not in the OpenBSD supported tree. You can still try to
get the sources out of CVS's Attic and build it for yourself but I'm
not sure if it will compile against X server 1.20.8.

> - If not, is there any (documented) way to still get X to work on the
> affected (laptop) machines using a framebuffer or other module, blacklisting
> in some way the Trident module which Xorg detects as the chipset in use but
> then bails out on because it is no longer there ?

You can try to use the xf86-video-vesa driver, but it's main
limitation is that it only supports graphics modes that are hard-coded
in the machine's video BIOS. And laptops from that ERA often didn't
even bother to provide a video mode that matches the native resolution
of their panel.

> - Is the removal of additional graphics modules in the future not
> effectively rendering the i386 port useless for anything else than pure CLI,
> router or headless systems, and, shouldn't , in that case, an explicit
> warning be added to release notes/installer/sysupgrade ?

Too late unfortunatly. 6.6 was release 6 month ago.

-- 
Matthieu Herrb

Reply via email to