xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

regid · 2018-06-02 17:36:50

The last post on this topic that I am aware of is at Lone_Wolf@message #38. It is a spin of the main issue there, which is why I am starting a new thread. For completnece, though probably will not contribute much, one might also should read messages #37, #30 and #29 there.
Should I left the discussion where it was?
I tried to see what others are doing. Only skimming, it looks like

Opensuse has ported their version of the driver to 1.20.0.
freebsdsoftware.org has a page here which links to the rather cryptic page here. By the dates it looks as if they updated their version. But I couldn't find a way to see something that looks close to a source code. Am I confusing freebsdsoftware.org with open source?

Last edited by regid (2018-06-02 18:20:20)

loqs · 2018-06-02 17:45:41

Patches suse applied are from upstream git https://cgit.freedesktop.org/xorg/drive … o-sis/log/
Edit:
The following builds in a clean chroot no further testing was performed.
PKGBUILD

# $Id: PKGBUILD 281737 2016-11-21 13:46:51Z lcarlier $
# Maintainer: Jan de Groot <jgc@archlinux.org>

pkgname=xf86-video-sis
pkgver=xf86+video+sis+0.10.9+7+ga50b2b3
pkgrel=1
pkgdesc="X.org SiS video driver"
arch=(x86_64)
url="https://xorg.freedesktop.org/"
license=('custom')
depends=('glibc')
makedepends=('xorg-server-devel' 'xorg-util-macros' 'xf86dgaproto' 'git' 'pixman' 'xorg-xrandr')
conflicts=()
optdepends=('sis-dri: DRI1 support from community repo')
groups=('xorg-drivers')
_commit=a50b2b3412dd8e7f3916acb142c942e85ffcb3e5
source=("git+https://anongit.freedesktop.org/git/xorg/driver/xf86-video-sis.git#commit=$_commit"
        'fix_defines.patch')
sha256sums=('SKIP'
            '8338641b519c25d9a8387608ea562970b4313e7602f890ff0331a0742c3f7f8b')

pkgver() {
  cd ${pkgname}
  git describe --tags | sed 's/^xorg-server-//;s/_/./g;s/-/+/g'
}

prepare() {
  cd ${pkgname}

  patch -Np1 -i ../fix_defines.patch

  autoreconf -vfi
}

build() {
  cd ${pkgname}
  ./configure --prefix=/usr
  make
}

package() {
  cd ${pkgname}
  make DESTDIR="${pkgdir}" install

  install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}"
  install -m644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/"
}

fix_defines.patch fixes defines and removes use of xf86DisableRandR() which appears to have been dropped.

diff --git a/src/sis_driver.c b/src/sis_driver.c
index 4e51e2e..13e6e24 100644
--- a/src/sis_driver.c
+++ b/src/sis_driver.c
@@ -4140,7 +4140,7 @@ SISPreInit(ScrnInfoPtr pScrn, int flags)
                   biossize = 0x8000;
                   break;
          }
-#if XSERVER_LIBPCIACCESS
+#ifdef XSERVER_LIBPCIACCESS
          if(readpci) {
         pSiS->PciInfo->rom_size = biossize;
         pci_device_read_rom(pSiS->PciInfo, pSiS->BIOS);
@@ -8973,11 +8973,11 @@ SISScreenInit(SCREEN_INIT_ARGS_DECL)
          case 24: refreshArea = SISRefreshArea24; break;
          case 32: refreshArea = SISRefreshArea32; break;
       }
