[mach64] DRI not Automatically Enabled for ATI Rage Mobility P/M

[reh4c]

I'm a newbie to Linux, but I've finally managed to get DRI enabled on my Fujitsu FMV-Biblo LOOX T86A with help from the forums. This may be more of a feature/enhancement request than a bug. The following procedure enables DRI on this notebook, while the basic installation of Ubuntu Dapper Flight 5 does not. With the 386 vanilla kernel installed, I perform the following:
1. Manually change the color depth to 16 instead of Ubuntu's default 24 in the xorg.conf file. My 8MB graphics chip (ATI Rage Mobility P/M) will only support 16 due to memory requirements.
2. 'sudo apt-get install linux-headers-386 build-essential'
3. Download the latest common and mach64 snapshots from http://dri.freedesktop.org.
4. Untar the common file first, followed by the mach64 file.
5. Change directory to the location of the unpacked common driver.
6. Run 'sudo ./install.sh' for the common modules and accept the default choices for the scripts.
7. Repeat steps 5 and 6 for the mach64 driver, using the default script choices.
8. Restart X and type 'glxinfo | grep "direct" to verify that direct rendering states "yes".

My laptop runs exceptionally better overall after completing this procedure. I'm certain it will help others as well. 3D gaming and GL are now possible. Can Ubuntu developers incorporate this script into the base install? Thanks.

Note: the original reporter indicated the bug was in package 'xserver-mach64'; however, that package was not published in Ubuntu.

[Jerome S. Gotangco (jsgotangco)]

I will confirm this bug but tag it as a wishlist. Beta freeze has already begun so I doubt it'll get into this cycle. Thanks for the instructions btw.

[Fabio Massimo Di Nitto (fabbione)]

DRM in the kernel should be updated.

(Ben this is just a "close with next upstream release bug")

[Fabio Massimo Di Nitto (fabbione)]

Note for X maintainers:

Edgy should grow a check for available videoram and DRI combinations.

[reh4c (gene-hoffler)]

Edgy neither checks for video ram limits nor DRI combinations. The default color depth is still 24 bits, so I must manually change it to 16. Also, I've heard that enabling DRI for the mach64 based ATI chips doesn't work in Edgy. I will try to enable DRI tonight using the above procedures and report back.

[audiophyl (audiophyl)]

The instructions given in the OP won't (and shouldn't) work in Feisty Fawn due to changes in the structure of X.org.

As I understand, there are security concerns regarding the mach64.ko DRM module needed for enabling DRI. Of course, there are security concerns with binary blobs, but it's much easier to install some of those!

Enabling DRI with Mach64-based graphics seems to be an important enough topic to have garnered 101 posts and more than 53,000 views at http://ubuntuforums.org/showthread.php?t=7200. Maybe it could be considered more than a "wishlist" item... especially since working code exists and has existed for quite some time.

Might I propose this solution: Build mach64.ko along with the rest of the DRM modules (/lib/modules/$KERNEL/kernel/drivers/char/drm/), but blacklist it in /etc/modprobe.d/blacklist along with an explanation regarding the security concerns. That would make Ubuntu secure by default, but allow the functionality to be easily enabled for those who aren't as concerned with the security implications.

As a side note, the security concerns don't appear to be well documented. By this, I mean that I can't seem to find anything other than "there are security concerns" as an explanation. That sure doesn't help to get the point across! :)

-Philip Barton

[Richard B. (richie)]

Hello!

After many hours of trying to compile the mach64 driver, I am a bit disappointed because I CANT compile it and because this driver isn't shipped with Ubuntu. I am using Ubuntu since Warty successfully on my Desktop. A few weeks ago, I bought an IBM Thinkpad X21, because of its great Linux support. And yes it works great, even not the direct rendering! Thats a shame! And I am not able to compile it (I have given hours away for this).
So please fix this Bug!!!

[Richard B. (richie)]

...and please not until Gutsy releases.

[Alvaro Pintos Pena (alvarop)]

HI !!!

