On Tue, Oct 14, 2008 at 7:15 AM, Pierre Schmitz wrote:

Am Dienstag 14 Oktober 2008 09:05:23 schrieb Jan de Groot:

...

I don't wish to wait for new non-free drivers, as the non-free vendors don't give any information about X.Org 7.4 support on their roadmap. We can wait for 6 months if we keep waiting on this.

I agree here. Neither AMD nor NVIDIA seem to publish any information about xorg 7.4 support yet. So we just have to assume they will never supoort it.

Let's go for it. Just make sure to have an announcement before with some workaround for users of such affected hardware.

+1 Although I am a Nvidia user I agree that we can not wait. We just need to make sure to add an announcement on the website, forum and ML. -- Hugo

On Wed, Oct 15, 2008 at 7:38 AM, Pierre Schmitz wrote:

Am Mittwoch 15 Oktober 2008 01:33:33 schrieb James Rayner:

...

It'd be a good idea to set conflicts=() with the older nvidia/catalyst so that their xorg doesnt get upgraded, and thus their X isn't broken. That way we don't piss off a lot of people.

Maybe not a bad idea. But I would add a depends('xorg-server<1.5') to those drivers. And if some day those drivers work again we just have to update those.

You can use versioned conflicts, so you would not have to update the xorg-server package when a driver works again, because it will very likely be a newer version of it. But then it is not clear when it is safe to remove these conflict lines in xorg-server. So I agree that the depends way still looks nicer.

2008/10/16 Jan de Groot :

On Tue, 2008-10-14 at 09:05 +0200, Jan de Groot wrote:

...

I would like to move xorg to extra soon. The state of X.org in testing is a lot better than the packages in extra. This means problems for some users though:

- nvidia-96xx doesn't work - nvidia-71xx doesn't work - catalyst doesn't work

All the other drivers should work fine, as they're either opensource drivers or binary drivers that support X.Org 7.4 by now. People affected by this should either stick with the old xorg-server or install free drivers with support for their hardware.

I don't wish to wait for new non-free drivers, as the non-free vendors don't give any information about X.Org 7.4 support on their roadmap. We can wait for 6 months if we keep waiting on this.

I just got mail from a user claiming catalyst 8.10 working with Xorg 7.4 which is also in OpenSuSE 11.1 beta2.

OK, I see you've updated catalyst to Ubuntu's secret version :-) which supports Xorg 1.5 according to Phoronix. So... is it ok to release Xorg 1.5 now? -- Roman Kyrylych (Роман Кирилич)

Am Sun, 19 Oct 2008 15:51:40 +0200 schrieb Jan de Groot :

There's still some issues with catalyst: - the libdrm.so symlinking crap is weird, I got different reports about ati and/or xorg version of this one working - somehow the ATI driver looks in /usr/lib/dri instead of /usr/lib/xorg/modules/dri.

Besides that, I'd like to have some wiki documentation about the input hotplugging so people know how to tune it or turn it off if they don't want it.

Some notes from 8.55-080930a-070555E-ATI driver from the Ati beta mailing list: Additional notes Installer has changed the default policy when installing for X Version

= 7.

The libraries previously installed to /usr/lib*/xorg/ have now been moved to /usr/lib*/. Consequently, any user running the automatic install will use this new default policy. RedHat RPM installation has been updated to support this new policy. The installer is unchanged for X Version < 7. I still doubt we are allowed to redistribute the beta code Ubuntu ships. I think they got a special exception for their upcoming release. I could upload the license agreement I had to sign somewhere if someone wants to check it. If we are allowed to ship it we should start shipping a catalyst-beta pkg soon just for testing. Another issue I have run into was poor performance with the free Xorg ati driver when we changed from git code to stable release. But I haven't heard of other users running into this. Anyway I will have a look at the latest catalyst and free drivers over the next few days. Anyway I

Am Sun, 19 Oct 2008 17:16:09 +0200 schrieb Jan de Groot :

On Sun, 2008-10-19 at 17:06 +0200, Andreas Radke wrote:

...

I still doubt we are allowed to redistribute the beta code Ubuntu ships. I think they got a special exception for their upcoming release. I could upload the license agreement I had to sign somewhere if someone wants to check it.