-#if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
+/*#if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
       xf86DisableRandR();
       xf86DrvMsg(pScrn->scrnIndex, X_INFO,
         "Driver rotation enabled, disabling RandR\n");
-#endif
+#endif*/
        } else if(pSiS->Reflect) {
           switch(pScrn->bitsPerPixel) {
       case 8:
@@ -8986,11 +8986,11 @@ SISScreenInit(SCREEN_INIT_ARGS_DECL)
              if(!pSiS->PointerMoved) pSiS->PointerMoved = pScrn->PointerMoved;
          pScrn->PointerMoved = SISPointerMovedReflect;
          refreshArea = SISRefreshAreaReflect;
-#if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
+/*#if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
          xf86DisableRandR();
          xf86DrvMsg(pScrn->scrnIndex, X_INFO,
           "Driver reflection enabled, disabling RandR\n");
-#endif
+#endif*/
          break;
       default:
          xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
@@ -9097,13 +9097,13 @@ SISScreenInit(SCREEN_INIT_ARGS_DECL)
        pSiS->Rotate = 0;
        pSiS->Reflect = 0;
        pSiS->ShadowFB = FALSE;
-#if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
+/*#if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
        if(pSiS->CRT1XOffs || pSiS->CRT1YOffs || pSiS->CRT2XOffs || pSiS->CRT2YOffs) {
       xf86DisableRandR();
       xf86DrvMsg(pScrn->scrnIndex, X_INFO,
         "MergedFB: CRT2Position offset used, disabling RandR\n");
        }
-#endif
+#endif*/
 #ifdef SISXINERAMA
        if(pSiS->UseSiSXinerama) {
       SiSnoPanoramiXExtension = FALSE;
diff --git a/src/sis_vga.c b/src/sis_vga.c
index 8b625d2..cf39d0c 100644
--- a/src/sis_vga.c
+++ b/src/sis_vga.c
@@ -1715,7 +1715,7 @@ SiSVGAMapMem(ScrnInfoPtr pScrn)
     if(pSiS->VGAMapPhys == 0) pSiS->VGAMapPhys = 0xA0000;
 
 #if XF86_VERSION_CURRENT >= XF86_VERSION_NUMERIC(4,3,0,0,0)
-#if XSERVER_LIBPCIACCESS
+#ifdef XSERVER_LIBPCIACCESS
     (void) pci_device_map_legacy(pSiS->PciInfo, pSiS->VGAMapPhys, pSiS->VGAMapSize,
                                  PCI_DEV_MAP_FLAG_WRITABLE, &pSiS->VGAMemBase);
 #else
@@ -1737,7 +1737,7 @@ SiSVGAUnmapMem(ScrnInfoPtr pScrn)
 
     if(pSiS->VGAMemBase == NULL) return;
 
-#if XSERVER_LIBPCIACCESS
+#ifdef XSERVER_LIBPCIACCESS
     (void) pci_device_unmap_legacy(pSiS->PciInfo, pSiS->VGAMemBase, pSiS->VGAMapSize);
 #else
     xf86UnMapVidMem(pScrn->scrnIndex, pSiS->VGAMemBase, pSiS->VGAMapSize);

Last edited by loqs (2018-06-02 19:18:26)

regid · 2018-06-03 00:05:49

Thank you.

./configure is missing.

==> Starting build()...
/home/guest/xf86-video-sis/PKGBUILD: line 37: ./configure: No such file or directory
==> ERROR: A failure occurred in build().
    Aborting...

In addition:
- Why a dependency on xorg-util-macros is declared when xorg-server-devel, which is the another dependency, depends on it?
- Patching of the sis_driver.c done manually, perhaps bacause of white space.

Last edited by regid (2018-06-03 00:16:14)

progandy · 2018-06-03 00:45:50

configure is there, but only if you run the autoreconf line from prepare(). The error during the patch process stopped that from happening. The patch works if you add the option --ignore-whitespace (-l) and update the checksum in the PKGBUILD.

loqs · 2018-06-03 01:11:32

https://ptpb.pw/2MVt should have the patch which matches the checksum apologies. regid yes the depends is unneeded. The other dependencies need checking as well.
This PKGBUILD was just aimed at getting a building package to test.
Edit:
The remaining compile warnings relating to const mismatches I did not address as they did not prevent compilation.

Last edited by loqs (2018-06-03 01:12:57)

Lone_Wolf · 2018-06-03 11:28:03

Build looks ok, i've adopted the aur package.

Should this package depend on 'X-ABI-VIDEODRV_VERSION=24.0' and conflict with older or newer versions like xf86-video-* in repos ?

loqs · 2018-06-03 11:45:17

makedepends=('xorg-server-devel' 'X-ABI-VIDEODRV_VERSION=24.0' 'xf86dgaproto' 'git' 'pixman')
conflicts=('xorg-server<1.20' 'X-ABI-VIDEODRV_VERSION<24' 'X-ABI-VIDEODRV_VERSION>=25')

Also dropped xrandr as the sis driver tries to disable it but the function to do that was removed https://cgit.freedesktop.org/xorg/xserv … 23692827ed
Edit:
This might be needed as well https://git.archlinux.org/svntogit/pack … ouveau#n29 needs someone to test loading the module.

Last edited by loqs (2018-06-03 11:49:04)

regid · 2018-06-04 00:14:41

I built xf86-video-sis before loqs posted comment #7. Seem to got built reasonbly well. Than I was anxious to get it running, which is why I didn't took into account that comment.
I also haven't done any of the configuration suggested by https://wiki.archlinux.org/index.php/SIS#xorg.conf, hoping it will configure itself. So I used

xinit -geometry=80x65+10+10 -fa monospace:size=23 -fg white -bg navy

I believe that is very similar to an example from xinit manual page. I got surprised to see that it used my .xinitrc file. Shouldn't it just opened an xterm? More important to this discussion, it fell back to the working vesa driver.
It would be more convenient if I could write some lines to a configuration file, or commenting them out, in order to choose which driver I am intersted in running, rather than installing, or removing, unwanted drivers from the system. Can I do that?

Can I get the relevant information just by grepping the log files for sis?
With both sis and vesa drivers installed:

$ grep sis /var/log/Xorg.0.log  # Both sis and vesa drivers installed.
[ 62108.000] (==) Matched sis as autoconfigured driver 0
[ 62108.000] (II) LoadModule: "sis"
[ 62108.000] (II) Loading /usr/lib/xorg/modules/drivers/sis_drv.so
[ 62108.034] (EE) Failed to load /usr/lib/xorg/modules/drivers/sis_drv.so: /usr/lib/xorg/modules/drivers/sis_drv.so: undefined symbol: xf86InitInt10
[ 62108.034] (EE) Failed to load module "sis" (loader failed, 0)

When only vesa driver installed:

$ grep sis /var/log/Xorg.0.log.old  # Only vesa driver installed.
[    41.422] (==) Matched sis as autoconfigured driver 0
[    41.423] (II) LoadModule: "sis"
[    41.433] (WW) Warning, couldn't open module sis
[    41.433] (EE) Failed to load module "sis" (module does not exist, 0)

Both log files reported inability to load protocol.txt.

Marginal to this discussion, exiting the xserver when the vesa driver was in charge leaves the vt in a somewhat non consistent state as far as I, as a user, am concerned. My solution is to issue a setfont command in order to get it back to where it was before xinit. Luckily I can still see the vt reasonbly well to issue commands.

Last edited by regid (2018-06-04 00:39:20)

loqs · 2018-06-04 10:04:25

Updated PKGBUILD to fix the undefined symbol issue no increment in pkgrel

# $Id: PKGBUILD 281737 2016-11-21 13:46:51Z lcarlier $
# Maintainer: Jan de Groot <jgc@archlinux.org>

pkgname=xf86-video-sis
pkgver=xf86+video+sis+0.10.9+7+ga50b2b3
pkgrel=1
pkgdesc="X.org SiS video driver"
arch=(x86_64)
url="https://xorg.freedesktop.org/"
license=('custom')
depends=('glibc')
makedepends=('xorg-server-devel' 'X-ABI-VIDEODRV_VERSION=24.0' 'xf86dgaproto' 'git' 'pixman')
conflicts=('xorg-server<1.20' 'X-ABI-VIDEODRV_VERSION<24' 'X-ABI-VIDEODRV_VERSION>=25')
optdepends=('sis-dri: DRI1 support from community repo')
groups=('xorg-drivers')
_commit=a50b2b3412dd8e7f3916acb142c942e85ffcb3e5
source=("git+https://anongit.freedesktop.org/git/xorg/driver/xf86-video-sis.git#commit=$_commit"
        'fix_defines.patch::https://ptpb.pw/2MVt')
sha256sums=('SKIP'
            '8338641b519c25d9a8387608ea562970b4313e7602f890ff0331a0742c3f7f8b')

pkgver() {
  cd ${pkgname}
  git describe --tags | sed 's/^xorg-server-//;s/_/./g;s/-/+/g'
}

prepare() {
  cd ${pkgname}

  patch -Np1 -i ../fix_defines.patch

  autoreconf -vfi
}

build() {
  cd ${pkgname}
  export CFLAGS=${CFLAGS/-fno-plt}
  export CXXFLAGS=${CXXFLAGS/-fno-plt}
  export LDFLAGS=${LDFLAGS/,-z,now}
  ./configure --prefix=/usr
  make
}

package() {
  cd ${pkgname}
  make DESTDIR="${pkgdir}" install

  install -m755 -d "${pkgdir}/usr/share/licenses/${pkgname}"
  install -m644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/"
}

Edit:
Abount xinit

...
If no specific client program is given on the command line, xinit will
look for a file in the user's home directory called .xinitrc to run as
a shell script to start up client programs. If no such file exists,
xinit will use the following as a default:
xterm -geometry +1+1 -n login -display :0

Last edited by loqs (2018-06-04 10:15:53)

regid · 2018-06-04 14:01:44

message #9 has changed only PKGBUILD. In that case, now it is exaDriverAlloc that is not defined:

(==) Matched sis as autoconfigured driver 0
(II) LoadModule: "sis"
(II) Loading /usr/lib/xorg/modules/drivers/sis_drv.so
(EE) Failed to load /usr/lib/xorg/modules/drivers/sis_drv.so: /usr/lib/xorg/modules/drivers/sis_drv.so: undefined symbol: exaDriverAlloc
(EE) Failed to load module "sis" (loader failed, 0)

xinit:
The way I understand loqs qoutation from the manual page is:
```
if (no specific client program is given on the command line)
    if (.xinitrc exits)  use it;
    else exec  xterm  -geometry  +1+1  -n  login  -display  :0;
```
Which look to me consistent with one of the examples at the bottom of the manual page:
xinit -geometry =80x65+10+10 -fn 8x13 -j -fg white -bg navy
This will start up a server named X, and will
append the given arguments to the default
xterm command. It will ignore .xinitrc.

Last edited by regid (2018-06-04 14:44:37)

loqs · 2018-06-04 14:53:24

Please create /etc/X11/xorg.conf.d/10-sis.conf with the following contents

Section "Module"
    Load "exa"
    Load "sis"
EndSection

If it still fails please post the full Xorg.log

xinit -geometry=80x65+10+10 -fa monospace:size=23 -fg white -bg navy

Does not specify client program though just options intended for xterm

progandy · 2018-06-04 15:26:49

@loqs: The documentation is inconsistent, the example describes a behaviour that is not implemented and differs from the description.

I already reported a bug for startx which runs into this issue as well, but there was no reaction. I know, it is not the best report because it mixes startx and xinit, but I have no motivation to improve it when there is no activity.
https://bugs.freedesktop.org/show_bug.cgi?id=104910

loqs · 2018-06-04 16:00:29

If it is still failing with the above 10-sis.conf please also try modifying it to

Section "Module"
    Load "sis"
EndSection

Section "Device"
  Identifier  "Sis Graphics"
  Driver      "sis"
  Option      "Accel" "False"
EndSection

regid · 2018-06-05 00:50:04

Turns out that Load "exa" is enough for the Secion "Module" of /etc/X11/xorg.conf.d/10-sis. No need for a Load "sis" there. If the exa module is required for the sis driver, can't it get loaded automatically?
I deliberately reverted to falling back to the vesa driver by commenting out the Load "exa" line. I did that because I am totaly not satisfied with the resulting resolution of the sis driver. It claims it can do less than the 1024x768 of the vesa driver. Which seems to me as if something is wrong with the sis driver. At the same machine, MS XP reports a resolution of 1280x1024 at 32 bpp, a resolution that the vesa driver excplicitly rules out. Another blocking issue I have with the sis driver is that the WM can not maximize the windows on the screen. It makes them larger than the screen size. I think this problem is tied to the resolution issue. The same WM has no problem to maximize the windows with the vesa driver.
The log file when running the sis driver is at Xorg.log.UnsatisfacorySisDriver. It think it shows more issues. For comparision, the log when deliberately falling back to the vesa driver is at Xorg.log.DeliberatelyFallingBackToVesa. The monitor is a 19" 4:3 aspect ratio.

regid · 2018-06-05 01:21:10

progandy@comment# 12, are you referring to the xinit issue? loqs@comment #11 is right that the command line has no client program, but

The manual page explicitly states, I think that more than once, that xterm is a default client when no other is mentioned.
That line is taken almost verbatim from the manual page.

Which brings me to the correctness of the manual page.

My experience is that in practice, the command line client takes over only if there is no .xinitrc file, where the manual page states the opposite. Just move an .xinitrc file aside to test. It could be that the same is true for the .xserverrc file.
Not that it matters much but xterm does not accept = in -geometry. And that equality character is taken from the xinit manual page verbatim.

Edit: I think the actual behaviour of xinit, which is to run .xinitrc if exists, even when arguments are given on the command line, and an xterm only when no .xinitrc exists, is better than what the manual page describes. The reason is that it lets one pass arguments to .xinitrc, thus do something like:

...

# Here Xfce is kept as default
session=${1:-xfce}

case $session in
    i3|i3wm           ) exec i3;;
    kde               ) exec startkde;;
    xfce|xfce4        ) exec startxfce4;;
    # No known session, try to run it as command
    *                 ) exec $1;;