I have this same problem too... It's imposible compile the mach64 driver for the 3D acceleration in feisty. I have been using Ubuntu since Hoary and I would like use it a lot of time because is a very good distro, but I need the 3D acceleration because I use Blender to work in design and with no 3D acceleration sometimes blender crash... I have a compaq evo n400c with a Rage Mobility P/M AGP 2x 8MB . It's a great labtop and works fine in ubuntu... but not the 3D acceleration.

If there aren't any solution I must downgrade to edgy again or try another distro... but i would like stay in ubuntu. I attached the log with the error alcompile the mach64 driver.

PLease, any solution to this bug??

[Ralf Meyer (ranf)]

Alvaro,

linux/config.h was removed from the linux kernel source in version 2.6.19.

So you should simply remove or uncomment the include line:
En el fichero incluído de /usr/src/mach64-20060403-linux.i386/drm/linux-core/drm_auth.c:36:

[Alvaro Pintos Pena (alvarop)]

Ralf, very thanks for your help.

I did most removed the linux/config.h entry from various files but now I have another problem that I couldn't revolv it:

/usr/src/mach64-20060403-linux.i386/drm/linux-core/drm_stub.c:51: error: size of array ‘type name’ is negative

In the log appears the complete problem. Very thanks again for your help

[Alvaro Pintos Pena (alvarop)]

Sorry, I forget it!

This is the drm_stub.c:51:

module_param_named(debug, drm_debug, int, S_IRUGO|S_IWUGO);

[Alvaro Pintos Pena (alvarop)]

Well , I deleted the 51 line of the drm_stub.c file and compile without any problem!!
Now I have the 3D acceleration in my compaq evo n400c in feisty!!!

Thank's a lot!! If anyone have a problem to compile the driver I can help to do it :)

[audiophyl (audiophyl)]

The main problem I can see with what you're trying is that you're using
sources that area over one year old. "mach64-20060403-linux.i386" = 3rd of
April, 2006. Check
http://ubuntuforums.org/showthread.php?p=2399695#post2399695 for more
current information (this may not work with 6.10, but does work with 7.04)

-Philip

On 5/15/07, Alvaro Pintos Pena <email address hidden> wrote:
>
> Ralf, very thanks for your help.
>
> I did most removed the linux/config.h entry from various files but now I
> have another problem that I couldn't revolv it:
>
> /usr/src/mach64-20060403-linux.i386/drm/linux-core/drm_stub.c:51: error:
> size of array 'type name' is negative
>
> In the log appears the complete problem. Very thanks again for your help
>
> ** Attachment added: "log mach64 compile"
> http://librarian.launchpad.net/7649730/dri.log
>
> --
> DRI not Automatically Enabled for ATI Rage Mobility P/M - Mach64
> https://bugs.launchpad.net/bugs/34590
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Alvaro Pintos Pena (alvarop)]

Thanks audiophyl!

But finally I could compile the driver mach64-20060403-linux.i386 and now I have the 3D acceleration :)

anyway, which is the diffrence between this version of the driver and the other?

[audiophyl (audiophyl)]

the version you are compiling is geared towards either x.org 6.9 or 7.0, the
newer versions (used in 7.04 and such) are for x.org 7.2. you could search
around at freedesktop.org for a list of things that have changed in the
architecture, as well as specifics for the mach64 driver.

-Philip

On 5/16/07, Alvaro Pintos Pena <email address hidden> wrote:
>
> Thanks audiophyl!
>
> But finally I could compile the driver mach64-20060403-linux.i386 and
> now I have the 3D acceleration :)
>
> anyway, which is the diffrence between this version of the driver and
> the other?
>
> --
> DRI not Automatically Enabled for ATI Rage Mobility P/M - Mach64
> https://bugs.launchpad.net/bugs/34590
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Matt Hoy (old-pink)]

http://ubuntuforums.org/showthread.php?p=3047138#post3047138

Could we PLEASE see this in Gutsy?

Possibly with the aid of restricted driver management?

Or a working guide for feisty? The guides are so outdated it's literally impossible to get anything to even remotely work, we need a good, new walkthrough.

