xf86 Driver Removals in Current

chrisretusn · 08-09-2022, 05:36 AM

Per

Code:

Mon Aug 8 23:29:31 UTC 2022
Hey folks, here's that graphics stack upgrade that you've been waiting for!
After looking at what drivers are currently shipped by other projects, I took
an axe to the driver list. Some of the removed drivers will still compile even
though they are abandoned, and some of the others are still getting git commits
(which allows *some* of them to compile). The removed stuff mostly looks
obsolete to me (we really can't support ancient hardware forever). But if you
think I've gone too far with any of these removals, please make or contribute
to a thread about it on LQ and I'll take any comments there into consideration.

I'll start.

x/xf86-video-vboxvideo-1.0.0-x86_64-5.txz: Removed.
This is very useful in a VirtualBox virtual machine IF you are not installing the VirtualBox Guess Additions. It's not really needed IF you plan to use the CLI environment, but with X in is needed for the GUI to properly work.

Perhaps put it in 'extra' vice back in to the base 'x' set.

ppr:kut · 08-09-2022, 08:42 AM

Quote:

Originally Posted by chrisretusn

x/xf86-video-vboxvideo-1.0.0-x86_64-5.txz: Removed.
This is very useful in a VirtualBox virtual machine IF you are not installing the VirtualBox Guess Additions. It's not really needed IF you plan to use the CLI environment, but with X in is needed for the GUI to properly work.

Perhaps put it in 'extra' vice back in to the base 'x' set.

That's not really true. VirtualBox's default graphics adapter now is "VMSVGA", which uses the vmware driver and works just fine without guest additions. You will need guest additions to get automatic resizing though. "VBoxVGA", which was using the virtualbox driver, is deprecated.

chrisretusn · 08-09-2022, 09:58 AM

Quote:

Originally Posted by ppr:kut

That's not really true. VirtualBox's default graphics adapter now is "VMSVGA", which uses the vmware driver and works just fine without guest additions. You will need guest additions to get automatic resizing though. "VBoxVGA", which was using the virtualbox driver, is deprecated.

Before I bothered to post this I tested it against a Slackware64-current fully upgraded installation. This is a clean system, no third party. Logged in as a user, ran startx to start KDE Plasma. The desktop image does not show, you can't even set the desktop to a single color. There we a few other issues as well. I first attempted this as root, the result a lock up.

After installing xf86-video-vboxvideo-1.0.0-x86_64-5.txz, all issues went away. I know what the default graphics adapter is set to. Setting to VBoxVGA will cause issues. If been there tried that.

I have two VM's one for Slackware64-current, one for Slackware64-15.0. Both of the are clean machines, meaning full installation of Slackware, no third party. I choose not to install the Guest Additions in these two machines. They work fine with the previous Slackware provided driver (xf86-video-vboxvideo-1.0.0-x86_64-5.txz) installed.

I do have one machine I use that has Slackware64-current installed, the Guest Additions and some third party programs.

All of these machine are for testing. They run on a Slackware64-current host.

lucabon · 08-10-2022, 07:04 AM

I have some x86 PCs (still in use!!) that have mach64, r128, and mga video cards.
For mach64 and r128, the "ati" driver could be used (but without acceleration), and for Matrox cards the generic "vesa" driver should work, even if without acceleration.

In my opinion, if the drivers compile and/or are actively maintained, maybe it will be better to leave them in the source tree (maybe moving them in "pasture"), otherwise the best choice is to remove them as recently done.

Anyway, if really needed, with Slackware is very simple to re-add the specific driver to the sources and compile it :-)

Luca

LuckyCyborg · 08-10-2022, 09:41 AM

Quote:

Originally Posted by lucabon

I have some x86 PCs (still in use!!) that have mach64, r128, and mga video cards.
For mach64 and r128, the "ati" driver could be used (but without acceleration), and for Matrox cards the generic "vesa" driver should work, even if without acceleration.

In my opinion, if the drivers compile and/or are actively maintained, maybe it will be better to leave them in the source tree (maybe moving them in "pasture"), otherwise the best choice is to remove them as recently done.

Anyway, if really needed, with Slackware is very simple to re-add the specific driver to the sources and compile it :-)

Luca

In fact, the "ati" driver is a dispatcher which call the appropriate driver: mach64, r128 or radeon. So, no "r128" driver presence in system means no r128 support on "ati" driver.