esac

, which will run an xterm if explicitly required by the command line. This code, which is copied verbatim from an example on arch wiki, is more versatile and probably least surprise. Therfore, I think only the documentation should be fixed.

Last edited by regid (2018-06-08 12:18:25)

regid · 2018-06-05 01:38:01

loqs@comment #13: The configuration you suggested is bad. It reports the undefined exaDriverAlloc. It looks like sis will not get loaded without that symbol. When I changed the sis loading to exa loading it does run, but in way that I described in comment #14. As I wrote, I don't accept that. Currently I am back to vesa.

loqs · 2018-06-05 09:57:10

@regid did the sis driver ever have auto loading of exa or correct resolution detection under older versions of X?
Edit:
Can you also post the working config snippet you are using please.

Last edited by loqs (2018-06-05 09:57:47)

regid · 2018-06-05 11:18:56

loqs@message #17:

How was it under older versions of X?

The short answer is: I don't know.
The long answer is: The VESA driver runs for me almost effortlessly. I have more urgent work, so I didn't mind. A few months ago, with X < 1.20.0, I gave the SIS driver a short test. I followed https://wiki.archlinux.org/index.php/SIS, and got it running. With the exact configuration that is suggested by the wiki. I was disapointed, much like I am now disapointed, and after a few minutes I reverted back to VESA. From memory, and because exa is not mentioned at the wiki page, I think it was not required to explicitly load it. BUT. From memory, it was running with a low resolution. I don't remember and didn't actually were looking for the figures, but it could be 640x480. Or maybe it was the current 960x600 resolution, and I mistakenly think it was 640x480? And it could be that the wrong screen size problem was there back than. I don't remember, and I gave up after a few minutes. As an aside, you can see that both the wiki and UnsatisfacorySisDriver, explicitly mentions sisctrl. Qouting