[dougfractal (dougs-b)]

This bug seems to be a major annoyance to ATI Rage Mobility P/M - Mach64 users.

I've created a script that may help many users.
http://ubuntuforums.org/showpost.php?p=3090744&postcount=161

card database
http://ubuntuforums.org/showpost.php?p=3090744&postcount=162

NOTES:
audiophyl has directions on creating more up-to-date drivers but is longer, I've tried to create an install, in a few clicks.

[Matt Hoy (old-pink)]

I do not recommend the use of dougfractal's above script.

It rendered my system unusable, with Xorg broken, the ati driver package broken and no means of restoring it, with the backups all pointing to the destroyed ati driver.

I had to download xserver-xorg-video-all and xserver-xorg-video-ati onto a memory stick from my other computer, purge them on the laptop in terminal then use sudo dpkg -i to reinstate them.

Without another computer or a cable connection, and decent knowledge of terminal commands, you will not be able to recover your system, and may be forced to reinstall.

Just hold out for an appearance in Gutsy, or use Mepis.

[dougfractal (dougs-b)]

Matt Hoy, I'm sorry that it doesn't work for you. But i386DX http://ubuntuforums.org/showthread.php?p=3089287#post3089287 has confirmed that it works for your card with no problems.I believe that problem is in damage to the files from previous attempts or incomplete troubleshooting.

Matt Hoy has been been very negative about many community members advice, for example; kfazz, http://ubuntuforums.org/showthread.php?t=406389.

Matt Hoy has been told by many members to reinstall because of self-damage to his system, but refuses to. He carries on using howtos and complains when they don't work.

My experience with helping him, tells me that he selectively uses parts of howtos without following the whole guide.
He even has stated that my copy/paste script broke his networking.
As any intelligent user could read from the script that this is not possible.

So please use mine http://ubuntuforums.org/showpost.php?p=3090744&postcount=161 or audiophyl's http://ubuntuforums.org/showthread.php?p=2399695#post2399695 guide and feedback on your experience.

[Matt Hoy (old-pink)]

Damage to files from previous attempts and incomplete troubleshooting is a weak defence. Think about it, I purged and reinstalled everything you said to reinstall, even X and everything releated, taking an extra step, and your guide overwrote all nessecary files. So there are no "old files" remaining in the equation, after running your script.

I was negative about two parts of advice. One that was old, badly laid out, hard to follow and broke a previously working part of my system, so I felt it was only right to wrn others to avoid the guide, and yours, which although new broke even more of my system, and you had requested feedback.

I've never been told by anyone to install, apart from to fix glxinfo, which I fixed myself, without an install. You, nor any of the guides you work with (or steal from) have mentioned reinstalling. Never. Do not lie.

I use the whole how to. Both as a whole paste after activating sudo, and when that doesn't work line by line, to see where it goes wrong. And yes, I stated your copy/paste script "broke" my networking. GUI interface Network Manager is used to configure wireless, the GUI depends on X, you broke X, left me with a terminal, and no working networking to redownload X for reinstallation. Chances are this has happened to many other WiFi users and they're so stuck without a computer you just haven't heard back from them.

And you ended asking for feedback again. But if you are provided with any slightly negative feedback, you'll simply deny it's truth, your guide couldn't possibly be at fault, could it?

My advice? Don't use the guide. It broke my system beyond use, and it was only by chance I had another computer I could get it back. You may be lucky enough to have wired networking. However, dougfractal doesn't even own the card, he hasn't tested it himself, he's just compiling old guides into forms of his own and when your setup already working really well, just without the extra of direct rendering, I think I'd rather just live with a less than outstanding video performance than risk losing it all.

Chances are it'll be in Gutsy anyway.

[Bradly Wilson (mocoloco)]

So can someone confirm yes or no on mach64 in Gutsy? I can't find a definite answer anywhere. I agree this is more than a wishlist item, I now have 3 machines with this chip, and I've only been able to get DRI working on 2 of them. Anyone who's in the know it would be great to have a confirmation of the rumors.

