Should I Submit My Mach64 PKGBUILDs?

kludge · 2008-08-08 00:15:52

Greetings, y'alls.

So, I've spent a whole lot of time reading all the available documentation on getting DRM/DRI to work with the Mach64 chipset, and the upside is that I've crafted and tested two PKGBUILDS that do the work.

The first, libdrm-mach64, pulls the Mesa libdrm from git and compiles it with support for the Mach64 chipset. This pkg replaces extra/libdrm, and provides the new libdrm files, drm.ko re-rolled for Mach64 support, and all of the other card-specific kernel modules.

The second, xf86-video-ati-mach64, re-rolls and replaces the X11 ATI video and dri drivers and installs the mach64_dri.so and mach64_drv.so missing from extra/xf86-video-ati.

These are two PKGBUILDS that have been asked for repeatedly:

http://bbs.archlinux.org/viewtopic.php?id=43041
http://bbs.archlinux.org/viewtopic.php?id=41722
http://bbs.archlinux.org/viewtopic.php?id=32511
http://bbs.archlinux.org/viewtopic.php?id=14767
http://bbs.archlinux.org/viewtopic.php?pid=324509

and I'd be really happy at having a chance to contribute something concrete to the distro and community that's given me such a rad linux desktop. However, in looking around, I find a couple of things that make me hesitate before submitting these to the AUR.

First, vis-a-vis libdrm-mach64, there's this PKGBUILD already available and apparently maintained: http://aur.archlinux.org/packages.php?ID=17939. However, this PKGBUILD *only* provides the kernel modules, and only drm.ko and mach64.ko. I haven't tested it, having only discovered it after I'd put my own together, but it seems like it would raise package conflicts (for instance with extra/libdrm, as mentioned in the README. I'd like to present my work to the current maintainer, lambchop468, before posting something that conflicts with/overrides their work, but I'm unclear if that's expected or how to do that.

Second, vis-a-vis xf86-video-ati-mach64, my PKGBUILD only really differs from the extra/xf86-video-ati ABS in that it includes mach64 in the build targets and inserts itself cleanly into the system by providing and conflicting with xf86-video-ati. In light of this thread, it seems like this might be frowned upon for needlessly duplicating existing pkgs and ABS PKGBUILDs, as well as "dumbing down" the process for an otherwise fairly well-documented tweak.

Finally, as I've never submitted to the AUR before, I'd be happy if folks would look over the PKGBUILD files to see if I've done an alright job. (I've tried to follow the guidelines, but it's always nice to get that seal of approval.)

On the other hand(s), I'm pleased as punch with my work and would love to contribute back to the Arch community.

Any thoughts?

-kludge

Kalidor · 2008-10-14 10:29:45

Wow, seems like you've really invested a lot of time there. The lack of response must be due the relative age of the Mach64 chip. I still have a laptop with it, but do not need/use 3D acceleration there (with 8 MB of video memory, you can't do much anyway nowadays). In the past, though, I was very displeased with the fact that 3D acceleration was not (easily) available.

medic2000 · 2008-11-25 23:07:16

Yes you should really contribute your workings. I have tried the package in the AUR. But i gave me an error :