https://wiki.archlinux.org/index.php/SIS#Packages wrote:

it's good idea to install sisctrlAUR (gui tool for setting video modes)

. And UnsatisfacorySisDriver even bothers to mention a URL for sisctrl. Did sisctrl has a high importance all that time? I didn't test sisctrl back than.

Current configuration

There is practically none. I deliberately want it to fall back to the VESA driver, which I managed to get working out of the box. https://wiki.archlinux.org/index.php/Xorg writes that these days X is mostly working out of the box. I think it is a desired goal. /var/log/Xorg.0.log is very similar to the one at Xorg.log.DeliberatelyFallingBackToVesa.
More precisely,

$ cat /etc/X11/xorg.conf.d/*
Section "Module"
#    Load   "exa"
EndSection

Section "Device"
    Identifier "Sis Graphics"
#    Option "ForceCRT1VGAAspect" "NORMAL"
#    Option "UseSSE" "on"
EndSection

Last edited by regid (2018-06-05 13:29:14)

Lone_Wolf · 2018-06-05 18:48:05

[  5283.079] (==) SIS(0): DRI disabled

try installing https://www.archlinux.org/packages/comm … 4/sis-dri/ .

X is mostly working out of the box

That is largely due to KMS drivers .

Last edited by Lone_Wolf (2018-06-05 18:48:18)

regid · 2018-06-06 00:16:45

Lone_Wolf wrote:

[  5283.079] (==) SIS(0): DRI disabled
try installing https://www.archlinux.org/packages/comm … 4/sis-dri/ .

pacman wrote:

# pacman -S sis-dri
resolving dependencies...
looking for conflicting packages...
:: sis-dri and xf86-video-sis are in conflict. Remove xf86-video-sis? [y/N] 
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: sis-dri and xf86-video-sis are in conflict (xf86-video-sis<0.10.2)
# pacman -Qi xf86-video-sis | grep Version
Version         : xf86+video+sis+0.10.9+7+ga50b2b3-1

progandy · 2018-06-06 05:40:54

The version of xf86-video-sis does not look right, the pkgver() function should remove the leading "xf86+video+sis+".

pkgver() {
  cd ${pkgname}
  git describe --tags | sed 's/^xf86-[a-z-]*//;s/_/./g;s/-/+/g'
}