[audiophyl (audiophyl)]

The reason you won't see it in Gutsy is that Mach64's DRM module is not within the vanilla kernel sources. You can confirm this by checking git.kernel.org. For the current kernel release, the link is http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=tree;f=drivers/char/drm;hb=HEAD.

None of the source files there are related to Mach64.

The best course of action would likely be to lobby the dri.freedesktop.org maintainers to submit Mach64 DRM sources to the Linux kernel maintainers to be included as 'EXPERIMENTAL'. Once Mach64 sources are included with the Linux kernel sources, you can likely expect to see the module included in Ubuntu.

[Jay De Souza (the-digital-journalist)]

Matt Hoy was right, I tried the Mach64 script twice and on both occasions it broke my OS and I had to perform a reinstallation in order to restore a working Feisty Fawn. As with an earlier poster, I also have several machines with this chipset, so hopefully we'll see some progress on this front eventually...

[dougfractal (dougs-b)]

noted: I've grayed the script. pointed to an updated version of the script using the newer xf86-video-ati-6.7.192.tar.bz2 (26-Aug-2007)
but alex.bb http://ubuntuforums.org/showpost.php?p=3274249&postcount=172 in my view has the best method.
using fiesty-backports and audiophyl's compiled kernel modules drm.ko and mach64.ko compiled from drm sources freedesktop.org

[Jay De Souza (the-digital-journalist)]

Thanks doug, only thing is that alex assumes everyone using his guide is totally proficient with Linux procedures and unfortunately this is not the case for me as a "newcomer"...

"You needs three things:
- backported xserver-xorg-video-ati 6.6.193 from gutsy compiled with --enable-dri
- backported xserver-xfree-core 1.3 from gutsy (depended from xserver-xorg-video-ati)"

After a google I worked out backporting/ported is but which command do I use to achieve this please?

[Peter Rhone (prhone-gmail)]

alex.bb's method may work well in feisty, but I need this to work in gutsy... has anyone gotten this working in gutsy yet? I've been trying since yesterday and have probably made a huge mess of the system in the process :-(

[alex.bb (alex-bb)]

I built deb-packages for also for gutsy:

http://www.bakarasse.de/mach64-howto.html

see http://ubuntuforums.org/showpost.php?p=3765722&postcount=192

I hope that this works also.
Alex

[jotronic (jotronic)]

I couldn't really follow the howto and got stuck at the " Package xserver-xorg-video-ati backported from gutsy and compiled with --enable-dri ". However, I just installed the "Hardy" - Alpha and of course no DRI support for mach64. Is this Bug beeing ignored?

[audiophyl (audiophyl)]

In Gutsy all you need to compile is the mach64.ko DRM module (git'd from
freedesktop.org), as all of the other modules are compiled 'correctly'. It
is possible this is all that matters in Hardy, as well.

The main reason nothing can realistically be done about this bug (which
pains me!) is the fact that mach64.ko is not part of the Linux kernel
source. While X.org moves to DRI2, we could see this resolved. Presently,
mach64.ko (DRI/DRM for Mach64) is not considered to be a 'secure' module. I
have no idea why this is.

-Philip Barton

On Dec 1, 2007 9:38 PM, jotronic <email address hidden> wrote:

> I couldn't really follow the howto and got stuck at the " Package
> xserver-xorg-video-ati backported from gutsy and compiled with --enable-
> dri ". However, I just installed the "Hardy" - Alpha and of course no
> DRI support for mach64. Is this Bug beeing ignored?
>
> --
> DRI not Automatically Enabled for ATI Rage Mobility P/M - Mach64
> https://bugs.launchpad.net/bugs/34590
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Henrik Nilsen Omma (henrik)]

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.
According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .
The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). If the state of this bug should change such that it qualifies for the SRU process, please contact the person who originally declined it and ask them to re-evaluate it. To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage .

[Matt Hoy (old-pink)]

