/srv/irclogs.ubuntu.com/2009/12/01/#ubuntu-x.txt

brycetormod, alpha-1 is dec 10th00:00
sconklinI've seen a number of opinions that graphics got worse from Jaunty->Karmic, I don't want to set up any sort of trend. And also, there are people irate over Fedora because 3d support is not good, but no one really tested 3d until after the release, and I think we'll see the same thing happen.00:00
tormodbryce, which means freeze on 8th00:00
brycetormod, right00:00
brycesconklin, fwiw, every single release we have heard "graphics is worse!"00:01
sconklinAnd if people think it's broken, none of the arguments we've made for going to nouveau will make any sense to them if it 'worked' before.00:01
sconklinbryce: ok, I feel better :) maybe00:01
brycesconklin, what I think happens is we hear from people when things get worse, but not when they get better00:01
tormodmost of the things that got worse in Karmic were introduced around/after FF00:02
sconklinbryce: agreed. It's the same with most kernel drivers. No news is really good news.00:02
jcristautormod: what was that, btw?00:02
tormodkey here is to get things in early and get everybody to test lucid continuously not wait for (late) alphas00:03
sconklinyes.00:03
jcristautormod: (stuff that "got worse" in karmic)00:03
sconklinsome intel drivers got worse, although I think that's mostly resolved now - we froze in the middle of a bunch of changes that came from upstream.00:05
tormodjcristau, there were a few radeon mesa regressions, well I don't know if there was much, u pstart issues got sorted out mostly00:05
jcristauok00:05
brycejcristau, gdm rewrite + upstart post-FF caused failsafe to break horribly; boot speed improvements exposed design flaws in dkms that can result in nvidia.ko not getting built 00:05
jcristauso other than the mesa stuff that's not really X stuff00:05
sconklinalso, there were things like EDID quirke that didn't get migrated from X to the kernel KMS code, which caused apparent regressions (Bryce explained this to me)00:06
brycesconklin, the intel issues - were those the ones just for ironlake / new hardware?00:06
brycesconklin, oh right... still need to get that fixed up00:06
brycejcristau, right X just got caught in the crossfire for the most part00:06
sconklinbryce: no, I think there were some suspend/resume issues that came up with old hardware. That patch is already out for an SRU.00:07
tormodanyway, I think graphics in general got a lot better from Jaunty to Karmic, my "opinion"00:07
brycesconklin, ok00:07
bryceoh also there have been some regressions on older ATI hardware where it falls back to XAA instead of EXA (as a workaround to still other problems)00:08
brycewe should switch to Wayland00:09
bryceit has *so* fewer bugs00:09
jcristauit has *so* fewer users :)00:09
brycejcristau, perfect!00:09
brycebbiab (babysitting time)00:10
sconklinfun times00:12
sconklinRAOF: did you see that I had put up the Fedora kernel patch set for people to browse? There are some additional nouveau patches in there, which may very well now be in the upstream nouveau - I haven't had time to look00:20
RAOFsconklin: I don't think I did see that; is it on ubuntu-x@?00:21
sconklinno, I sent it to the kernel list, hang on for a link.00:22
RAOFOh, whoops.  Yeah, found it.00:22
sconklinhttp://www.ai4qr.com/fedora12kernel/rpmbuild/00:22
sconklinyeah00:22
sconklinare you familiar with rpm's layout?00:22
sconklinnot that you have to go browse patches - I just thought you may be interested00:23
RAOFNo, but it's easy enough to find the patches.00:23
sconklinin SOURCES :)00:23
RAOFSo, they've taken the route of dumping a huge "nouveau" patch on the kernel rather than pulling from the nouveau tree.00:23
sconklinbut there are patches in there that aren't actually used, so be wary00:24
sconklinha, yeah00:24
sconklinand a 2.9M drm-next patch00:24
sconklinit gives me the willies00:25
RAOFOwch, yeah.00:26
pwnguinRAOF: I'm guessing the "nouveau" patch is generated from git for packaging purposes00:34
RAOFpwnguin: as in: git diff nouveau/master?  I'd guess, yes.00:34
pwnguinso the individual patches might still be around00:34
sconklinyeah. If we pull it in, it'll be probably done as a pull to a branch and a rebase, but that's andy's call - he's the git wizard. I know we won't do huge patches like that.00:40
sconklinit's unmaintainable00:40
RAOFAs I say, if we pull from nouveau's kernel tree we pull in (a recent snapshot of) drm-next, too, due to frequent merges.  I don't know how you'd (the kernel team) want to deal with that.00:42
sconklinI already handed that to Andy to think about.00:43
sconklinbut for the moment and for the purposes of the plan, I'm assuming that there's a magic step for making that happen in a sustainable way. It would be a first - we have00:44
RAOFHeh.00:44
sconklinalways taken Linus's tree plus minimal patches00:44
sconklinwe do drop in drivers, but there's never been a situation like there is with drm00:45
RAOFInterrelated drivers, what fun!00:45
RAOFSo, I guess my next action here would be a nouveau DDX package update, so we've got a shiny new snapshot for when the kernel does whatever it's going to do.00:45
Sarvatthmm, where are these patches at?05:27
Sarvatt* Apply Julien Cristau's udev patches. from https://edge.launchpad.net/~pitti/+archive/halsectomy/+packages05:28
Sarvattgrabbed the source for the xorg-server package there but i dont see any new patches in the series, guessing he applied them by hand? i was going to add them to the server in edgers05:29
tjaaltonSarvatt: check the version in experimental05:40
tjaaltonit's there too05:40
Sarvattthanks tjaalton, found it there05:44
=== seb128_ is now known as seb128
=== sconklin1 is now known as sconklin
brycetjaalton, how goes 1.7?  need help merging stuff in?18:15
tjaaltonbryce: pretty well I think. xserver 1.7.2 broke the ABI, so we need to wait for 1.7.3 (which should happen RSN). we could start by syncing the protos from unstable/experimental19:57
tjaaltonand libs too19:57
bryceok19:57
tjaaltonsome of them haven't been uploaded yet, though, but most are19:57
brycecan't most of those just be sync'd?  do we need sync requests?19:57
bryceoh duh, we're syncing from testing, that's why they're not already sync'd19:58
tjaaltonI've updated all the driver repo's, so those are just waiting for the 1.7.3, which should be uploaded to unstable once it's released AIUI19:58
tjaaltonright19:58
tjaaltonso they need manual syncs from unstable/experimental19:58
tjaaltonvery few of them need merging19:58
bryceok, I'll work on those today19:59
tjaaltonbut the most important one is probably xutil-dev which is a pre-req for many of the new versions :)19:59
tjaaltonthe new version of xutil-dev, that is19:59
tjaaltonthe only change we have on it probably makes sense for debian too, but since there's a rush to get all of this in a merge is probably worth it for now20:01
tjaaltonhmm looks like libxxf86{dga,vm} need some fixing until they can be uploaded (moved headers)20:03
tjaaltonI'll fix them shortly, but first something to eat.. ->20:04
Sarvattwell thats no good, 2.6.32 still doesnt suspend/resume right but now I cant use a web browser on the 2.6.31-14 kernel without crashing x and getting this - [drm:i915_gem_object_bind_to_gtt] *ERROR* Invalid object alignment requested 409621:09
marqyhello. i've just upgraded to karmic and i've had a few issues with my graphics driver for my ati radeon 2400.21:11
marqyi waas using fglrx but i couldn't boot the kernal except in safe mode, so i switched to the ati drivers. i still couldn't boot except in safe mode21:12
marqyi turned off the splash screen to get some error messages and the kernal then booted and x has started fine21:13
marqyalthough i don't have 3D rendering in my current state21:13
marqyall in all a bit confused21:13
tormodmarqy, did you remove all the fglrx trash?21:17
marqyi think so, it took a couple of attempts; 21:17
marqybut it'd be nice to know how to be sure21:18
tormodthere is a wiki page https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver21:20
marqytormod: cheers, i had a look.  i took the manual steps to purge: removed xorg-driver-fglrx and reinstalled libgl1-*21:24
marqy$ dpkg -l fglrx21:24
marqyNo packages found matching fglrx21:24
marqybut locate fglrx returns a load of stuff in /usr/src/fglrx-8.561, usr/share/ati, lib/modules, /var/lib/dkms/fglrx and /var/lib/dpkg/info21:25
Sarvattuploading a new libdrm now incase you were in the middle of packaging one tormod lol21:27
Sarvattwas just building it to check on new symbols21:27
tormodSarvatt, cool I am taking a break right now :)21:27
tormodmany intel's yesterday, many mesa's today21:27
tormodSarvatt, are you gonna add the udev patch to xserver?21:28
tormodI forgot to reinstall pitti's after doing a dist-upgrade, and I got pretty screwed :)21:28
Sarvattmore like 10 patches and a bunch of rules changes, haven't had a chance to look it over yet21:28
* bryce is syncreq'ing21:29
Sarvatti dont see the patches in his xserver though21:29
Sarvattthink he applied them by hand21:29
tormodnot even the power button would react :)21:29
tormodyou can debdiff against yours21:29
Sarvattthey're in the debian-experimental git21:30
tormodbut not all the rules are there yet21:30
Sarvattoh? darn gotta dig out the 20091111 server build then21:30
tormodI had to add one for my SynPS protocol touchpad, pitti said jcristau would add it to git21:31
jcristauyeah will be there soonish21:31
tormodit only adds udev support and does not take hal support away, right?21:32
jcristautormod: you can still choose hal at build time21:32
tormodjcristau, but you have to choose one of them?21:32
jcristauyes21:32
jcristauotherwise i don't see how you avoid duplicated events21:33
tormodyeah21:33
brycetjaalton, all protos have sync req's filed21:33
jcristau(also there probably wouldn't be much point.  all linux will use udev, !linux can stay with hal)21:33
brycetjaalton, I also syncreq's x11proto-input which had the XInput.h change - I assume we don't need that change any more, sounds like it got taken into debian at 1.9.99.902-1; let me know if otherwise21:34
tormodjcristau, sure. I just wondered about this transition period with one version in xorg-edgers and another in lucid21:34
Sarvattisn't Xinput.h in libxi-dev now?21:35
bryceSarvatt, that's what 1.9.99.902-1 says, however I'm not sure we have the right version of libxi in ubuntu yet...21:36
* bryce moves on to syncing lib's21:36
tormodSarvatt, I remember that transition upstream in hardy time, a PITA for xorg-edgers...21:36
Sarvattthink we should keep the old versions in edgers or delete them to clean it up tormod?21:39
tormodSarvatt, which old versions?21:39
Sarvatti dont really like the idea of telling people to use lucid sources on karmic like we were doing for jaunty-karmic because it was a nightmare explaining things to people who wanted to build packages21:39
Sarvattthe protos and stuff that are already in lucid21:40
Sarvattcan wittle it down to just the server eventually21:40
tormodoh yes if it obsoleted by main it should be deleted21:40
tormodlike we were doing for jaunty-karmic? I don't understand or remember exactly?21:42
tormodoh yeah cross-release mixing, yeah that can be a mess21:45
tjaaltonbryce: true about x11proto-input, can be synced now21:45
Sarvattwe had libdrm-radeon1 on karmic but not on jaunty and people were mixing and matching packages21:49
brycetjaalton, ok 21:49
bryce * x11proto-input: sync req# 49105121:49
tormodSarvatt, your intel issues are on your netbook?21:51
=== seb128_ is now known as seb128
brycetjaalton, all libs without ubuntu versions sync'd21:52
tjaaltonbryce: libdmx and libxext can be synced too22:00
brycetjaalton, rationale?22:01
tjaaltonlibdmx runs autoreconf now22:02
tjaaltonon build22:02
tjaaltonlibxext was pulled for moblin, and runs autoreconf now like the rest22:02
tjaaltonlibxi should be syncable as well22:02
tjaaltonlibxrender too22:03
tjaalton(yet-another autoreconf)22:03
bryceok, I'm working through these, just need to specify the rationale ("all changes upstream", "was just a fakesync", "was rebuild with no source change", etc.)22:04
tjaaltonyeah, most of them are simple22:05
* bryce nods22:06
brycethank god I have a script for this now22:06
tjaaltonlibxvmc syncable22:06
tjaaltonepoch is bumped in debian, the rest aren't that important I guess ;)22:07
tjaalton+of the changes22:07
jcristauwhat's your diff in libxfont?22:07
tjaaltonchecking 22:08
tjaaltondebian/rules: unset LDFLAGS to not be hit by -Bsymbolic-functions, as libxfont contains weak symbols which are meant to be overriden (cf. LP #226156).22:08
ubottuLaunchpad bug 226156 in libxfont "After update in intrepid branch Xorg " [High,Fix released] https://launchpad.net/bugs/22615622:08
bryce * libxvmc: sync req# 49108622:09
jcristautjaalton: hmm i've seen one of those in a debian/rules a few days ago22:10
brycelibxfontcache?22:10
jcristaulibxt has it22:10
jcristaubryce: i've gotten libxfontcache removed from debian22:10
bryce * libxrender: sync req# 49108822:11
bryce * libxext: sync req# 49108522:11
jcristaui got, even22:11
jcristautjaalton: if the diff is the same as in libxt, care to put it in libxfont debian-unstable before i prepare an upload?22:12
brycetjaalton, "libxi should be syncable as well" - mind doublechecking, seems quite a few changes, just want to be absolutely sure it's syncable22:12
brycehttps://edge.launchpad.net/ubuntu/+source/libxi/2:1.2.1-2ubuntu122:12
tjaaltonbryce: it's the same as with inputproto22:13
brycejcristau, ok22:13
tjaaltonI'll check the status of patch 10122:13
tjaaltonjcristau: yes, I'll check the diff22:14
bryce * libxi: sync req# 49109422:14
jcristautjaalton: thanks.  i pushed an update of libxfont to 1.4.1 to git a few minutes ago, so i'll wait22:14
* bryce ignores libxfontcache for now22:15
bryce(but noting that it's dropped in debian)22:16
jcristaui think libxfontcache had no reverse deps in lenny22:16
tjaaltonjcristau: it's done by just appending LDFLAGS="" for configure22:16
jcristautjaalton: ah, ok22:16
brycelibxkbfile has one patch - https://edge.launchpad.net/ubuntu/+source/libxkbfile/1:1.0.5-1ubuntu222:16
jcristaulibxt specifically filters out -Bsymbolic-functions22:17
jcristaubryce: pretty sure that's upstream22:17
bryceok, we'll do a merge on that to be sure22:17
brycetjaalton, libdrm ?22:18
brycechangelog entry is a bit terse ;-)22:18
brycehttps://edge.launchpad.net/ubuntu/+source/libdrm/2.4.14-1ubuntu122:18
jcristauyour libdrm builds -radeon iirc?22:19
tjaaltonyes, it's not syncable22:19
bryceah right22:19
tjaaltonat least not yet ;)22:19
brycelibx11 probably needs merger attention too22:19
tjaaltonthe full log is in git of course :)22:19
jcristaubryce: http://git.debian.org/?p=pkg-xorg/lib/libxkbfile.git;a=commit;h=e695be2ab7eb1361b204f98c3da872eff58ad6b522:20
brycealrighty, so except for libxfont I think all the libs and protos that can be sync'd are sync'd22:20
brycejcristau, aha awesome thanks22:20
tjaaltonor just check an older entry, if it's the same I usually don't bother22:20
bryceoh wait, there is also kees' fortify-crash.diff patch in libxkbfile22:21
jcristauupstream as well22:22
jcristauhttp://git.debian.org/?p=pkg-xorg/lib/libxkbfile.git;a=commit;h=dd9514fe714d81b881a1bd6bd88d4287adc5fc7e22:22
bryceaha excellent22:23
bryce * libxkbfile: sync req# 49110322:24
tjaaltonthe libxi patch 101 was pulled from upstream, so it should be safe to sync22:25
tjaaltonbut you already filed that, so it's good22:25
bryceyep22:26
tjaaltonjcristau: libxinerama should be good?22:26
brycelong sync list this cycle...  https://wiki.ubuntu.com/X/PackageNotes22:27
bryce(and haven't even gotten to the good stuff yet)22:27
bryceupdated notes @ http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html22:28
tjaaltonjcristau: also libxxf86dga and libxxf86vm have the Replaces, so whenever you have time.. :)22:28
tjaaltonchecking libx1122:30
tjaaltonbah, not upstream22:31
tjaaltonbad robert22:32
tjaalton"Fix 'locale not supported by XLib' errors for la locales" that is22:32
jcristauwhat's that locale?22:36
tjaaltonla_AU.UTF-822:37
jcristauthat isn't even in libc afaict..22:39
tjaaltonhehe22:44
tjaaltonapparently he created it22:53
tjaaltonand was turned down by upstream22:54
tjaaltonhttp://sourceware.org/bugzilla/show_bug.cgi?id=658322:55
ubottusourceware.org bug 6583 in localedata "Please add a locale for Latin" [Enhancement,Resolved: wontfix]22:55
jcristauyeah so i'm not going to carry that as a debian-specific patch22:56
jcristau003_recognize_glibc_2.3.2_locale_names.diff is enough of a nightmare as it is22:56
tjaaltonwow23:04
joumetalhttp://alec.mooo.com/mpx.php looks intresting.23:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!