Re: Removing old video drivers

2020-05-20 Thread Dirk Praet
OpenBSD's model and philosophy match both my requirements and expectations
perfectly, Theo. I'm just not too fond of stuff unexpectedly breaking -
admittedly because I missed out on this specific thread -, but for which
Stuart's tip is an excellent mitigation indeed. 

Kind regards,

Dirk



--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html



Re: Removing old video drivers

2020-05-19 Thread Theo de Raadt
Stuart Henderson  wrote:

> On 2020/05/19 14:23, Dirk Praet wrote:
> > A manual xorg config with the vesa driver brought X back to life, but not
> > until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
> > reply, Matthieu. I do hope 6.7 doesn't come with similar surprises, though 
> 
> Run -current between releases if you don't want to see surprises in a release.

Yes, that's the best way!

Another way is if your expectations don't match OpenBSD, there are many
other choices out there.



Re: Removing old video drivers

2020-05-19 Thread Stuart Henderson
On 2020/05/19 14:23, Dirk Praet wrote:
> A manual xorg config with the vesa driver brought X back to life, but not
> until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
> reply, Matthieu. I do hope 6.7 doesn't come with similar surprises, though 

Run -current between releases if you don't want to see surprises in a release.



Re: Removing old video drivers

2020-05-19 Thread Dirk Praet
A manual xorg config with the vesa driver brought X back to life, but not
until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
reply, Matthieu. I do hope 6.7 doesn't come with similar surprises, though 



--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html



Re: Removing old video drivers

2020-05-12 Thread Matthieu Herrb
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



Re: Removing old video drivers

2020-05-11 Thread Dirk Praet
Touché.

I should probably rephrase this as "operating a slightly less insecure
environment as compared to running vanilla Windows 10 on contemporary COTS
hardware". And finding it really hard to throw away perfectly good hardware
that suited the intended purposes really well until Matthieu unfortunately
retired a series of old video drivers. For reasons which, for the record, I
do understand. 

Keep up the good work.

Dirk



--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html



Re: Removing old video drivers

2020-05-11 Thread Theo de Raadt
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
  ^

I'm glad this delusion is not highly infectious.



Re: Removing old video drivers

2020-05-11 Thread Dirk Praet
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 ?
- 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 ?
- 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 ?

Kind regards,

Dirk

PS It would seem these are bad times for anything "Trident". I recently also
had to let go of several FreeBSD Trident (successor of PC-BSD/TrueOS) VM's
as its developers suddenly decided to ditch FreeBSD in favor of Linux.



--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html



Re: Removing old video drivers

2019-05-11 Thread Matthieu Herrb
On Mon, Apr 22, 2019 at 06:47:23PM +0200, Matthieu Herrb wrote:
> Hi,
> 
> In xenocara, we still build a number of video drivers for very old
> hardware, that is mostly useless. For AGP, I don't have a working
> motherboard to test the cards I still have.
> I also still have a few PCI cards for some of them, but most of them
> are dead, or don't work as primary display with modern BIOSes.
> 
> And most important, none of these old cards has enough RAM to run any
> kind of modern 16 or 32 bpp X at a decent resolution. (And the xserver
> version 1.20 has dropped support for 24 bits per pixel modes).
> 
> So rather that try to blindly fix the issues with these drivers I'd
> rather remove them. This is the list of candidates for removing.
> 

Here is the patch that implements the proposed removals. I've kept
xf86-video-savage for now, since they made cards with decent amounts
of RAM that are still usable.

ok ?

Index: Makefile
===
RCS file: /cvs/OpenBSD/xenocara/driver/Makefile,v
retrieving revision 1.73
diff -u -r1.73 Makefile
--- Makefile16 Apr 2019 02:06:30 -  1.73
+++ Makefile11 May 2019 07:56:17 -
@@ -44,16 +44,14 @@
 VIDEO_DRV_alpha=
 
 VIDEO_DRV_amd64= \
