- xserver-xorg-input-aiptek
- xserver-xorg-input-elographics
- xserver-xorg-input-mtrack
- xserver-xorg-input-mutouch
- xserver-xorg-input-void
- server-xorg-video-ast
- xserver-xorg-video-mach64
- xserver-xorg-video-neomagic
- xserver-xorg-video-r128
- xserver-xorg-video-savage
- xserver-xorg-video-siliconmotion
- xserver-xorg-video-sisusb
- xserver-xorg-video-tdfx
- xserver-xorg-video-trident
The history so far:
It starte with Geode display driver initially decided to be removed but wasn’t dropped. Debian bug report was the init of the history: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955603#29 you must send a cmail to that bug and reclaim that do not removes the modules!
Rage128 was OEM'ed to a very large number of manufacturers for many years and after the desktop moved on to newer tech, it had a lengthy life as the VGA chip for server boards, was also the video chip for the All-In-Wonder boards. When MSFT and ATI refused to port legacy AIW functions into M$ 2000/XP, many people just stayed on Win98 and let them run. When ATSC came along even more were retired.
VIA + S3 Graphics Chrome series of graphics accelerators arrived with the DeltaChrome line of chips. They were supplied as discrete, mobile, or integrated graphics. The hybrid Savage4/Savage2000 ProSavage IGP was part of chipsets such as KM133, PL133T, PM133T, KM266, P4M266, and KM333. Variants called SuperSavage MX & IX were used in notebooks as well, Several Pentium4 based hardwares and K8/K9 based hardwares comes with those chipsets. After those S3's graphics division would regroup in later years and create the Chrome series. but seems those lasted are not well supported on linux. In fact part are supported in Openchrome's xorg module and part are now gone in the Savage's xorg module.
CURRENT SITUATION:
The Savage, the openchrome module, used for VIA Chrome and Savage graphics, and the r128 module used for ATI Rage graphics currently have problems. The problem is the kernel flag CONFIG_IO_STRICT_DEVMEM which, for security reasons, prevents userspace programs from accessing hardware registers. This prevents these drivers from mapping the framebuffer unless special steps are taken.
Symptoms:
Many linux installations may fail to start X (live mode, unless a safe mode boot is selected). In the installed system, by exambple the vesa driver is used always, and mostly after install property selected module gives very poor results with tearing and ghost cursors, especially when there is a load on the cpu.
Solution:
- Use the kernel command line parameter iomem=relaxed. This allows proper framebuffer mapping. For a one-off boot in this mode, simply press “e” when you see the GRUB menu, to enter edit mode. Scroll down to the kernel command line and add the required parameter.
- To make the change permanent, you need to edit (as root) the /etc/default/grub file. There is a line in the file for the kernel command line. Simply add the iomem=relaxed parameter to this line. Then run update-grub. Every subsequent update of GRUB will include the new parameter.
NOTES: mismatch between the picture size and the screen:. This disappears when you use the card-specific driver. But because this driver was not in use during installation, you must either edit it into /etc/X11/xorg.conf or add an extra configuration file in /etc/X11/xorg.conf.d, and put or change the current "Driver" in use (by example mostly vesa) by the ones on the list:
- xserver-xorg-video-ast (ASpeed)
- xserver-xorg-video-mach64 (ati)
- xserver-xorg-video-neomagic (MagicGraph)
- xserver-xorg-video-r128 (ATI Rage)
- xserver-xorg-video-savage (S3)
- xserver-xorg-video-siliconmotion (Sis)
- xserver-xorg-video-sisusb (Sis)
- xserver-xorg-video-tdfx (Tdfx)
- xserver-xorg-video-trident (Trident 3D)
- xserver-xorg-video-openchrome (VIA chrome and VIA S3)
- xserver-xorg-video-matrox (MAtrox g200)
No hay comentarios.:
Publicar un comentario
no stupid winbuntu users allowed!