On 12/2/07, Henrik Nilsen Omma <email address hidden> wrote:
>
> This bug was nominated for Gutsy but does currently not qualify for a 7.10stable release update (SRU) and the nomination is therefore declined.
> According the the SRU policy, the fix should already be deployed and
> tested in the current development version before an update to the stable
> releases will be considered. With 7.10 now released, that policy applies
> to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .
> The bug is not being closed as work will continue on fixing it for the
> next release, Hardy Heron (8.04). If the state of this bug should change
> such that it qualifies for the SRU process, please contact the person who
> originally declined it and ask them to re-evaluate it. To help improve the
> state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage .
>
>
>
Good to know this is being worked on for Hardy, but is there any chance of
seeing it in the backports before then?

--
Matt Hoy
TopicalMatt.com

[Henrik Nilsen Omma (henrik)]

Changing the kernel task from 'linux-source-2.6.15' to 'linux', which is the relevant one for hardy. Setting it back to incomplete until we get confirmation of the problem in hardy. Could those with this hardware please test? Thanks!

[Tormod Volden (tormodvolden)]

The mach64.ko module is not in Hardy nor in the official kernel tree at this point.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/char/drm;hb=HEAD
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=tree;f=drivers/char/drm;hb=HEAD

However, it has recently been worked on in the upstream DRI project.
http://marc.info/?l=dri-users&m=119663012906996&w=2

If you want to try out the upstream git version on your own kernel, and you know what you're doing, you may find the easy-drm-modules-installer from https://wiki.ubuntu.com/XorgOnTheEdge convenient.

[Roland (roland1979)]

I second that. Just trying to get my old laptop with an ATI mach64 mobility to work in DRI mode in hardy alpha 6, but no chance. mach64.ko is still missing and I'm not able to compile the rather old snapshots from http://dri.freedesktop.org/snapshots/ due to compilation problems with the hardy kernel.

Any idea when this will be fixed for hardy? There isn't much time left.

[audiophyl (audiophyl)]

I may be off on the dependencies (only the Linux kernel headers, GCC & make
stuffs, and git, I believe), but you should be able to get by in Feisty and
Hardy with minimal building from sources. From what I can tell nothing
needs to be compiled except mach64.ko, and drm.ko needs a recompilation.