Edit: Typo: duplicated search/replace command ("s/s/" instead of "s/")

Last edited by progandy (2018-06-06 16:04:58)

Lone_Wolf · 2018-06-06 12:25:11

sed: -e expression #1, char 19: unknown option to `s'

typo ?

Anyway, here's an updated PKGBUILD.

# Maintainer: Lone_Wolf <lonewolf@xs4all.nl>
# Contributor: Jan de Groot <jgc@archlinux.org>
# Porting this to xorg-server 1.20 made possible by : loqs, progandy, regid
# see https://bbs.archlinux.org/viewtopic.php?id=237632

pkgname=xf86-video-sis
pkgver=0.10.9.r7.ga50b2b3
pkgrel=1
pkgdesc="X.org SiS video driver"
arch=(x86_64)
url="https://xorg.freedesktop.org/"
license=('custom')
depends=('glibc')
makedepends=('xorg-server-devel' 'X-ABI-VIDEODRV_VERSION=24.0' 'xf86dgaproto' 'git' 'pixman')
conflicts=('xorg-server<1.20' 'X-ABI-VIDEODRV_VERSION<24' 'X-ABI-VIDEODRV_VERSION>=25')
optdepends=('sis-dri: DRI1 support from community repo')
groups=('xorg-drivers')
_commit=a50b2b3412dd8e7f3916acb142c942e85ffcb3e5
source=("git+https://anongit.freedesktop.org/git/xorg/driver/xf86-video-sis.git#commit=$_commit"
        'fix_defines.patch::https://ptpb.pw/2MVt')
