Yes, as I said, adding “nomodeset” to the boot options might be worth a try.
But I don’t know what you mean with “disable DRI”.
Failing that, I would take a hard look at the arch linux sis DRI driver and ask myself, why is arch linux packaging such for sis ?
That is the Mesa 3D driver, which won’t help at all if not even the standard X driver can be loaded.
And AFAIK the 3D driver only supports an even more limited subset of sis chips, mabe a handful.
But again, this is irrelevant at this point, it’s only for 3D hardware acceleration.
Regarding the sis671, a quick google leads me to believe that this is a closed-source, proprietary driver. And likely to not even work at all on 13.2 I’d say.
PS: This might help for an acceptable resolution (using the vesa driver):
I don’t think I did (know) either. Your accurate observation motivated me to read up on DRI (Direct Rendering Interface) where according to the wiki it is split into three parts:
[ul]
[li]the Direct Rendering Manager (DRM), a kernel component, for command checking and queuing (not scheduling); the DRM is a combination of at least two kernel modules, one of core DRM code and others providing APIs to userland to access different classes of video hardware.[/li]> [LIST]
[li]KMS driver, the device driver for the display controller [/li]> [li]Graphics Execution Manager (GEM) or gemified Translation Table Maps (TTM), a kernel component, that despite its name, it does not execute anything but is responsible for the memory management of the graphics memory; [/li]> [/ul]
[li]the Mesa 3D device drivers, a userspace component, that does the translation of OpenGL commands into hardware specific commands; it prepares buffers of commands to be sent to the hardware by the DRM and interacts with the windowing system for synchronization of access to the hardware [/li]> [/LIST]
I recall reading posts of users who looked how to disable DRI, but as often in the case in GNU/Linux (like my ill informed statement) there is misinformation around (often borne out of speculation) and that wording does not make a lot of sense. I did note that features (?) of DRI can be disabled, such as disabling XAA (via " --disable-xaa " ) and disabling acceleration ( Option “NoAccel” “True” ) in appropriate places, or as you note disabling the kernel mode setting (KMS). But there are no errors that I could see in the xorg.0.log file suggesting the sis driver loaded sufficiently for such to have any negative nor positive impact.
I’m coming to the same conclusion as yourself and deano_ferrari that the VESA driver may be the best way to proceed.
Its been an educational thread for me, and I hope my few posts of research here were not too disruptive.
Those set the X driver’s acceleration method, or diable acceleration completely in the X driver.
But as the X driver (sis) is not even used, that won’t help either in getting it to work.
or as you note disabling the kernel mode setting (KMS).
AFAIK sis does not even support KMS.
So maybe disabling it could help, but I’m not sure. It’s been years since I used a sis chipset myself, before the advent of KMS.