In other hand, I fully agree with our BDFL - even the conservatory Slackware can't support ancient hardware forever.

pee_bee · 08-11-2022, 04:45 AM

Quote:

After looking at what drivers are currently shipped by other projects,

I did a quick comparison between what Slackware Current now supports compared with Debian and Void Linux (for 32-bit i.e. older systems):

Slackware Current Processing xserver_xorg
processing xf86-input-libinput-1.2.1-i586-2.txz
processing xf86-input-wacom-1.1.0-i586-1.txz
processing xf86-video-amdgpu-22.0.0-i586-2.txz
processing xf86-video-ati-20220730_7a6a34af-i586-1.txz
processing xf86-video-dummy-0.4.0-i586-2.txz
processing xf86-video-intel-20210115_31486f40-i686-1.txz
processing xf86-video-nouveau-20220125_29cc528-i586-1.txz
processing xf86-video-openchrome-0.6.0-i586-6.txz
processing xf86-video-vesa-2.5.0-i586-4.txz
processing xf86-video-vmware-20220621_ff5637a-i586-1.txz
processing xorg-server-21.1.4-i586-1.txz

Debian Processing xserver_xorg
processing xserver-xorg-input-aiptek_1.4.1-3_i386.deb
processing xserver-xorg-input-all_7.7+22_i386.deb
processing xserver-xorg-input-elographics_1.4.2-1_i386.deb
processing xserver-xorg-input-evdev_2.10.6-2_i386.deb
processing xserver-xorg-input-joystick_1.6.3-1+b1_i386.deb
processing xserver-xorg-input-libinput_0.30.0-1_i386.deb
processing xserver-xorg-input-mtrack_0.3.1-1+b3_i386.deb
processing xserver-xorg-input-mutouch_1.3.0-2_i386.deb
processing xserver-xorg-input-synaptics_1.9.1-2_i386.deb
processing xserver-xorg-input-wacom_0.34.99.1-1_i386.deb
processing xserver-xorg-input-xwiimote_0.5-1+b3_i386.deb
processing xserver-xorg-video-all_7.7+22_i386.deb
processing xserver-xorg-video-amdgpu_19.1.0-2_i386.deb
processing xserver-xorg-video-ati_19.1.0-2_i386.deb
processing xserver-xorg-video-dummy_0.3.8-1+b1_i386.deb
processing xserver-xorg-video-fbdev_0.5.0-1_i386.deb
processing xserver-xorg-video-intel_2.99.917+git20200714-1+deb11u1_i386.deb
processing xserver-xorg-video-mach64_6.9.6-3_i386.deb
processing xserver-xorg-video-neomagic_1.3.0-2_i386.deb
processing xserver-xorg-video-nouveau_1.0.17-1_i386.deb
processing xserver-xorg-video-openchrome_0.6.0-4_i386.deb
processing xserver-xorg-video-qxl_0.1.5+git20200331-1_i386.deb
processing xserver-xorg-video-r128_6.12.0-2_i386.deb
processing xserver-xorg-video-radeon_19.1.0-2_i386.deb
processing xserver-xorg-video-savage_2.3.9-4_i386.deb
processing xserver-xorg-video-siliconmotion_1.7.9-3_i386.deb
processing xserver-xorg-video-sisusb_0.9.7-2_i386.deb
processing xserver-xorg-video-tdfx_1.5.0-4_i386.deb
processing xserver-xorg-video-trident_1.3.8-2_i386.deb
processing xserver-xorg-video-vesa_2.5.0-1_i386.deb
processing xserver-xorg-video-vmware_13.3.0-3_i386.deb
processing xserver-xorg_7.7+22_i386.deb

Void Linux Processing xserver_xorg
processing xf86-input-joystick-1.6.3_3.i686.xbps
processing xf86-input-libinput-1.2.1_1.i686.xbps
processing xf86-input-mtrack-0.5.0_1.i686.xbps
processing xf86-input-vmmouse-13.1.0_4.i686.xbps
processing xf86-input-wacom-0.40.0_1.i686.xbps
processing xf86-video-amdgpu-22.0.0_1.i686.xbps
processing xf86-video-ati-19.1.0_4.i686.xbps
processing xf86-video-cirrus-1.5.3_9.i686.xbps
processing xf86-video-dummy-0.3.8_4.i686.xbps
processing xf86-video-fbdev-0.5.0_2.i686.xbps
processing xf86-video-intel-2.99.917.20210115_2.i686.xbps
processing xf86-video-mach64-6.9.6_3.i686.xbps
processing xf86-video-mga-2.0.0_3.i686.xbps
processing xf86-video-nouveau-1.0.17_2.i686.xbps
processing xf86-video-openchrome-0.6.0_3.i686.xbps
processing xf86-video-qxl-0.1.5_4.i686.xbps
processing xf86-video-r128-6.12.0_2.i686.xbps
processing xf86-video-sisusb-0.9.7_3.i686.xbps
processing xf86-video-vesa-2.5.0_2.i686.xbps
processing xf86-video-vmware-13.3.0_3.i686.xbps
processing xorg-server-21.1.4_1.i686.xbps