If this is a problem, we should move my new PKGBUILD to AUR so people can download it from ubuntu themselves and package it. We're not violating any license then, as Ubuntu is the one providing the prerelease driver. You might want to ask on the beta mailinglist if we're allowed to ship the ubuntu driver.

...

If we are allowed to ship it we should start shipping a catalyst-beta pkg soon just for testing.

I don't think AMD will agree on shipping beta versions each and every time. I think this driver is an exception because it makes the difference between not working at all or working untested.

...

Another issue I have run into was poor performance with the free Xorg ati driver when we changed from git code to stable release. But I haven't heard of other users running into this.

I got reports from a user that -git works with snapshots taken at 20081010 (later ones have issues again), so I'm thinking about updating the snapshot to that date again.

Another thing is that The 2.5.0 intel driver will get released tomorrow. There's a new 2.4.0 version of libdrm that has to be used with that new driver. So far everything looks good, but it might be worth to test this thing a bit (yes, I still get random crashes with 2.4.2 in some cases).

We are allowed to ship the Ubuntu based driver packages _this time_ as an exception: "Marsan, Luugi" : Feel free the use the driver with your packaging scripts. However, you should know that you can expect a beta driver in a day or two. It will be targeted for Catalyst 8.11. Regards, Luugi --------------- Thanks for your answer. To clarify: is this an exception to allow us only this time to distribute that (taken from Ubuntu) prerelease driver? Or would you allow us to distribute every beta driver packaged for more public testing giving you also more feedback? -Andy -------------- "Marsan, Luugi" : This whole situation was an exception. You CAN NOT distribute the beta drivers with the watermark. The driver given to Ubuntu was a "production" driver, without the watermark and that is why you can include it in your distribution. Do not distribute drivers given to the beta mailing list. This is a clear statement. Now Xorg move shouldn't be far away anymore. We will try to make the best out of the "Ubuntu based prerelease" driver for now and we will have to wait for final 8.11 driver for further improvements. -Andy

On Fri, 2008-10-31 at 02:34 +0100, Pierre Schmitz wrote:

Am Dienstag 14 Oktober 2008 09:05:23 schrieb Jan de Groot:

...

- nvidia-96xx doesn't work - nvidia-71xx doesn't work

Finally, nvidia has released legacy drivers for xorg 7.4. They are in beta state but better than nothing.

http://www.nvnews.net/vbulletin/showthread.php?t=122140 http://www.nvnews.net/vbulletin/showthread.php?t=122139

Ah, good. Can someone update them to testing? At this moment, we have some issues holding back the release: 1. xorg-server-1.5.2-3 gives a warning on install/upgrade, though harmless, it generates bugreports from concerned users 2. xf86-video-intel-2.5.0 seems to have problems with DRI on some chips 3. libdrm 2.4.0 seems to cause problems with compositing 4. kernel needs a patch for G4* support, Xorg will crash without the patch I updated libdrm to 2.4.1 which should fix some symbol conflicts with Mesa on Intel chips. This could fix point 2, which will possibly also fix point 3. There's also another thing that needs taken care of. X.Org 7.4 on archlinux comes with input hotplugging, which means all your devices setup in xorg.conf are ignored, including keymaps (the hotplugged devices are configured after the ones in xorg.conf, but evdev steals all input events from your configured devices, so the ones in xorg.conf don't get any key or mouse events). I expect another large amount of bugreports about keymaps and mouse configuration if we don't setup some good wiki documentation about this.

On Fri, 2008-10-31 at 12:53 -0500, Aaron "Hussein" Griffin wrote:

So what is the preferred way to configure keymaps now?

Either by disabling the autoconfiguration and using the old method, or copying /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy/ and changing the keymap there (hal restart required).

New xorg-server 1.5.3 needs to ahve evdev as a dependency, I just upgraded last night, and after restarting X it froze as hard as to require a hard reboot. Testing what it should have been I experienced hard lockups only when X was started, when I checked the logs Xorg was spitting out errors about evdev module not bein found. So I guess evdev needs to be a dependency. Thanks, Eduardo "kensai" Romero