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