sha256sums=('SKIP'
            '8338641b519c25d9a8387608ea562970b4313e7602f890ff0331a0742c3f7f8b')

pkgver() {
  cd ${pkgname}
  git describe --long | sed 's/^xf86-video-sis.//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

prepare() {
  cd ${pkgname}
  patch -Np1 -i ../fix_defines.patch
  autoreconf -vfi
}

build() {
  cd $pkgname
  export CFLAGS=${CFLAGS/-fno-plt}
  export CXXFLAGS=${CXXFLAGS/-fno-plt}
  export LDFLAGS=${LDFLAGS/,-z,now}
  ./configure --prefix=/usr
  make
}

package() {
  cd $pkgname
  make DESTDIR="$pkgdir" install

  install -Dt  "$pkgdir"/usr/share/licenses/$pkgname "$srcdir"/$pkgname/COPYING
}

progandy · 2018-06-06 16:06:58

Yes, typo. This should now allow the installation of sis-dri which has a conflict with older xf86-video-sis versions (<0.10.2).

regid · 2018-06-06 18:15:38

Log when running xf86-video-sis built with Lone_wolf@comment #22 PKGBUILD is at UnsatisfacorySisDriver.

sis-dri, which has been insatlled, doesn't seem to change the fact that the server has DRI DISABLED. Neither does adding Load "dri", as suggested by https://wiki.archlinux.org/index.php/SiS.
Should I have used "sis-dri", instead of just "dri"?
For some reason, contrary to what happened before, commenting Load "exa" in, or out, does not change anything. The server does run in both cases.

I am disapointed with the resolution.

Last edited by regid (2018-06-06 18:20:51)

progandy · 2018-06-06 19:48:25

Another option might be to compile the kernel with FB_SIS FB_SIS_300, FB_SIS_315 or maybe compile them as extra modules and use xf86-video-fbdev for xorg? The sis-dri driver in mesa seems to be old and not supported anymore.

Edit: There seems to be a drm sis driver in the kernel as well, but arch doesn't compile it either.

Last edited by progandy (2018-06-06 19:54:47)

Arch Linux

#1 2018-06-02 17:36:50

xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#2 2018-06-02 17:45:41

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#3 2018-06-03 00:05:49

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#4 2018-06-03 00:45:50

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#5 2018-06-03 01:11:32

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#6 2018-06-03 11:28:03

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#7 2018-06-03 11:45:17

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#8 2018-06-04 00:14:41

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#9 2018-06-04 10:04:25

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#10 2018-06-04 14:01:44

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#11 2018-06-04 14:53:24

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#12 2018-06-04 15:26:49

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#13 2018-06-04 16:00:29

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#14 2018-06-05 00:50:04

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#15 2018-06-05 01:21:10

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#16 2018-06-05 01:38:01

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#17 2018-06-05 09:57:10

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#18 2018-06-05 11:18:56

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#19 2018-06-05 18:48:05

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#20 2018-06-06 00:16:45

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#21 2018-06-06 05:40:54

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#22 2018-06-06 12:25:11

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#23 2018-06-06 16:06:58

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#24 2018-06-06 18:15:38

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

#25 2018-06-06 19:48:25

Re: xf86-video-sis in AUR is old, and need to be ported to xorg 1.20.0

Board footer