business_kid · 08-11-2022, 05:17 AM

Good point: Slackware is supplying 64bit drivers for input & video which ran exclusively on 32bit machines. The last 32bit generation of cpus was the Pentium 4 IIRC. That went from 2000 to 2008. By 2008 both AMD & Intel had 64bit twin core offerings. By 2007/8 pci was gone, & pcie was in on motherboards.

So the isa/pci driven video cards have no place in a 64bit distro. Can somebody post details of their 64bit box running a 1990s pci video card?

LuckyCyborg · 08-11-2022, 05:19 AM

Quote:

Originally Posted by pee_bee

I did a quick comparison between what Slackware Current now supports compared with Debian and Void Linux (for 32-bit i.e. older systems):

From what I know, our BDFL uses Fedora Linux as reference.

And please, Debian? With its packages patched like hell and which packages are usually obsolete already when they are published? There is a reason why Ubuntu earns its food, you know...

Heck, Ubuntu means: Debian Done Right. Yes, I'm an Ubuntu user since longer time than of Slackware, so I known about what I talk.

LuckyCyborg · 08-11-2022, 05:31 AM

Quote:

Originally Posted by business_kid

Good point: Slackware is supplying 64bit drivers for input & video which ran exclusively on 32bit machines. The last 32bit generation of cpus was the Pentium 4 IIRC. That went from 2000 to 2008. By 2008 both AMD & Intel had 64bit twin core offerings. By 2007/8 pci was gone, & pcie was in on motherboards.

So the isa/pci driven video cards have no place in a 64bit distro. Can somebody post details of their 64bit box running a 1990s pci video card?

Not sure if it's in 1990s range, but there are NVIDIA GeForce 6200 on PCI slot - a friend of mine uses one like this after his high end graphics card committed harakiri and dragged the PCIE x16 slot with it in Afterlife.

BUT, I believe that this particular one is covered by the Nouveau driver.

lucabon · 08-11-2022, 06:37 AM

Quote:

Originally Posted by business_kid

So the isa/pci driven video cards have no place in a 64bit distro. Can somebody post details of their 64bit box running a 1990s pci video card?

I had to repair a PC with broken PCI-Express bus, so I replaced the PCIe video card with a PCI video card (an s3virge, if I well remember). Some current motherboards still have a PCI slot.

Anyway, Slackware has also an official 32bit porting, that could be installed on "ancient" PC. I installed Slackware 15.0 on a Celeron Mendocino (Pentium II) 400 MHz laptop that I currently use (not so much, but I use it), with an ATI 3D Rage LT (mach64) video card.

So, in my opinion, if the driver for ancient/obsolete hardware still compiles and works, I think it will be good to keep it in Slackware.

LuckyCyborg · 08-11-2022, 07:58 AM

Quote:

Originally Posted by lucabon

I had to repair a PC with broken PCI-Express bus, so I replaced the PCIe video card with a PCI video card (an s3virge, if I well remember). Some current motherboards still have a PCI slot.

Anyway, Slackware has also an official 32bit porting, that could be installed on "ancient" PC. I installed Slackware 15.0 on a Celeron Mendocino (Pentium II) 400 MHz laptop that I currently use (not so much, but I use it), with an ATI 3D Rage LT (mach64) video card.

So, in my opinion, if the driver for ancient/obsolete hardware still compiles and works, I think it will be good to keep it in Slackware.

Oh, well...

Honestly, I believed that Slackware 32bit is today supposed to be for systems like I have one too, with a CPU Intel Pentium 4 HT 540J, which is on socket 775, runs at 3.2GHz, BUT it's 32bit only.

https://ark.intel.com/content/www/us...0-mhz-fsb.html

