[13:36] bryce_: did OLPC's Bernie manage to find you? [13:37] yes, we chatted a bit [13:37] more about inkscape than -amd though [13:37] ah [13:38] I talked with ogra about -amd briefly as well - he said "the current -amd fails to work for 80% of the people, and that we should go to the previous -amd, which worked fine." [13:38] I asked him if he'd talked to you about this, and he said no, so I told him he needed to speak with you about it first. [13:38] it's not a question of previous -amd as much as current X [13:38] it was the first I'd heard of an issue [13:39] ogra fails to see the big picture: X since 7.2 leaves many drivers that work just fine with 7.1 in the dust, -amd being just one of many. [13:40] it gets even worse with 7.3 [13:41] modularisation allows upstream X to crank out new releases of the core more often, but this comes at the price of chipset drivers requiring more frequent updates. [13:42] for widespread drivers that sometimes include paid coders from the manufacturer, such as ati, mga, intel and nvdia, this works well. [13:42] for all other chipsets, their stability falls behind one API/ABI chunk at atime. [13:44] * bryce_ nods [13:44] so it's a case that even if we went back to the previous -amd, it'd still be broken? [13:45] that is sort of what I suspected [13:49] yup [13:50] bryce: ping [13:50] I tried going back to really old CVS snapshots and I get the same result: the X core simply has changed in too many ways startign with 7.2 [13:51] 7.2 was sort-of compatible with 7.1, but 7.3 definitely isn't [13:51] bryce_: Gadi here has his ThinCan with him at UDS [13:52] bryce_: can you introduce him to Bernie? [13:53] bryce_: and sbalneav is the one that merged -amd support for edubuntu. he has a ThinCan too, though not with him at UDS [13:54] * Gadi is sitting along the window with Dave Trask atm [13:54] and I have to leave in a few mins [13:54] so.... [13:55] oh... [13:55] i am happy to hand off the thincan [13:55] I am meeting up with the rest of the LTSP gang in Maine tomorrow [13:55] and can get it back then [13:55] ok [13:55] that could work well too [13:57] does the LTSP gang ever gather up in EU? [13:58] heya sbalneav [13:58] I've got a session starting now but think I'm free after [14:02] Q-FUNK: in what way is the -amd driver broken atm? [14:03] majority of the drivers have not changed in between xserver releases, so I wonder why those still work [14:04] Hey bryce_ [14:04] tepsipakki: auto-configuration fails on recent X versions that support it. vice-versa, on recent X, ctrl-alt-Fx fails to change console. [14:04] yeah, changing the console hangs up the whole box. [14:05] well, i get the exact same problem on an unrelated driver -siliconmotion [14:06] here, it doesn't hang the whole box, but I cannot get an image back after. I can still ssh into the box, thoguh. [14:07] Ah, well, when I say "hang", I haven't tested to see if I can still ssh in. Keyboard becomes unresposive, however. [14:07] my problems with -siliconmotion are described in a bug I filed on LP [14:07] the problems described by sbalneav with -amd are similar to those I experience with -siliconmotion. those problems did not exist on Feisty, which has an older X release. [14:08] otherwise, almost the same source code, in both cases. [14:09] ok [14:09] Q-FUNK: ok [14:09] I gave the thincan to Dave Trask [14:09] I've had to pin xserver-xorg-core and xserver-xorg-dev to 7.1 in both cases [14:09] bryce_: you're welcome to it for the day, but please give it back to him or another LTSP person headed to Maine [14:10] actually there is a problem with -sis that it hangs on logout [14:10] using feisty [14:10] 7.2 works but you cannot change console and if the X built-in screensaver kicks-in, you can never recover video. [14:10] hang on logout is also something i experience with siliconmotion, if I let it upgrade to gutsy [14:11] 7.3 is even worse. [14:11] something tells me that -amd might need a partial upgrade to work with the new XrandR [14:12] it might also need a shuffle of the BIOS env parts, as decribed in the bug report for -amd [14:13] I wouldn't be surprised if other drivers need a similar cleanup [14:23] that seems likely [14:23] do you have additional information on specifics of what changes are needed? [14:27] Q-FUNK: btw, I'm going to be in and out today so don't think I should take the thincam (not really sure even how to use it) [14:32] bryce_: if it would help, I'd be happy to lend you my thincan, and ship it to you, when I get back to winnipeg. [14:33] I suspect I need the high level overview first; I've never heard of 'thincan' before [15:13] bryce_: a thin client based on the AMD Geode chipset. [15:15] works well with LTSP, except for the new bugs introduced by X >=7.2 [15:16] bryce_: dtrask has the thincan left by Gadi, if you need it [15:16] tepsipakki: alternately, since you live here, it could be very easy for me to loan you one, if you feel like working on it. [15:26] Q-FUNK: hmm :) [15:27] hello! what is the current plan for xlib with xcb support? is there any timeline for this yet? we want to switch to compiz 0.7 and it will be a requirement there [15:28] Q-FUNK: I'm not sure if I'd be able to find the problem though [15:28] mvo: uploaded! [15:28] rock! [15:28] * mvo hugs tepsipakki [15:28] libx11-xcb* is sitting in new :) [15:28] mvo, as soon as the xserver build is through, you should be good to go [15:28] * tepsipakki hugs mvo back [15:30] bryce_: it doesn't really need the server, it's just a lib :) [15:32] :) [15:33] ah [15:44] Q-FUNK: do you have a detailed write-up of the work needed for -amd? [15:48] the details provided by Anti in the bug are as close to a checklist as I've got [15:58] hmm, I don't remember the bug id offhand [15:58] ok, going out for a bit. bbl [16:36] New bug: #159556 in xorg-server (main) "[Hardy] xserver-xorg-core incorrectly conflicting with xserver-xorg-video?" [Undecided,New] https://launchpad.net/bugs/159556 [16:38] hah [16:38] that bug ^^ [16:38] someone actually running hardy [19:23] <_bernie> hello [19:24] sbalneav: I found Bernie :) [19:24] <_bernie> anythink I can do... [19:25] <_bernie> are you maintainers of amd_drv in Xorg? [19:25] _bernie: Jordan said that you might be able to help us bring -amd in line with X.org 7.3 specs [19:25] <_bernie> we currently just rebuild it with no patches [19:26] we currently have a situation where it fails autoconfiguration on recent X releases. [19:26] <_bernie> but we don't use Xorg as upstream [19:26] you have oyur own fork? [19:27] <_bernie> http://dev.laptop.org/git?p=xf86-amd-devel;a=summary [19:27] <_bernie> unfortunately [19:27] <_bernie> jordan says the version on fd.o is not suitable for us [19:27] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051 [19:27] <_bernie> probably some DCON changes, I never got around to diff them. [19:27] Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [High,Triaged] [19:28] yes, DCON. we don't have those [19:28] <_bernie> if you have commit access on the fd.o git repository, it would be nice to pull from us and resync the source [19:28] <_bernie> I hate forks [19:28] I cannot sync as-is [19:29] you guys have too many OLPC-specific changes that would need to be #ifdef'ed [19:29] <_bernie> I had that segfault too! [19:29] <_bernie> I can't remember how I fixed it though... just a moment [19:29] that's why Jordan has been acting as a sort of gate keeper between both trees [19:30] if/when you get around haivng proper #ifdef on all OLPC-specific stuff, we 'd love to merge trees and maintian everything at f.d.org [19:30] <_bernie> are you sure you're building with 100% 7.3 headers? [19:30] yup [19:30] but 7.2 already is problematic [19:30] <_bernie> I had to delete my /usr/include/X11 and /usr/include/xorg dirs at some point when I was testing stuff locally [19:30] building against anything more recent than 7.1 cuases all sorts of issues [19:31] <_bernie> I can't test on anything but OLPC. I have no other amd boards... this is why I can't easily help making our patches available for the fd.o version [19:31] <_bernie> I build against 7.3 and everything is fine [19:32] I think that the most pressing issue is to fix auto-configuration. as far as we can tell, this requires shuffling BIOS environmnet parsing around. [19:32] <_bernie> so the fix is somewhere in our tree [19:32] <_bernie> how about cherry-picking the easy to merge patches and retry? [19:32] _bernie: please look for dtrask at UDS. he has a more generic board made with an LX on it. it's the same that LTSP guys have been playing with. [19:33] <_bernie> argh, I'm already back at One Cambridge Center [19:33] oh [19:34] <_bernie> I'm looking for bits where we explicitly require DCON in our driver [19:34] <_bernie> I don't see them... We always check for it before any access as far as I see. [19:35] <_bernie> we're nearby a big feature freeze. that would be today. [19:36] <_bernie> so maybe next week I could start submitting patches [19:36] lovely! [19:37] <_bernie> have you being building from a pristine git's master? Or do you have debian or ubuntu specific patches on top of it? [19:38] nothing debian/ubuntu specific [19:38] we build against a pristine f.d.org tree [19:43] <_bernie> I see there are _several_ patches on fd.o [19:43] <_bernie> try pulling from our git repo and see what happens [19:43] <_bernie> if your bug goes away, then you know where to look [19:43] on fd.o ? [19:43] the current 2.7.7.3 includes all the latest. [19:44] ...except for OLPC additions [19:44] git head on fd.o = 2.7.7.3 [19:46] <_bernie> I mean, try building the source from git://dev.laptop.org/xf86-amd-devel [20:02] I just diffed it [20:02] very few differences, oddly enough [20:02] mostly DCON stuff [20:03] <_bernie> looking [20:07] I also added that diff to the bug. [20:08] and includes that have been either eliminated or shuffled around [20:09] <_bernie> I don't see anything that would be clearly responsible for your particular segfault [20:10] <_bernie> well, try building our driver and see what it does [20:10] <_bernie> can you do a quick test? [20:12] sure [20:13] midn you, you guys are using a fixed resolution with a config, aren't you? [20:13] I'm also wondering why you removed amd.h from so many files [20:32] New bug: #34146 in xserver-xorg-input-hyperpen (universe) "appearance of constant full pressure" [Medium,New] https://launchpad.net/bugs/34146 [20:41] <_bernie> http://dev.laptop.org/git?p=xf86-amd-devel;a=commitdiff;h=1d6f6bdcb0aac722e50ac58ff94e4df5c5f0220b [20:41] <_bernie> dan williams says it caused a build error [20:41] <_bernie> I recall something messing with _X_INLINE [20:42] <_bernie> http://dev.laptop.org/git?p=xf86-amd-devel;a=commitdiff;h=63d72f8c1ff1b7e534fc533a6aae8683e83fc0ca [20:42] <_bernie> ^^^ this was also a good idea [20:43] <_bernie> Q-FUNK: yes, we hardcode the resolution in xorg.conf, since the LCD size is fixed. [20:43] <_bernie> but we shouldn't. I'd like to get rid of xorg.conf alotgether [20:44] for that, you'd need to manage to fix the above ubuntu bug :) [20:45] New bug: #159617 in xserver-xorg-input-hyperpen "tablet does not work" [Undecided,New] https://launchpad.net/bugs/159617 [20:45] <_bernie> :-/ [20:50] basically, BIOS parsing has to be cleaned up and parts of it shuffled around, for autoconfiguration to work. [20:50] our Anti did most of the ground work in his coments to the bug [22:08] _bernie: I get a big hard freeze with the olpc tree, as soon as X tries to load