The instructions are fairly straight-forward (assuming you've already
apt-get'd the aforementioned stuffs):

(terminal)
git clone git://anongit.freedesktop.org/git/mesa/drm
cd drm/linux-core
make mach64.o (that's not a typo, and this builds drm.ko & mach64.ko)
sudo cp *.ko /lib/modules/<kernel version>/kernel/drivers/char/drm/
sudo depmod -n
(reboot and glxinfo | grep "direct")

Oh yeah, and make sure your default bit depth is right ahead of time.
16bpp@1024x768 is the best you can hope for with 8MB. I don't think you can
do much of anything with 4MB.

When the kernel is officially updated, a simple depmod will not suffice.
You will need to recompile the mach64.ko module. It doesn't take long. May
as well update the sources, anyhow.

Can someone confirm these instructions from a fresh(er) install, and, more
specifically, post a definitive list for apt-get prior to building?

-Philip

On Mon, Mar 10, 2008 at 6:01 PM, Roland Arendes <email address hidden> wrote:

> I second that. Just trying to get my old laptop with an ATI mach64
> mobility to work in DRI mode in hardy alpha 6, but no chance. mach64.ko
> is still missing and I'm not able to compile the rather old snapshots
> from http://dri.freedesktop.org/snapshots/ due to compilation problems
> with the hardy kernel.
>
> Any idea when this will be fixed for hardy? There isn't much time left.
>
> --
> DRI not Automatically Enabled for ATI Rage Mobility P/M - Mach64
> https://bugs.launchpad.net/bugs/34590
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Roland (roland1979)]

Your hint seems to have brought me one step further. I compiled both modules successfully, rebooted, and now have some lines in the Xorg.log that indicate that DRI should work -

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
(WW) AIGLX: 3D driver claims to not support visual 0x25
(WW) AIGLX: 3D driver claims to not support visual 0x26
(WW) AIGLX: 3D driver claims to not support visual 0x27
(WW) AIGLX: 3D driver claims to not support visual 0x28
(WW) AIGLX: 3D driver claims to not support visual 0x29
(WW) AIGLX: 3D driver claims to not support visual 0x2a
(WW) AIGLX: 3D driver claims to not support visual 0x2b
(WW) AIGLX: 3D driver claims to not support visual 0x2c
(WW) AIGLX: 3D driver claims to not support visual 0x2d
(WW) AIGLX: 3D driver claims to not support visual 0x2e
(WW) AIGLX: 3D driver claims to not support visual 0x2f
(WW) AIGLX: 3D driver claims to not support visual 0x30
(WW) AIGLX: 3D driver claims to not support visual 0x31
(WW) AIGLX: 3D driver claims to not support visual 0x32
(II) AIGLX: Loaded and initialized /usr/lib/dri/mach64_dri.so
(II) GLX: Initialized DRI GL provider for screen 0
Atom 4, CARD32 4, unsigned long 4

However, enabling Desktop effects does not work. As you guessed, I have a 1024x768 TFT LCD with 8megs of RAM. I moved to 16bits beforehand.

roland@roland-laptop:/var/log$ glxinfo | grep direct
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb7c61767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7c618b1]
#2 /usr/lib/libX11.so.6 [0xb7cf7421]
#3 /usr/X11R6/lib/libGL.so.1(__glXInitialize+0x596) [0xb7f2d3cc]
#4 /usr/X11R6/lib/libGL.so.1 [0xb7f29fc8]
#5 /usr/X11R6/lib/libGL.so.1(glXChooseVisual+0x29) [0xb7f2b124]
#6 glxinfo [0x8049448]
#7 glxinfo [0x8049b23]
#8 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7db5450]
#9 glxinfo [0x8048d51]
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose.

[audiophyl (audiophyl)]

Unfortunately, even with working DRI you won't be seeing any desktop
effects. Those effects require very specific off-screen rendering
functionality of which Mach64 cards are not capable. You will, however, see
a fairly drastic boost in more 'general' OpenGL functionality.

Your situation brings up another reason why this bug isn't likely to be
closed anytime soon: Mach64 DRI seems to be hit or miss with results being
insignificant to most users.