-   xf86-video-amdgpu xf86-video-apm xf86-video-ark \
+   xf86-video-amdgpu xf86-video-apm \
xf86-video-ast xf86-video-ati \
-   xf86-video-chips xf86-video-cirrus xf86-video-dummy xf86-video-glint \
-   xf86-video-i128 xf86-video-intel xf86-video-mach64 \
-   xf86-video-mga xf86-video-neomagic \
+   xf86-video-cirrus xf86-video-dummy \
+   xf86-video-intel xf86-video-mach64 \
+   xf86-video-mga \
xf86-video-nv xf86-video-openchrome xf86-video-r128 \
-   xf86-video-rendition xf86-video-s3 \
-   xf86-video-s3virge xf86-video-savage xf86-video-siliconmotion \
-   xf86-video-sis xf86-video-tdfx xf86-video-trident \
-   xf86-video-tseng xf86-video-vesa xf86-video-vmware \
+   xf86-video-savage xf86-video-siliconmotion \
+   xf86-video-vesa xf86-video-vmware \
xf86-video-wsfb xf86-video-wsudl
 
 VIDEO_DRV_arm64= \
@@ -68,9 +66,7 @@
 
 VIDEO_DRV_i386= \
${VIDEO_DRV_amd64} \
-   xf86-video-geode \
-   xf86-video-i740 \
-   xf86-video-voodoo
+   xf86-video-geode
 
 VIDEO_DRV_landisk=
 
@@ -89,7 +85,7 @@
 VIDEO_DRV_sgi= xf86-video-wsfb
 
 VIDEO_DRV_sparc64= \
-   xf86-video-ati xf86-video-mach64 xf86-video-r128 xf86-video-glint \
+   xf86-video-ati xf86-video-mach64 xf86-video-r128 \
xf86-video-sunffb \
xf86-video-wildcatfb xf86-video-wsfb
 

-- 
Matthieu Herrb



Re: Removing old video drivers

2019-04-23 Thread Craig Skinner
On Tue, 23 Apr 2019 11:55:01 +0200 Matthieu Herrb wrote:
> If you are actually running X, ...

Not on the old "S3 Trio3D AGP" Pentium II 350MHz machines Matthieu,
(these are used as small servers, some with VGA glass tube screens).




> This is an Intel chipset supported by the current DRM driver. ...

OK.

Cheers!
-- 
Craig Skinner | http://linkd.in/yGqkv7



Re: Removing old video drivers

2019-04-23 Thread Matthieu Herrb
On Tue, Apr 23, 2019 at 10:28:18AM +0100, Craig Skinner wrote:
> On Mon, 22 Apr 2019 18:47:23 +0200 Matthieu Herrb wrote:
> > If you're still using a machine with a graphics card supported by one
> > of these, please speak up, otherwise they are going to be removed:
> 
> Is this a valid way to find out Matthieu?

Hi,

Yes, but it doesn't tell you which X.Org driver is beeing used.
If you are actually running X, A better way is to look in
/var/log/Xorg.0.log

Something like that will print the driver name:
awk -F' ' '/[A-Za-z]+\(0\)/ { print $4 }' /var/log/Xorg.0.log | uniq

(Unfortunatly there is no standard way to query the running X server
for the active video driver(s)...)

I'm interested in the full contents of /var/log/Xorg.0.log if you're
willing to share it. 

> 
> 
> $ grep -i -e vga -e video /var/run/dmesg.boot
> vga1 at pci1 dev 1 function 0 "S3 Trio3D AGP" rev 0x01
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)

This is probably using the s3virge driver, which is on the list of
driver that have issues with the next X server version.

> 
> 
> 
> $ grep -i -e vga -e video /var/run/dmesg.boot
> acpivideo0 at acpi0: IGD0
> acpivout0 at acpivideo0: DD01
> vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x00
> intagp0 at vga1
> inteldrm0 at vga1
> wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
> "Intel Pineview Video" rev 0x00 at pci0 dev 2 function 1 not configured
> uvideo0 at uhub0 port 8 configuration 1 interface 0 "Chicony Corp. Lenovo 
> EasyCamera" rev 2.00/45.42 addr 3
> video0 at uvideo0

This is an intel chipset supported by the current DRM driver. It's not
going away anytime soon.

-- 
Matthieu Herrb



Re: Removing old video drivers

