You are not logged in.

#1 2012-03-15 07:53:00

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

LibGL is NOT a replacement for DRI1 drivers

:: Replace r128-dri with extra/libgl? [Y/n] n

Just because the newest release of mesa includes no DRI1 doesn't mean you have to flag the packages out of date and remove them. The 7.11.2-1 versions were up to date because 7.11.2 is the newest version of r128-dri (for instance) that exists. The proper thing to do would be to build a 7.11.2-2 package on a machine that has an 8.0.1 version of libGL installed and release that. Not trick users into removing their drivers by telling them to replace it with a non-replacement.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#2 2012-03-15 08:04:12

t1nk3r3r
Member
From: The Pacific Northwest
Registered: 2011-03-22
Posts: 79

Re: LibGL is NOT a replacement for DRI1 drivers

I'm not sure the right ppl are going to ever see this...

I suggest:
http://mailman.archlinux.org/mailman/listinfo/
https://wiki.archlinux.org/index.php/IRC_Channels


--------------------------The only wasted day is one in which you learn nothing.--------------------------

Offline

#3 2012-03-15 13:32:46

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: LibGL is NOT a replacement for DRI1 drivers

Take it up with upstream, and/or write your own PKGBUILD. I believe upstream development has stopped, if that's the case its unlikely you'd ever get anyone interested in maintaining it in the repos anyway (assuming it continues to work, which I believe is unlikely after some time).


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#4 2012-03-15 13:58:13

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: LibGL is NOT a replacement for DRI1 drivers

ngoonee wrote:

assuming it continues to work, which I believe is unlikely after some time

According to this, it should work fine. Later in that thread it is said that the libgl interface is stable and the plan is to keep it so. Which means Arch could ship a r128-dri driver compiled from mesa 7.11 source.

I agree with t1nk3r3r though, this should be reported elsewhere, the bug tracker would be the best place I think.

Last edited by Gusar (2012-03-15 13:59:48)

Offline

#5 2012-03-16 05:51:20

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: LibGL is NOT a replacement for DRI1 drivers

Yes, those are the somewhat reassuring answers to my email. I reported this as a bug https://bugs.archlinux.org/task/28938.

And about the pros and cons of offering Arch packages for programs not being developed, there are many current examples. Just look at any program that requires lesstif. Even though some of them have received a very recent update on the Arch side, the upstream releases are very old.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#6 2012-03-16 07:37:22

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: LibGL is NOT a replacement for DRI1 drivers

As you mentioned yourself, mesa dropped r128-dri, so its a matter of being deprecated by that rather than being old per se (old and still working is fine). Regardless, the bug report is the right way to get it back in, though I suspect there will come a point (considering the nature of X) where it just won't work anymore.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#7 2012-03-16 09:54:46

Mr.Elendig
#archlinux@freenode channel op
From: The intertubes
Registered: 2004-11-07
Posts: 4,092

Re: LibGL is NOT a replacement for DRI1 drivers

I suspect that a bug report to get it included is not really going to help, the only thing that can really save the driver is actual contribution upstream. Xorg is short enough on manpower as it is, which is one reasons for why they are deprecating several drivers now.


Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest

Offline

#8 2012-03-16 10:01:13

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: LibGL is NOT a replacement for DRI1 drivers

But the drivers still work, that's the point. Even if they won't receive further development, they work in the current state, they will continue to work, because the libgl interface is stable. Arch includes quite a few things that haven't been worked on in a long time. Because they still work. So it could just as well continue shipping dri1 drivers, all that needs to change is their dependency, from libgl=7.11 to just libgl

Last edited by Gusar (2012-03-16 10:04:51)

Offline

#9 2012-03-16 21:24:03

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: LibGL is NOT a replacement for DRI1 drivers

And one final recompilation with --disable-shared-dricore as I just found out.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#10 2012-03-20 21:36:32

Birkov
Member
Registered: 2011-10-26
Posts: 21

Re: LibGL is NOT a replacement for DRI1 drivers

Conner, I used your PKGBUILD with extra/mesa 8.0.1-2 [installed] and extra/libgl 8.0.1-2 [installed] and did:

# pacman -U mach64-dri-7.11.2-1-i686.pkg.tar.xz

to install the new package, rebooted and got a blank screen and a non-responsive keyboard again.

Problem seems to be solved after downgrading some other packages:

# cd /var/cache/pacman/pkg/
# pacman -U xorg-server-common-1.11.4-1-i686.pkg.tar.xz xorg-server-1.11.4-1-i686.pkg.tar.xz xorg-server-utils-7.6-2-any.pkg.tar.xz xf86-input-evdev-2.6.0-4-i686.pkg.tar.xz xf86-input-keyboard-1.6.1-1-i686.pkg.tar.xz xf86-input-mouse-1.7.1-2-i686.pkg.tar.xz xf86-video-mach64-6.9.0-3-i686.pkg.tar.xz