Yes, thanks to Intel and the way it treated at beginning those 64bit features (as premium), there are relative modern (and quite decent) systems, sporting up to 8GB DDR2 800MHz memories, which are 32bit only. Mine one has 4GB and an ATI Radeon HD4350 as graphics card, BUT I've seen similar systems with 8GB, using 4 slots for memories.

However, no offense intended, but expecting from Slackware to support fully a Celeron Mendocino at 400MHz and Mach64 graphics, in this day and age, is well... nuts.

In the end, what the heck you do today with that laptop? It can't even play Youtube videos at 160p.

business_kid · 08-11-2022, 08:59 AM

Quote:

Originally Posted by lucabon

I had to repair a PC with broken PCI-Express bus, so I replaced the PCIe video card with a PCI video card (an s3virge, if I well remember). Some current motherboards still have a PCI slot.

If I interpret that correctly, some post-2007 m/bs may have had a single pci slot, but would you want to slow your video down like that? either way, pci was chipset-dependent, and it's gone.

Quote:

Originally Posted by lucabon

So, in my opinion, if the driver for ancient/obsolete hardware still compiles and works, I think it will be good to keep it in Slackware.

Ancient 32bit video cards of antique value only have no place in a 64bit distro, your memory notwithstanding. You can argue for them in the 32bit version. But you really should have a 25 year old pc to do so. And even then, we're talking about stuff which is wildly outclassed by Raspberry Pi graphics. My days in Electronic Hardware taught me that there's no room for sympathy, and no antiques of value in electronics.

lucabon · 08-11-2022, 11:03 AM

Quote:

Originally Posted by LuckyCyborg

However, no offense intended, expecting from Slackware to support fully a Celeron Mendocino at 400MHz and Mach64 graphics, in this day and age, is well... nuts.

I love Slackware because it does not set any constraint on hardware (except for minimum instruction set, actually i586): if it works, good for you; if not (maybe because too slow due too few memory, etc), clearly you cannot ask for support...
I actually also have some ARM-based "server" (e.g. Marvell Orion @ 500Mhz with 64MB of RAM) and Slackware armv5 porting works flawlessly. Sure, here no graphic card is involved, but the Slackware's simplicity is beyond the support that could be given.

I don't know the amount of effort by Slackware maintainers to keep ancient drivers: if it is only compile the driver (if it still compiles), why not keep them? In the other hand, if "support" means to be sure the drivers work with actual Xorg framework, maybe it is correct to remove them, or maintainers could put the source code in "pasture" so you can [try to] compile, but clearly without any support.

Quote:

Originally Posted by LuckyCyborg

What the heck you do today with that laptop? It can't even play Youtube videos at 160p.

It is mainly used as a controller for a custom-made light-dimmer, commanded via parallel-port, with a small GUI (no graphics acceleration needed). Is is also used for small projects that use a serial (RS232) port to communicate.

It could still play DivX video, but actual Firefox version (so Youtube) do not run (too few memory).

LuckyCyborg · 08-11-2022, 12:38 PM

Quote:

Originally Posted by lucabon

I don't know the amount of effort by Slackware maintainers to keep ancient drivers: if it is only compile the driver (if it still compiles), why not keep them? In the other hand, if "support" means to be sure the drivers work with actual Xorg framework, maybe it is correct to remove them, or maintainers could put the source code in "pasture" so you can [try to] compile, but clearly without any support.

I'm just a regular Slackware user, but from what I observed, the "support" means also Quality Assurance, where it's verified the proper working of a driver with the actual Xorg framework.

I for one, I believe that those old drivers are barely functional, even they compiles. And who will adapt them to the future changes on graphics stack, considering that Slackware has not a sound crowd of programmers around?

Quote:

Originally Posted by lucabon

It is mainly used as a controller for a custom-made light-dimmer, commanded via parallel-port, with a small GUI (no graphics acceleration needed). Is is also used for small projects that use a serial (RS232) port to communicate.

It could still play DivX video, but actual Firefox version (so Youtube) do not run (too few memory).

Man, no offense intended, BUT you just waste electrical energy! There should be a law against that!

Why the heck everybody talks about Global Warming when people like you invents custom-made light dimmers which consumes "only" 90W/h ?

BTW, how is your Po river? It's fine and sound? I heard that this Summer it transformed in a creek.

qunying · 08-11-2022, 01:34 PM

Dell's server rack, like R750/R740, still use Matrox's chip as integrated graphics controller. It would be better to keep the xf86-video-mga driver.