2019-04-23 Thread Craig Skinner
On Mon, 22 Apr 2019 18:47:23 +0200 Matthieu Herrb wrote:
> If you're still using a machine with a graphics card supported by one
> of these, please speak up, otherwise they are going to be removed:

Is this a valid way to find out Matthieu?


$ grep -i -e vga -e video /var/run/dmesg.boot
vga1 at pci1 dev 1 function 0 "S3 Trio3D AGP" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)



$ grep -i -e vga -e video /var/run/dmesg.boot
acpivideo0 at acpi0: IGD0
acpivout0 at acpivideo0: DD01
vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x00
intagp0 at vga1
inteldrm0 at vga1
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
"Intel Pineview Video" rev 0x00 at pci0 dev 2 function 1 not configured
uvideo0 at uhub0 port 8 configuration 1 interface 0 "Chicony Corp. Lenovo 
EasyCamera" rev 2.00/45.42 addr 3
video0 at uvideo0


Cheers,
-- 
Craig Skinner | http://linkd.in/yGqkv7



Re: Removing old video drivers

2019-04-22 Thread Tim Chase
(sorry this isn't coming with In-Reply-To/References headers as I
read Matthieu's post on marc.info via Mastodon)

> So rather that try to blindly fix the issues with these drivers I'd
> rather remove them. This is the list of candidates for removing.
> 
> If you're still using a machine with a graphics card supported by
> one of these, please speak up, otherwise they are going to be
> removed:
> 
> xf86-video-s3
> xf86-video-s3virge

I still have one i386 OpenBSD machine with an S3 card (running 6.4,
usually tracking releases, so it'll get upgraded to 6.5 here shortly).
I'm not positive if this is one of the two S3 drivers on the chopping
block, but I at least wanted to wave a "yes, I'm still using an S3 card,
albeit lightly" from the back row.

  $ dmesg |  grep vga
  vga1 at pci1 dev 0 function 0 "S3 Twister" rev 0x02
  wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)

  $ grep -i s3 /var/log/Xorg.0.log
  [   164.119] (II) SAVAGE: driver (version 2.3.9) for S3 Savage chipsets: 
Savage4,
  [   164.279] (II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. Twister BIOS
  [   164.279] (II) SAVAGE(0): VESA VBE OEM Vendor: S3 Incorporated.
  [   165.680] (II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. Twister BIOS
  [   165.680] (II) SAVAGE(0): VESA VBE OEM Vendor: S3 Incorporated.

Please let me know if you need any further information. 

And push come to shove, I can retire the GUI on this machine, as I use
it largely out of nostalgia as it was my first 100% OpenBSD machine.

Thanks,

-Tim






Removing old video drivers

2019-04-22 Thread Matthieu Herrb
Hi,

In xenocara, we still build a number of video drivers for very old
hardware, that is mostly useless. For AGP, I don't have a working
motherboard to test the cards I still have.
I also still have a few PCI cards for some of them, but most of them
are dead, or don't work as primary display with modern BIOSes.

And most important, none of these old cards has enough RAM to run any
kind of modern 16 or 32 bpp X at a decent resolution. (And the xserver
version 1.20 has dropped support for 24 bits per pixel modes).

So rather that try to blindly fix the issues with these drivers I'd
rather remove them. This is the list of candidates for removing.

If you're still using a machine with a graphics card supported by one
of these, please speak up, otherwise they are going to be removed:

xf86-video-ark
xf86-video-chips
xf86-video-glint
xf86-video-i128
xf86-video-i740
xf86-video-neomagic
xf86-video-rendition
xf86-video-s3
xf86-video-s3virge
xf86-video-savage
xf86-video-sis
xf86-video-tdfx
xf86-video-trident
xf86-video-tseng
xf86-video-voodoo

For now, we would keep the following non drm/kms drivers:

xf86-video-ast
xf86-video-cirrus
xf86-video-dummy
xf86-video-mach64
xf86-video-mga
xf86-video-nv
xf86-video-openchrome
xf86-video-r128
xf86-video-siliconmotion
xf86-video-vesa
xf86-video-vmware
xf86-video-wsfb
xf86-video-wsudl

and on i386 only:

xf86-video-geode

--
Matthieu Herrb