As for additional tips... no clue, really. In my /etc/X11/xorg.conf I have
the following changed, and I really have no clue if it makes a difference
(meaning I'm too lazy to test, sorry!):

(In Section ServerLayout make sure the following is commented out if it
exists)
#Option "AIGLX" "False"

(The following section may need to be added if it is not present, but I
believe it's there by default in newer Ubuntus)
Section "DRI"
        Mode 0666
EndSection

For more rigorous (and involved) instructions, check for earlier posts from
me in the bug notes. There are instructions for replacing libGL in the case
that it is the culprit. However, I really am hoping the DRM modules were
all that needed to be compiled...

-Philip

On Wed, Mar 12, 2008 at 5:19 PM, Roland Arendes <email address hidden> wrote:

> Your hint seems to have brought me one step further. I compiled both
> modules successfully, rebooted, and now have some lines in the Xorg.log
> that indicate that DRI should work -
>
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 8, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 8, (OK)
> drmOpenByBusid: drmOpenMinor returns 8
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> (WW) AIGLX: 3D driver claims to not support visual 0x23
> (WW) AIGLX: 3D driver claims to not support visual 0x24
> (WW) AIGLX: 3D driver claims to not support visual 0x25
> (WW) AIGLX: 3D driver claims to not support visual 0x26
> (WW) AIGLX: 3D driver claims to not support visual 0x27
> (WW) AIGLX: 3D driver claims to not support visual 0x28
> (WW) AIGLX: 3D driver claims to not support visual 0x29
> (WW) AIGLX: 3D driver claims to not support visual 0x2a
> (WW) AIGLX: 3D driver claims to not support visual 0x2b
> (WW) AIGLX: 3D driver claims to not support visual 0x2c
> (WW) AIGLX: 3D driver claims to not support visual 0x2d
> (WW) AIGLX: 3D driver claims to not support visual 0x2e
> (WW) AIGLX: 3D driver claims to not support visual 0x2f
> (WW) AIGLX: 3D driver claims to not support visual 0x30
> (WW) AIGLX: 3D driver claims to not support visual 0x31
> (WW) AIGLX: 3D driver claims to not support visual 0x32
> (II) AIGLX: Loaded and initialized /usr/lib/dri/mach64_dri.so
> (II) GLX: Initialized DRI GL provider for screen 0
> Atom 4, CARD32 4, unsigned long 4
>
> However, enabling Desktop effects does not work. As you guessed, I have
> a 1024x768 TFT LCD with 8megs of RAM. I moved to 16bits beforehand.
>
> roland@roland-laptop:/var/log$ glxinfo | grep direct
> Locking assertion failure. Backtrace:
> #0 /usr/lib/libxcb-xlib.so.0 [0xb7c61767]
> #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7c61...

[Tormod Volden (tormodvolden)]

Just a tip for those wanting to build DRM modules, the easy-drm-modules-installer script on https://wiki.ubuntu.com/XorgOnTheEdge might be handy.

[Bryce Harrington (bryce)]

since this is a wishlist item for an old graphics chipset that doesn't appear likely to get solved any time soon, I think we should drop the release nomination for it. The bug should stay open though; looks like it's still got activity and is still a valid bug.

[Russell Phillips (ignissport)]

Philip,

Your instructions seem to have worked, except the 'modprobe mach64' command did not work (module not found) until I ran 'depmod -a'. After this, the module loaded, /dev/dri/card0 appeared, and glxinfo told me that DRI was enabled.

Also, I found the mach64 source module was just added to intrepid, which looks promising:
https://launchpad.net/ubuntu/intrepid/+source/xserver-xorg-video-mach64/6.8.0-1

I also downloaded and installed the xserver-xorg-video-mach64 package from the debian repository, and it appears to work (however I still had to manually compile the mach64.ko module as above).

Cheers,

  - Russell.

[Tormod Volden (tormodvolden)]

FYI, the xserver-xorg-video-mach64 package has nothing to do with the drm modules. The old -ati package had the same support for mach64 cards, but is now (Intrepid) split into an -ati package for Radeon cards and a -mach64 package for Rage (Pro) cards (and an -r128 for Rage 128 cards).

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Ralph Janke (txwikinger)]

Unfortunately this bug report is being closed because we received no response to the last inquiry for information. However, the Intrepid Ibex 8.10 Beta release was most recently announced - http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm this is still an issue with this most recent release please feel free to reopen this report. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks.

[goto (gotolaunchpad)]

Hello,
just tested Xubuntu 8.10 and on the Live CD there was DRI working out-of-the-box.
"Direct Rendering: Yes"
I dunno which package would need to be set to 'Fix Released', so I let someone who knows doing this.
Thanks for this!

Only one last question: Are the changes that it works upstream now or only in Ubuntu? Thanks.
OT: (I ask because I installed Debian Etch and it does not work there (compiling doesn't work there, either). Maybe it is just too old. Wanted to install Ubuntu, but the CD drive was broken a bit and the installation wasn't possible due to errors, Debian businesscard worked great.)

[Bryce Harrington (bryce)]

On Mon, Dec 29, 2008 at 10:54:03PM -0000, goto wrote:
> Hello,
> just tested Xubuntu 8.10 and on the Live CD there was DRI working out-of-the-box.
> "Direct Rendering: Yes"
> I dunno which package would need to be set to 'Fix Released', so I let someone who knows doing this.
> Thanks for this!
>
> Only one last question: Are the changes that it works upstream now or only in Ubuntu? Thanks.
> OT: (I ask because I installed Debian Etch and it does not work there (compiling doesn't work there, either). Maybe it is just too old. Wanted to install Ubuntu, but the CD drive was broken a bit and the installation wasn't possible due to errors, Debian businesscard worked great.)

The changes are upstream.

Bryce

[goto (gotolaunchpad)]

Bryce, thanks for the answer.
So we can conclude that in every future distribution, which uses the upstream xorg, mach64 dri will be automatically working?

Is this actually a thing which has to be done in the linux kernel or in xorg? Is the module now by default in the linux kernel?

Thanks again.

[danomatika (danomatika)]

I have a Xybernaut MA-V with an ATI Rage Mobility P/M (rev 64) aka mach64 running Karmic and yes glxinfo "says" direct rendering is enabled, but the OpenGL render string is "Software Rasterizer", glxinfo | egrep "direct rendering|OpenGL renderer" returns:

direct rendering: Yes
OpenGL renderer string: Software Rasterizer

... so I don't think you can mark the bug fixed as yet.

[Tormod Volden (tormodvolden)]

No, it is not fixed. The upstream task is marked as fixed because it was pointing to a security issue blocking the inclusion of mach64 into the main drm repository. However the inclusion did not happen anyway. Meanwhile, the drm code moved to the kernel, and still has no mach64. The Ubuntu task was closed because of missing feedback from the reporter.

If anyone would like to hack on this, the most recent patches I have seen are from Mandriva, see http://forums.opensuse.org/get-help-here/hardware/435228-ati-mach64-2.html

[reh4c (gene-hoffler)]

I'm sorry, but I no longer own this laptop to test if DRI is enabled.  However, I thank you for continuing the effort to solve it.

--- On Fri, 4/23/10, Tormod Volden <email address hidden> wrote:

From: Tormod Volden <email address hidden>
Subject: [Bug 34590] Re: [mach64] DRI not Automatically Enabled for ATI Rage Mobility P/M
To: <email address hidden>
Date: Friday, April 23, 2010, 11:56 AM

No, it is not fixed. The upstream task is marked as fixed because it was
pointing to a security issue blocking the inclusion of mach64 into the
main drm repository. However the inclusion did not happen anyway.
Meanwhile, the drm code moved to the kernel, and still has no mach64.
The Ubuntu task was closed because of missing feedback from the
reporter.

If anyone would like to hack on this, the most recent patches I have
seen are from Mandriva, see http://forums.opensuse.org/get-help-
here/hardware/435228-ati-mach64-2.html

--
[mach64] DRI not Automatically Enabled for ATI Rage Mobility P/M
https://bugs.launchpad.net/bugs/34590
You received this bug notification because you are a direct subscriber
of the bug.

[Sergio Zanchetta (primes2h)]

Thank you for reporting this bug to Ubuntu. Dapper reached EOL, please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please upgrade and test, I'll leave the linux task open for that.

Feel free to report any other bugs you may find.

[reh4c (gene-hoffler)]

I no longer have this laptop, so I can't test it.  Therefore, please close this bug.  Thanks.

________________________________
From: Sergio Zanchetta <email address hidden>
To: <email address hidden>
Sent: Friday, July 29, 2011 5:41 AM
Subject: [Bug 34590] Re: [mach64] DRI not Automatically Enabled for ATI Rage Mobility P/M

Thank you for reporting this bug to Ubuntu. Dapper reached EOL, please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please upgrade and test, I'll leave the linux task open for that.

Feel free to report any other bugs you may find.

** Changed in: linux-source-2.6.15 (Ubuntu)
       Status: New => Won't Fix

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/34590

Title:
  [mach64] DRI not Automatically Enabled for ATI Rage Mobility P/M

To manage notifications about this bug go to:
https://bugs.launchpad.net/dri/+bug/34590/+subscriptions

[reh4c (gene-hoffler)]

<p>life has thrown a few curveballs my way I was quickly running out of options this allows me to spend my paycheck the way I want to !!<br><a href="http://cs-outsiders.cba.pl/ChristopherGreen37.html">http://cs-outsiders.cba.pl/ChristopherGreen37.html</a> ive committed myself to this you would really love this<br>trust me, you will be happy</p>