sudo modprobe mach64
FATAL: Error inserting mach64 (/lib/modules/2.6.27-ARCH/kernel/drivers/char/drm/mach64.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Dmesg is:

mach64: Unknown symbol drm_get_dev
mach64: Unknown symbol drm_handle_vblank
mach64: Unknown symbol drm_cleanup_pci
mach64: Unknown symbol drm_vblank_init

kludge · 2008-11-26 18:24:02

@medic2000: the one in the aur you refer to is mach64drm, yeah? did you pay catc this note when you ran 'pacman -U mach64drm.pkg.tar.gz':

If you recieve a message when starting X or modprobing mach64 about unknown symbols, attempt to modprobe the proper AGP module for your chipset first, then the drm module

i would try this *first*. after that, check out my stuff.

here's the thing... i quit using my hand-rolled libdrm, and now use lambchop's mach64drm. i'm not even sure my other package is necessary, but i've uploaded it to the aur anyhow. it's the ati driver package, but with mach64 enable in the build configuration.

here it is: http://aur.archlinux.org/packages.php?ID=21826

i don't want to upload my libdrm-mach64 pkgbuild because

(a) i'm not sure it's useful (i'm having no problems* with the libdrm from [extra])
(b) it superscedes lambchop's pkgbuild, and that would be impolite

but i'll post the files here, so you can use it if you like.

PKGBUILD:

# Packager: kludge (drkludge@rat-patrol.org)
# Contributor: kludge (drkludge@rat-patrol.org)
pkgname=libdrm-mach64
pkgver=2.3.0
pkgrel=1
pkgdesc="Userspace interface to kernel DRM services with ATI Mach64 support"
arch=(i686)
depends=('glibc')
makedepends=('git' 'make' 'imake' 'automake')
provides=('libdrm=2.3.0')
conflicts=('libdrm=2.3.0')
options=('!libtool')
install=$pkgname.install
url="http://dri.freedesktop.org/wiki/Building"
license=('custom')
source=()
md5sums=('')

_gitroot="git://anongit.freedesktop.org/git/mesa/drm"
_gitname="drm"

_kernelrelease=`uname -r`

build() {

  cd $startdir/src

  msg "Connecting to git.freedesktop.org GIT server...."

  if [ -d $startdir/src/$_gitname ] ; then
  cd $_gitname && git-pull origin
  msg "The local files are updated."
  else
  git clone $_gitroot
  fi

  msg "GIT checkout done or server timeout"
  msg "Starting make..."

  cp -r $startdir/src/$_gitname $startdir/src/$_gitname-build
  cd $startdir/src/$_gitname-build

  ./autogen.sh --prefix=/usr --exec-prefix=/usr
  make || return 1
  make DESTDIR=$startdir/pkg install

  find $startdir/pkg -type f -name '*.la' -exec rm {} \;

  cd $startdir/src/$_gitname-build/linux-core
  make || return 1
  mkdir -p ${startdir}/pkg/lib/modules/$_kernelrelease/kernel/drivers/char/drm
  mv *.ko ${startdir}/pkg/lib/modules/$_kernelrelease/kernel/drivers/char/drm

}

n.b.: this is version 2.3.0 of libdrm. the current release version is 2.3.1. since i'm not using it, i never bothered to updated it.

README:

Please use the '--holdver' flag to prevent makepkg from automatically 
assigning a package version based on the git checkout of the source.

If pacman complains that any of the files already exist, install with 'pacman -Uf'.

libdrm-mach64.install:

#!/bin/bash

post_install(){
        echo 'running depmod -a `uname -r`'
        depmod -a `uname -r`
        echo "If you recieve a message when starting X or modprobing mach64 about unknown symbols, attempt to modprobe the proper AGP module for your chipset first, then the drm module"
}

post_upgrade(){
        echo 'running depmod -a `uname -r`'
        depmod -a `uname -r`
        echo "If you recieve a message when starting X or modprobing mach64 about unknown symbols, attempt to modprobe the proper AGP module for your chipset first, then the drm module"
}

*i'm also not using dri for anything. the whole point of the exercise was get compositing running so i could offload some of the 2D processing onto the gpu. but that doesn't work with fluxbox *anyhow*, so i kinda gave up

medic2000 · 2008-11-27 11:47:28

Thanks for the quick reply kludge. Yes i've tried to load the needed modules first. But that too didn't solved the problem. Some people say you have to recompile the kernel to get rid of the built-in drm. They say that is conflicting with the new one. But i have no time for and I guess i am gonna use your ati package.

Thanks again for everything.

AlbaTiVo · 2008-12-28 04:23:36

Hi kludge,

According to yaourt:

[root@archlinux ~]# yaourt mach64
1 extra/xf86-video-mach64 6.8.0-2 [installed] (xorg-video-drivers)
X.org mach64 video driver

However, I am getting the following error in my /var/log/Xorg.0.log:

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
[drm] failed to load kernel module "mach64"
(EE) [drm] drmOpen failed.
(EE) MACH64(0): [dri] DRIScreenInit Failed

Would your PKGBUILD address this?

Thanks!

Steven

kludge · 2008-12-28 05:50:03

@AlbaTivo: it might, but before you go with it, what else have you done to get the driver from [extra] working? have you tried modprobing it by hand? with the '-v' switch? watching the error messages? now that xf86-video-mach64 is in [extra], i'm using it and not planning on maintaining the pkgbuild in the aur (unless i get requests for it). the pkg in [extra] works just fine for me, so it must work... maybe open a new thread for help with it if you can't resolve it on yr own?

Arch Linux

#1 2008-08-08 00:15:52

Should I Submit My Mach64 PKGBUILDs?

#2 2008-10-14 10:29:45

Re: Should I Submit My Mach64 PKGBUILDs?

#3 2008-11-25 23:07:16

Re: Should I Submit My Mach64 PKGBUILDs?

#4 2008-11-26 18:24:02

Re: Should I Submit My Mach64 PKGBUILDs?

#5 2008-11-27 11:47:28

Re: Should I Submit My Mach64 PKGBUILDs?

#6 2008-12-28 04:23:36

Re: Should I Submit My Mach64 PKGBUILDs?

#7 2008-12-28 05:50:03

Re: Should I Submit My Mach64 PKGBUILDs?

Board footer