[07:19] jcristau: oh, nice.. didn't spot that one [07:21] heya [07:21] howdy [07:22] no archive-admin action yet, it seems :) [07:22] yeah :-/ [07:22] I did mention the sync req's to rick [07:22] if they don't get done in the next day I can ping some people [07:23] most of the protos should be autosynced anyway, since they entered testing yesterday [07:23] but I need to merge xutils-dev so they build [07:27] maybe I should upgrade my laptop as well.. [07:28] before the madness [08:14] mvo: hey, could the "failed to install" bugs attach the output of df to the bug. I suspect most of them are due to full root partition.. [08:18] 'df -l' would do [08:56] hey tjaalton [08:56] tjaalton: sure [08:56] tjaalton: good idea [08:56] hm, update-manager should check (well, approximate) that now, however apt itself does not [09:00] mvo: great, thanks [09:09] mvo: is it generally ok to drop Breaks/Depends/.. on packages from a past devel version (so that the version was not in the final release)? [09:10] since I don't think we support upgrades from a past alpha [09:13] yeah, that should be fine [09:14] good [09:41] tjaalton: df -l commited to my bzr branch, thanks [09:41] mvo: excellent :) [10:01] hi all [10:02] I have read that the big X/Kernel changes are scheduled before Alpha 1. So it doesn't make sense/is dangerous before that to upgrade a Lucid Testing environment? [10:03] Btw. which gain do we have through noveaou. I mean it has no 3D support yet afaik and KMS is good but most people would switch to the proprietary driver anyway. [10:04] I mean nv is quite stable and has an alternative or are there many bugs for nv? [10:04] bah, I upgraded an hour ago [10:04] tjaalton, So the big changes hasn't happened yet or already? :) [10:04] nv is pretty much dead [10:04] Unggnu: not yet [10:04] tjaalton, But they still make it work for new cards, 2d and xv or not anymore? [10:04] waiting on syncs from debian, and xorg & xorg-server merges to be uploaded [10:05] Unggnu: it has modesetting bugs that wont be fixed [10:05] Ok, noveau would be great for old Nvidia cards that has no proprietary driver anymore but I doubt that it is already fast or so stable [10:05] it's fast for 2D [10:05] ok, I just thought it is a tough decision for LTS [10:05] and some people can't get nv up at all [10:06] I mean radeon driver is in development since a long time and still has no Powerplay [10:06] which makes the computer pretty loud and uses much energy [10:07] I don't know if the nv has the pendant. [10:07] it doesn't [10:07] But with the edgers package KMS already works and textured video (still with tearing though). [10:08] Ok, we will see how it works out. I haven't any Vvidia card anymore, at least not in use. [10:10] Through ChromeOS and developments like this Nvidia will probably change their decison, at least I hope so [10:10] The pressure through Dell has already worked in some areas afaik [10:11] chromeos would be more likely to be used on a tegra type platform I would have thought? [10:12] Ng, on Netbooks and in future it should be combine with Android afaik. Anyway Nvidia also produces chips for this devices afaik. [10:12] If they only use open source drivers they have to change [10:13] sure, the tegra, but I'm assuming wildly that it's very different to their desktop offerings [10:14] synergy ;) [10:22] KMS seems to work with nouveau even for nvidia TNT, that's cool. [10:22] So Debian plans to use Nouveau in SID too? [10:23] probably not as default. that would mean kernel changes [10:23] which is the painful part [10:25] yes, I have heard [10:26] Radeon is also pretty fast without KMS [10:26] but I think this was fixed lately [10:29] Got to go, thanks for the information, bye. [13:48] hi all, using kernel 2.6.32 from the mainline kernel ppa and the xorg-edgers ppa on karmic, i get no dri. xorg.log says:(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed. [dri] Disabling DRI. [13:48] any ideas? [13:56] i should say that i also enable kms [13:56] does .31 work? [13:57] tjaalton, i'll check that, just a minute [14:03] tjaalton, same thing with 2.6.31-15 from karmic repos [14:04] don't use kms, it seems [14:05] it does use KMS i believe [14:05] but if you use modeset=1, DRI works [14:05] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/394263 [14:05] Ubuntu bug 394263 in linux "2.6.31 kernel breaks 3d for radeon x1600" [Undecided,Confirmed] [14:05] erm, =0 [14:06] i'm quite sure it's someting in the updated X stack, because i get dri with the X stack from karmic + KMS [14:06] mesa then [14:07] google for the error, there are tons of hits [14:07] diverse_izzue: your issue is either your ddx driver doesn't support kms, or there's a race when loading the radeon kernel module which makes this fail. [14:07] jcristau, my ddx driver is the most recent one from the xorg-edgers ppa [14:07] so probably number 2 [14:07] what to do about that? [14:08] modeset=0, or load radeon earlier [14:08] how to load radeon earlier? [14:13] have to go to the lab, back in a little while... [14:22] bryce, can you join our radeon kms discussion on #ubuntu-kernel please? [14:24] doubt he's awake yet [14:25] the xorg wiki talks about the error: http://www.x.org/wiki/radeonBuildHowTo. [14:25] hmm doesn't his son keep him awake all the time? [14:25] hehe [14:26] tjaalton: i'd forgotten xft.. damn lib not starting with lib. fixed now, on its way to sid. [14:27] jcristau: hehe, time to rename it? :) [14:27] it's libXft upstream [14:27] so it would be even consistent :) [14:27] diverse_izzue, it's not what they say on the x wiki [14:28] tormod, but what...? [14:38] diverse_izzue, the reason for that error message can be what the x wiki says, and it can be what my page says [14:38] on Ubuntu, the x wiki explanation is not applicable since we build with the kms api [14:41] bryce, yo ... we are discussing the change to enable radeon kms on #u-k [14:41] apw, I tried to wake him too :) [14:44] heheh [14:45] so how does intel initialize early enough, but not radeon? [14:45] is the module in initramfs? [14:45] AIUI it isn't [14:48] tjaalton, is the i915 force loaded somewhere, not by the X server? [14:48] tormod: maybe, I don't know [14:49] I just remember there was this i915 and fbcon(?) issues in karmic before release [14:50] wasn't there some kind of race that got sorted out? [14:50] apw: ^ [14:50] or should Keybuk know? [14:50] things progress too fast for me :) [14:50] I asked Keybuk about all this some days ago [14:51] he did not know [14:51] heh ok [14:51] I thought I had more time to sort it out anyway :) [14:51] its odd, we load the drivers which do that very early, in responce to udev events for them [14:51] we then boot ... slowly for several seconds, then start X [14:52] how it could not be ready in time i do not know [14:52] radeon does not load by itself [14:52] I tried, see my gdm.conf on the wiki page [14:52] the radeon driver does not have module aliases ? [14:52] if I remove "modprobe radeon" X does not start [14:53] tormod: but kms worked? [14:53] if I then manually modprobe radeon, boom X starts [14:53] I mean, how can it work without radeon? [14:53] no kms does not activate before [14:53] it can't work without radeon, but radeon should load automatically by itself [14:53] right [14:53] if its done right [14:53] it takes 2.5s for i915 to load here [14:54] but that is sychonous [14:54] so its done by the time X starts [14:54] historically only the X server would make radeon load [14:54] and only if the X server uses "radeon" DDX I guess [14:54] and not if it uses fglrx [14:55] so it's a chicken and hen element to this [14:55] *egg [14:55] #if defined(CONFIG_DRM_RADEON_KMS) [14:55] MODULE_DEVICE_TABLE(pci, pciidlist); [14:55] #endif [14:55] if KMS is turned on in the build (which it is) then we should load the driver if the id's are listed [14:55] ha [14:56] maybe that would do it? [14:56] that is the current settings [14:56] that is the current settings since a long time right? [14:56] so if you disabe the gdm upstart job, we'd expect to see it loaded by udev [14:56] tormod: has anyone tried with a kernel where it's enabled?-) [14:56] all of karmic yes [14:56] thats enabled, with or without modesetting selected [14:56] tjaalton, CONFIG_DRM_RADEON_KMS means support for KMS [14:57] not that it is on by default [14:57] ah right [14:57] yep we have the code ON but disabled by option [14:57] well, it does not load by itself here [14:57] then the module aliases are wrong i would guess [14:57] what can I check? [14:58] wait I know [14:58] if you don't load it by default [14:58] then you can see what udev sees in its logs /var/log/udev [14:59] my card is 1002:5653 and I see pci:v00001002d00005653sv*sd*bc*sc*i* in modinfo [14:59] tormod, there are a lot of id's listed [14:59] nope not listed [14:59] is /var/log/udev kept logged to? [15:00] its a live file i believe [15:00] This file is auto-generated from the drm_pciids.txt in the DRM CVS [15:00] Please contact dri-devel@lists.sf.net to add new cards to this list [15:00] ok the list of supported id's has that comment in it [15:01] apw, not listed where? I see it in modinfo [15:01] yeah ... hrm [15:01] it is in there [15:03] tormod, i see the ids in the source but not in the modules.alias file [15:04] anyway, it can still be racy since kms init takes ~0.6s and X starts earlier and earlier [15:04] tormod, wa [15:04] tormod, what is the solution to that ... [15:05] apw, you saw my gdm.conf hack? [15:05] there must be a real solution though [15:06] drmCheckModesettingSupported in libdrm should not return before init is finished maybe [15:08] if there's a way from userspace to see if drm init has finished regardless of kms support [15:08] we have an issue that we want X to start earlier to get things working qucker, but that makes people do init async, and we have no way to work out if its meant to be coming [15:08] the issue is that there is no way to know if the device will find an output and modeset it or not [15:11] we could make drm emit an event and let gdm wait for it, but then if you boot something where there is no drm hw... [15:12] you need to know its done whether it did anything or not [15:13] I am tending towards fixing radeon DDX, it knows it has a drm device, just have to wait for it to finish init before probing it [15:16] I wonder if /dev/dri/card0 shows up before it is fully initialised? [15:17] in other words, if /dev/dri/card0 shows up before /sys/class/.../drm/controlD* which is the KMS marker it probes for [15:19] I mean /sys/bus/pci/devices/.../drm/controlD* [15:26] yes it does, that is obvious from Xorg.0.log [16:25] (more loud thinking in #radeon) [17:05] * tormod notices libdrm 2.4.16 is out! === ripps is now known as ripps|sleep [18:01] bryce, yo! [18:02] i reenabled ati kms, tormod seems to think that userspace is not ready, what do you want the Alpha-1 kernel to have as the default, on or off? [18:10] apw, I have some ideas to avoid potential races if the module already has been loaded and is under initialisation, but what about the fact that radeon is not loaded by itself? [18:15] its sounding like you guys just need to do more before this is ready [18:15] so i'll just turn it off again [18:16] apw, yes I agree. we could add some quick workarounds now, but we need to find a better solution [18:17] we [18:17] heya apw [18:17] i'll put together an email tomorrow saying that we're turning it off [18:17] would be good if more of you devs would run lucid and latest bits and KMS though [18:17] and you guys can argue about how to fx it for alpha2 [18:18] we all sensibly have intel [18:18] if I am the only one who have tested KMS, I would not enable it for everybody ATM [18:18] then we'll never enable it, which seems like no progress [18:18] bryce, talking about radeon [18:18] yes that's bad that you all use the same hardware [18:18] i enabled it in the -6 kernel and its seeeming its not working [18:19] userspace issues, so i wanted to confirm whether i should switch it off for a1 or not [18:20] if it is completely broken, there's not much time remaining pre-a1 for us to fix it [18:20] bryce, i thought from our disucssions at uds it was ok, but tormod says userspace isn't ready [18:21] perhaps you could disucss with him and let me know what you wnat the default to be for a1 [18:21] i'll be uploading tommorrow am my time for the release [18:21] i have to run now, so drop me an email.... [18:21] leave it off [18:22] ack [18:22] I tend to prefer switching things on right after a release, to give maximal time to test [18:22] if we already know radeon kms doesn't work reliably, I'd rather not have the deluge of bug reports ;-) [18:23] ok so lpan of off for a1 and on in the first upload after thant [18:23] yep [18:23] I'll work out the plan with tormod for what we have to do on the userspace side and hopefully get that squared away in the mean time [18:23] bryce, to summarize: radeon is not loaded before X loads it, but when X probes for KMS the module has not finished initializing so it thinks KMS is off [18:24] and you get UMS and KMS at the same time! [18:24] tormod, ah [18:24] bryce, please read the backlog here, #ubuntu-kernel and #radeon [18:24] tormod, could we just force it to expect KMS and sleep if it is missing? [18:24] tormod: afaict with CONFIG_DRM_RADEON_KMS=y, the radeon module exports a device table that should get it loaded automatically by whatever at boot [18:24] hmm, I'm not on #radeon [18:25] jcristau, I was discussing this with apw above, but it seems it is not loading [18:26] hmm and looks like I caught only the tail end of the #ubuntu-kernel discussion... mind re-summarizing the main bits for me? [18:26] hmm the MODULE_DEVICE_TABLE isn't enough? [18:26] so maybe it is a kernel issue although apw blames userspace :) [18:27] well there's still another bug if 'modprobe radeon; drmCheckModesettingSupported()' fails [18:27] bryce, I have a patch for what you suggested there :) [18:27] jcristau, yes it is still racy [18:28] tormod: but that should only matter in the case where radeon doesn't get loaded by udev earlier [18:28] jcristau, or everything starts up really quick :) [18:28] which is aiui the whole point of the device table [18:29] note also that radeon will need firmware available, currently missing from initrd [18:29] it doesn't need to be in initrd [18:29] depends on when you load radeon... [18:30] udev should load it after / is available, i think [18:36] bryce, this is patch http://ubuntu.pastebin.com/d3b3afb7c [18:38] tormod, firmware? [18:39] bryce: platform radeon_cp.0: firmware: requesting radeon/R420_cp.bin [18:39] tormod, yeah that's what I was thinking [18:40] on my own laptop, I have a kms-ready.conf that waits for "filesystem" to load radeon [18:41] then I let gdm.conf wait for kms-ready (which is NOP without KMS) [18:41] tormod: that patch seems wrong. drmCheckModesettingSupported returns 0 if modesetting *is* supported [18:41] jcristau, quite possibly, not tested yet :) [18:41] tormod, oh right the command processor [18:42] also a 2s penalty for ums users seems a lot... [18:42] not if KMS is default [18:42] right ideally we don't care about UMS [18:43] like with -intel people need UMS only to work around bugs [18:43] (in theory, ideally) [18:43] ideally drmCheckModesettingSupported should be fixed to wait if stuff is initialising [18:43] yes [18:44] jcristau, this is not a upstream patch :) just a Ubuntu hack [18:44] drmCheckModesettingSupported is kind of mickeymouse also IMO [18:51] how difficult would it be to fix the radeon module to create a /sys file that tells if KMS is enabled or disabled (and not just one of them) [18:53] jcristau, do you envision in debian testing wanting to support both UMS and KMS on radeon? [18:54] i don't think we'll turn radeon kms on by default if that was the question [18:54] jcristau, since I know with -intel the plan is to eliminate UMS entirely, I'm sort of figuring supporting both to be just a transitional thing [18:54] jcristau, ok gotcha [18:55] (if we do, we'd have to track whatever's in f12, since apparently dave didn't get all fixes in .32 final, and considering the manpower issues we have i don't think that's feasible [18:56] ) [18:57] since many users does kernel-hopping it would be good if user-space can deal with both active-by-default and not [18:57] email from alex deucher: [18:57] Any chance you can pull radeon drm bits from 2.6.33 during [18:57] development? We are planning to move radeon kms out of staging during [18:57] 2.6.33 and there are a number of important patches already queued for [18:57] 2.6.33: a number of bug fixes, tmds support on pre-avivo igp chips, [18:57] interrupt support on r6xx/r7xx, and displayport support to name a few. [18:57] [18:57] Displayport is supported now in xf86-video-ati master for UMS, and for [18:57] KMS the patches are in drm-radeon-testing. I hope to have the [18:57] interrupt bits for KMS DP/HPD merged soon too. This will give us [18:57] interrupt driven monitor detection which will trigger a uevent (e.g., [18:57] box pops up saying: "You've attached/disconnected a monitor", etc.). [18:58] [18:58] monitor uevents... sweetness [18:59] anyone here on radeon UMS ATM? [18:59] yes [19:00] can you pastebin your "find /sys/devices/pci-blahblahvideocard" ? [19:01] http://pastebin.ubuntu.com/334037/ [19:01] thanks [19:08] my KMS one: http://ubuntu.pastebin.com/d43af9bdf drmCheckModesettingSupported looks for drm/controlD* in there [21:10] tjaalton, how are we looking for the 1.7 merge? would it help if I work on some of the misc. outstanding merges? [21:11] bryce: 44 packages are waiting to be synced [21:12] xorg & xorg-server are merged, but the latter has some patches that need a review & refresh [21:12] tjaalton, right, beyond the syncs anything else needed that I should work on? [21:12] well, maybe have a look at the patches and see if they are needed? [21:13] I've updated the versions page with some new syncs and comments [21:14] ok [21:14] I've pinged pitti to do the syncs [21:14] great [21:15] are the patches to review flagged somehow in git? [21:15] ah yes they are [21:15] ok on it [21:15] uncommented from series, and marked in the changelog [21:40] are you gonna use udev in the xserver for A1? [21:42] yes [21:43] cool [21:46] hrmph, everyone complains "canonical doesn't contribute to X.org upstream", yet here are all these patches I made and sent upstream and they never got taken (or got a reply as to why not) [21:47] and I continue to wait for my fdo git account :-P https://bugs.freedesktop.org/show_bug.cgi?id=20373 [21:47] Freedesktop bug 20373 in Account Modification Requests "Please add gpg key to this account" [Major,New] [21:50] maybe ping someone on #xorg-devel? [21:51] and the workflow has changed, so direct commits to master are a no-go, so posting patches for a review doesn't require the login (not that it would harm either..) [21:52] but maybe it's just the xserver that follows this, dunno [21:52] oh interesting [21:52] yeah mainly I wanted access to do work on -ati [21:52] it's been discussed on the list several times the past few months :) [21:53] yeah read those, and also discussed at XDC which I attended. [21:53] you'd think I'd remember these things [21:53] oh right [21:53] hehe [21:53] it's mostly for the server, where keith is the one to push to master [21:53] yeah I guess I can try pushing the patches in again [21:54] iirc some of them whot said were just papering over issues and he'd prefer to crash in those situations [21:54] i need to resend the udev stuff [21:54] I tend to prefer issuing a warning in Xorg.0.log and not crash... seems more friendly to the user [21:54] patch 169 obsoleted by http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=3d30789a05a730a03faa6058c73a5eda36ef3779 ? [21:55] Sarvatt, unfortunately that's not the only place where MIPOINTER() is dereferenced without checking for NULL [21:57] tjaalton, I don't see the touchpad rule in git yet [21:57] Sarvatt, grepping launchpad, patch 169's error string does show up in a couple bug reports (for proprietary drivers). [21:57] maybe those are outdated, I didn't check [21:57] tormod: i think i pushed it to -synaptics... [21:58] jcristau, oh that would make sense [22:00] tjaalton, looks like the syncs are coming in [22:00] libs at least so far [22:00] bryce: yep :) [22:01] looks like lp is about to go down so rest are going to wait for tomorrow [22:03] it's only 90min or so [22:03] I think pitti wants to go to bed [22:03] ah, right :) [22:06] at least most of that wont build without the missing protos so things wont be broken until then :D [22:06] yep [22:08] ok, down to two patches [22:08] but oy, saved the hardest for last [22:09] nothing can be worse than libx11's 03 patch lol [22:10] which one is left? [22:10] 003_recognize_glibc_2.3.2_locale_names.diff ? [22:10] - 135_rethrow_signals.patch - TODO: Refresh [22:10] - 190_cache-xkbcomp_output_for_fast_start_up.patch [22:10] bryce: ok, it's still alive, synced all bug bug 491051 [22:10] Launchpad bug 491051 in x11proto-input "[Sync Request] Please sync x11proto-input (1.5.0-2) from Debian [unstable] (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/491051 [22:10] ugh yeah thats the nightmare one I spent 8 hours refreshing [22:11] oop he did that one too [22:11] bryce: 003? where's that from? [22:11] tjaalton, ok all in [22:11] tjaalton libx11 [22:11] hehe [22:11] libx11, sorry was talking about nightmare patches [22:11] the infamous la_AU patch [22:12] Sarvatt, 006 looks bad too (at least, it's huge) [22:12] wait, you need x11proto-input 2.0 from experimental not the one from unstable dont you? [22:12] indeed [22:12] $ diffstat 006_tailor_pt_BR.UTF-8_Compose.diff [22:12] Compose.pre | 5619 ------------------------------------------------------------ [22:12] 1 file changed, 1 insertion(+), 5618 deletions(-) [22:12] ok maybe not so bad, just deletes a lot of stuff :-) [22:12] huh [22:13] Sarvatt, yes, the bug was just misfiled, my bad [22:13] Sarvatt: want to help getting it upstream? [22:13] :) [22:13] bryce: only patch 16 is ours [22:14] 016 I mean [22:14] so it's a simple merge [22:19] hey, speaking of XI2, does this finally get rid of the 256 limitation on key codes? [22:19] or is that a more fundamental X11 protocol issue? [22:23] the core protocol still only has 8bit for keycodes [22:23] but i think apps can listen to xi2 events and get 32bit keycodes [22:24] so we probably still need xkb2 and then fix clients [22:28] jcristau, so will only apply for xi2 compliant apps? [22:28] do apps need changed to use this or is it something that can be taken care of by the toolkits? [22:28] bryce: may be enough to migrate toolkits [22:29] that's probably all that's needed [22:29] * bryce nods [22:29] but then it's possible even fewer people understand gtk's input code than X's [22:29] ;) [22:29] lol [22:30] refreshing the udev patch for master and i'll upload it in a bit tormod [22:31] oh darn he just left, nevermind [22:37] ok patch 135 done, one patch left [22:54] done [22:55] and refreshed/re-enabled the timing patch 160 for good measure [22:55] that one fails nastily on master :D [22:56] Sarvatt, the timing patch? [22:56] 190_cache-xkbcomp_output_for_fast_start_up.patch [22:56] oh [22:56] it required only minor tweaking to get it to apply (just one chunk was off) [22:57] bryce: so 156 is no longer needed? [22:58] the commits were a bit messy ;) [22:58] tjaalton, where might I best snag xorg-server_1.7.2.orig.tar.gz ? I'll do a build test [22:58] packages.debian.org? [22:58] ftp.debian.org works [22:58] that too [22:58] tjaalton, my commits were messy? sorry about that, tried to keep one commit per patch [22:59] well, some changelog edits etc. and patch 156 is still in git and enabled, also referenced in the changelog :) [22:59] sweet, changelog is down to 4 hooks for xorg-server master now from about 40 :D [23:00] oh whoops [23:00] * bryce fixifies [23:01] pushed [23:01] thanks [23:04] 02_Add-libgcrypt-as-an-option-for-sha1.diff is upstream 164_trap-aspect-ratios.patch fails 190_cache-xkbcomp_output_for_fast_start_up.patch fails and 12-Add-libudev-input-hotplug-backend.diff just needed 2 words changed. ah yeah and --disable-werror needed to be changed to --disable-strict-compilation in rules on master [23:05] what's the error on 190? [23:05]