(still using the new mach64-dri-7.11.2-1-i686.pkg.tar.xz)

# pacman -Syu

Still wants to replace mach64-dri with libgl, fixed that in /etc/pacman.conf

Oh, and great things don't come in tar.xz packages (see libgl and streamtuner), they come from PKGBUILD's ;-)

Offline

#11 2012-03-21 02:11:29

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: LibGL is NOT a replacement for DRI1 drivers

Are you sure that has to do with the old DRI package? The new Xserver package fails that way for me but it still does so when I use xf86-video-r128 alone.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#12 2012-03-21 02:46:35

Birkov
Member
Registered: 2011-10-26
Posts: 21

Re: LibGL is NOT a replacement for DRI1 drivers

Not sure what you mean with the old DRI package but downgrading with

# pacman -U /var/cache/pacman/pkg/libgl-7.11.2-1-i686.pkg.tar.xz /var/cache/pacman/pkg/mach64-dri-7.11.2-1-i686.pkg.tar.xz /var/cache/pacman/pkg/mesa-7.11.2-1-i686.pkg.tar.xz

gave me a blank screen and a non-responsive keyboard after reboot. Recompiled mach64drm and the problem didn't go away.

So I updated everything, build the new mach64-dri package from your PKGBUILD which unfortunately has the same number as the old one and gave that a try. Got a blank screen and a non-responsive keyboard after reboot.

Downgraded with

# pacman -U xorg-server-common-1.11.4-1-i686.pkg.tar.xz xorg-server-1.11.4-1-i686.pkg.tar.xz xorg-server-utils-7.6-2-any.pkg.tar.xz xf86-input-evdev-2.6.0-4-i686.pkg.tar.xz xf86-input-keyboard-1.6.1-1-i686.pkg.tar.xz xf86-input-mouse-1.7.1-2-i686.pkg.tar.xz xf86-video-mach64-6.9.0-3-i686.pkg.tar.xz

and kept the new mach64-dri, rebooted and everything worked fine.

Just removed mach64-dri from the IgnorePkg-line in /etc/pacman.conf and got this:

# pacman -Syu
:: Synchronizing package databases...
core                                                                 104.9 KiB   543K/s 00:00 [#######################################################] 100%
extra                                                               1383.4 KiB  1094K/s 00:01 [#######################################################] 100%
community                                                           1630.7 KiB  1086K/s 00:02 [#######################################################] 100%
:: Starting full system upgrade...
:: Replace mach64-dri with extra/libgl? [Y/n]

I can try to upgrade xf86-video-mach64 from 6.9.0-2 => 6.9.0-3 and keep the above xorg-packages if you want to know what that does.

The guy that opened this thread https://bbs.archlinux.org/viewtopic.php?pid=1074943 has the same problem as me but he doesn't use mach64drm form AUR.
I use xf86-video-mach64, mach64-dri and mach64drm. Never removed the mach64drm package.

Sorry if I don't understand you correct, my english is a bit poor. But if you give me instructions like:

# pacman -Rns mach64drm
# shutdown -r now

or

# pacman -U /var/cache/pacman/pkg/mach64-dri-7.11.2-1-i686.pkg.tar.xz
# shutdown -r now

I will try and give you the results.

Offline

#13 2012-03-21 02:57:44

Birkov
Member
Registered: 2011-10-26
Posts: 21

Re: LibGL is NOT a replacement for DRI1 drivers

Ps

# pacman -Qi libgl

looks a bit weird now:

Name           : libgl
Version        : 8.0.1-2
URL            : http://mesa3d.sourceforge.net
Licenses       : custom
Groups         : None
Provides       : None
Depends On     : libdrm>=2.4.31  libxxf86vm>=1.1.1  libxdamage>=1.1.3  expat>=2.0.1  libglapi  gcc-libs
Optional Deps  : None
Required By    : libva  mach64-dri  mesa  mplayer  qt  snes9x-gtk  xorg-xdriinfo
Conflicts With : None
Replaces       : unichrome-dri  mach64-dri  mga-dri  r128-dri  savage-dri  sis-dri  tdfx-dri
Installed Size : 18733.00 KiB
Packager       : Andreas Radke <andyrtr@archlinux.org>
Architecture   : i686
Build Date     : Fri 09 Mar 2012 09:40:07 PM CET
Install Date   : Tue 20 Mar 2012 07:35:31 PM CET
Install Reason : Installed as a dependency for another package
Install Script : No
Description    : Mesa 3-D graphics library and DRI software rasterizer

Edit: I suggest renaming the mach64-dri package from your PKGBUILD to mach64-dri1 to solve above conflict.

Last edited by Birkov (2012-03-21 03:07:41)

Offline

#14 2012-03-21 03:17:21

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: LibGL is NOT a replacement for DRI1 drivers

Yeah there's nothing I can do about that libgl weirdness since my bug report was closed. You have the setup that I would recommend. DON'T switch xf86-video-mach64 from 6.9.0-2 to 6.9.0-3.

All I'm saying is that the blank screen error seen by you, me and Stutz Jr has nothing to do with DRI. I think it is purely an Xserver bug.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#15 2012-03-21 10:03:29

0mark
Member
From: earth
Registered: 2010-06-09
Posts: 162
Website

Re: LibGL is NOT a replacement for DRI1 drivers

Ive got the same problem, but i lack the old packages to downgrade. Can someone upload them please?


Ceterum autem censeo Systemdinem esse delendam

Offline

#16 2012-03-21 10:42:09

skunktrader
Member
From: Brisbane, Australia
Registered: 2010-02-14
Posts: 1,538

Re: LibGL is NOT a replacement for DRI1 drivers

0mark wrote:

Ive got the same problem, but i lack the old packages to downgrade. Can someone upload them please?

https://wiki.archlinux.org/index.php/Do … er_Version

Offline

#17 2012-04-14 07:13:06

qwertypoke
Member
Registered: 2011-09-06
Posts: 28

Re: LibGL is NOT a replacement for DRI1 drivers

This is not the first time a similar problem has arisen with older hardware. I personally agree generally with the reasons why Arch maintainers do not want to deal with this kind of issues. I also believe that Mesa developers have also their reasons to stop support for our cards. I still hate that old working hardware looses it's usability due to software issues and I hope this kind of decisions would be really well considered (upstream in this case I think) before making. Disabling dri is not a real solution if you are not ready to loose heavily on performance.

I personally bet that Arch or Mesa development/support will not do anything to get these older cards supported again in future versions, The next best thing would probably be find out the best way to keep this hardware alive as long as possible. This would include some instructions and possibly something in AUR. It would be also a good idea to include more informative messages in the package information for mesa, xorg etc. so that undesired surprises when upgrading could be more easily avoided.

What is the best way to keep on using this hardware on Arch in your opinion?

This is what I have done so far to get my chromium-bsu working again on my Matrox G550 after full system upgrade:
The package files are in /var/cache/pacman/pkg.

[2012-04-13 22:10] Running 'pacman -U mesa-7.11-2-i686.pkg.tar.xz'
[2012-04-13 22:10] upgraded mesa (8.0.2-1 -> 7.11-2)
[2012-04-13 22:11] Running 'pacman -U libgl-7.11-2-i686.pkg.tar.xz'
[2012-04-13 22:11] upgraded libgl (8.0.2-1 -> 7.11-2)
[2012-04-13 22:11] Running 'pacman -U mga-dri-7.11-2-i686.pkg.tar.xz'
[2012-04-13 22:11] installed mga-dri (7.11-2)
[2012-04-13 22:51] Running 'pacman -R xf86-video-vesa'
[2012-04-13 22:51] removed xf86-video-vesa (2.3.1-1)
[2012-04-13 22:51] Running 'pacman -R xf86-video-mga'
[2012-04-13 22:51] removed xf86-video-mga (1.5.0-1)
[2012-04-13 22:53] Running 'pacman -U xf86-input-evdev-2.6.0-4-i686.pkg.tar.xz'
[2012-04-13 22:53] upgraded xf86-input-evdev (2.7.0-2 -> 2.6.0-4)
[2012-04-13 22:53] Running 'pacman -U xorg-server-1.11.2-2-i686.pkg.tar.xz'
[2012-04-13 22:53] upgraded xorg-server (1.12.0-1 -> 1.11.2-2)
[2012-04-13 22:58] Running 'pacman -U xf86-video-mga-1.4.13-4-i686.pkg.tar.xz'
[2012-04-13 22:58] installed xf86-video-mga (1.4.13-4)
[2012-04-13 22:59] Running 'pacman -U xf86-video-vesa-2.3.0-7-i686.pkg.tar.xz'
[2012-04-13 22:59] installed xf86-video-vesa (2.3.0-7)

I also added following to pacman.conf:

IgnorePkg   = mesa libgl mga-dri xf86-input-evdev xorg-server xf86-video-mga xf86-video-vesa

Offline

#18 2012-04-14 08:23:54

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: LibGL is NOT a replacement for DRI1 drivers

That will keep you safe but you don't have to freeze that many packages if you're careful. First off, the DDX bug that was causing several Archers to see a blank screen with 1.12 has been fixed. Therefore you can unfreeze xorg-server, xf86-video-vesa and xf86-input-evdev. In order to make sure xf86-video-mga works with it, you will have to recompile the newest version with --enable-dri. Keep doing this every time a new Xserver comes out.

Mesa and libgl can also be upgraded BUT in order to unfreeze them, you will have to recompile mga-dri once. Use the old 7.11 PKGBUILD to do this. You have to change the libgl=7.11 requirement to just libgl and add --disable-shared-dricore to the configure flags. After this, you SHOULD have the final version of mga-dri that will be stable against changes to libgl.

So there's one package that you have to rebuild once, and one package that you have to keep rebuilding, then everything else should be fine with the repo versions.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#19 2012-04-14 11:53:31

qwertypoke
Member
Registered: 2011-09-06
Posts: 28

Re: LibGL is NOT a replacement for DRI1 drivers

Thank you ConnorBehan. The situation seems much better than I feared first. I can live with this solution.

Offline

#20 2012-04-14 16:19:45

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: LibGL is NOT a replacement for DRI1 drivers

qwertypoke wrote:

Thank you ConnorBehan. The situation seems much better than I feared first. I can live with this solution.

My thanks also to you and ConnorBehan for making sense out of this situation. Hopefully I can keep several older systems going with these tips; nothwithstanding the dri problem they are performing just fine with the latest Arch updates!
wink

Offline

#21 2012-04-15 14:29:00

qwertypoke
Member
Registered: 2011-09-06
Posts: 28

Re: LibGL is NOT a replacement for DRI1 drivers

I can confirm that ConnorBehan's excellent instructions worked on my Matrox G550 system.

I had a hard time searching for the PKGBUILD for mga-dri as it was contained in a larger PKGBUILD. I found this:

http://pastebin.com/QgEk4CqT

I do not know where it is from or who made it... Anyway --disable-shared-dricore was already flagged and it compiled and installed fine.

The xf86-video-mga was easier. I installed abs and changed --disable-dri to --enable-dri in the PKGBUILD for xf86-video-mga. It also compiled and installed ok.

I have only xf86-video-mga listed in pacman.conf's IgnorePkg (to prevent accidental overwrite of the dri-enabled version), everything is up-to-date and dri is working. smile smile

Here is the documentation for ABS for those who are not familiar with it:
https://wiki.archlinux.org/index.php/Arch_Build_System

Last edited by qwertypoke (2012-04-15 16:01:24)

Offline

#22 2012-06-22 00:09:23

ismaelvc
Member
From: México, D.F.
Registered: 2012-02-26
Posts: 136

Re: LibGL is NOT a replacement for DRI1 drivers

Thanks a lot, I will try to build the latest mach64-dri and rebuild the xf86-video-mach64, for every new release of X, do I have to rebuild mach64drm also or just keep it like mach-dri?, I will also try the r128 driver, never used it before, but in other distros it is either ati or mach64 the ones that get used(puppy linux for example)

VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Rage Mobility P/M AGP 2x (rev 64)

Laptop: LG LM70 Express                                                  Kernel: 3.14.2-1-ARCH   
CPU: Intel Pentium M processor @1.86GHz                  Hard Drive: 80G
Video: Mobility Radeon X600                                            X Driver: xf86-video-ati
Memory Size: 1.5G + zramswap: 384M + swap: 3G

Offline

#23 2012-06-27 11:11:54

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: LibGL is NOT a replacement for DRI1 drivers

Just saw that DRI1 drivers were put into the Community repo. Awesome.

Last edited by Gusar (2012-06-27 12:28:02)

Offline

#24 2012-06-27 17:44:21

ismaelvc
Member
From: México, D.F.
Registered: 2012-02-26
Posts: 136

Re: LibGL is NOT a replacement for DRI1 drivers

I'm glad! I'll just wait a few hours to try building again: xf86-video-mach64 with "--enable-dri" because abs isnt connecting for me right now.


Laptop: LG LM70 Express                                                  Kernel: 3.14.2-1-ARCH   
CPU: Intel Pentium M processor @1.86GHz                  Hard Drive: 80G
Video: Mobility Radeon X600                                            X Driver: xf86-video-ati
Memory Size: 1.5G + zramswap: 384M + swap: 3G

Offline

#25 2012-06-28 01:46:29

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,354

Re: LibGL is NOT a replacement for DRI1 drivers

Gusar wrote:

Just saw that DRI1 drivers were put into the Community repo. Awesome.

May have something to do (didn't check myself) with the fact that ConnorBehan is now a TU smile


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

Board footer

Powered by FluxBB