[13:36] <Q-FUNK> bryce_: did OLPC's Bernie manage to find you?
[13:37] <bryce_> yes, we chatted a bit
[13:37] <bryce_> more about inkscape than -amd though
[13:37] <Q-FUNK> ah
[13:38] <bryce_> 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] <bryce_> 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] <Q-FUNK> it's not a question of previous -amd as much as current X
[13:38] <bryce_> it was the first I'd heard of an issue
[13:39] <Q-FUNK> 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] <Q-FUNK> it gets even worse with 7.3
[13:41] <Q-FUNK> 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] <Q-FUNK> for widespread drivers that sometimes include paid coders from the manufacturer, such as ati, mga, intel and nvdia, this works well.
[13:42] <Q-FUNK> for all other chipsets, their stability falls behind one API/ABI chunk at  atime.
[13:44]  * bryce_ nods
[13:44] <bryce_> so it's a case that even if we went back to the previous -amd, it'd still be broken?
[13:45] <bryce_> that is sort of what I suspected
[13:49] <Q-FUNK> yup
[13:50] <Gadi> bryce: ping
[13:50] <Q-FUNK> 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] <Q-FUNK> 7.2 was sort-of compatible with 7.1, but 7.3 definitely isn't
[13:51] <Q-FUNK> bryce_: Gadi here has his ThinCan with him at UDS
[13:52] <Q-FUNK> bryce_: can you introduce him to Bernie?
[13:53] <Q-FUNK> 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] <Gadi> and I have to leave in a few mins
[13:54] <Gadi> so....
[13:55] <Q-FUNK> oh...
[13:55] <Gadi> i am happy to hand off the thincan
[13:55] <Gadi> I am meeting up with the rest of the LTSP gang in Maine tomorrow
[13:55] <Gadi> and can get it back then
[13:55] <Q-FUNK> ok
[13:55] <Q-FUNK> that could work well too
[13:57] <Q-FUNK> does the LTSP gang ever gather up in EU?
[13:58] <bryce_> heya sbalneav
[13:58] <bryce_> I've got a session starting now but think I'm free after
[14:02] <tepsipakki> Q-FUNK: in what way is the -amd driver broken atm?
[14:03] <tepsipakki> majority of the drivers have not changed in between xserver releases, so I wonder why those still work
[14:04] <sbalneav> Hey bryce_ 
[14:04] <Q-FUNK> 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] <sbalneav> yeah, changing the console hangs up the whole box.
[14:05] <Q-FUNK> well, i get the exact same problem on an unrelated driver -siliconmotion  
[14:06] <Q-FUNK> 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] <sbalneav> Ah, well, when I say "hang", I haven't tested to see if I can still ssh in.  Keyboard becomes unresposive, however.
[14:07] <Q-FUNK> my problems with -siliconmotion are described in a bug I filed on LP
[14:07] <Q-FUNK> 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] <Q-FUNK> otherwise, almost the same source code, in both cases.
[14:09] <Gadi> ok
[14:09] <tepsipakki> Q-FUNK: ok
[14:09] <Gadi> I gave the thincan to Dave Trask
[14:09] <Q-FUNK> I've had to pin xserver-xorg-core and xserver-xorg-dev to 7.1 in both cases
[14:09] <Gadi> 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] <tepsipakki> actually there is a problem with -sis that it hangs on logout
[14:10] <tepsipakki> using feisty
[14:10] <Q-FUNK> 7.2 works but you cannot change console and if the X built-in screensaver kicks-in, you can never recover video.
[14:10] <Q-FUNK> hang on logout is also something i experience with siliconmotion, if I let it upgrade to gutsy
[14:11] <Q-FUNK> 7.3 is even worse.
[14:11] <Q-FUNK> something tells me that -amd might need a partial upgrade to work with the new XrandR
[14:12] <Q-FUNK> it might also need a shuffle of the BIOS env parts, as decribed in the bug report for -amd
[14:13] <Q-FUNK> I wouldn't be surprised if other drivers need a similar cleanup
[14:23] <bryce_> that seems likely
[14:23] <bryce_> do you have additional information on specifics of what changes are needed?
[14:27] <bryce_> 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] <sbalneav> 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] <bryce_> I suspect I need the high level overview first; I've never heard of 'thincan' before
[15:13] <Q-FUNK> bryce_: a thin client based on the AMD Geode chipset.
[15:15] <Q-FUNK> works well with LTSP, except for the new bugs introduced by X >=7.2
[15:16] <Q-FUNK> bryce_: dtrask has the thincan left by Gadi, if you need it
[15:16] <Q-FUNK> 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] <tepsipakki> Q-FUNK: hmm :)
[15:27] <mvo> 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] <tepsipakki> Q-FUNK: I'm not sure if I'd be able to find the problem though
[15:28] <tepsipakki> mvo: uploaded!
[15:28] <mvo> rock!
[15:28]  * mvo hugs tepsipakki
[15:28] <tepsipakki> libx11-xcb* is sitting in new :)
[15:28] <bryce_> mvo, as soon as the xserver build is through, you should be good to go
[15:28]  * tepsipakki hugs mvo back
[15:30] <tepsipakki> bryce_: it doesn't really need the server, it's just a lib :)
[15:32] <Q-FUNK> :)
[15:33] <bryce_> ah
[15:44] <bryce_> Q-FUNK: do you have a detailed write-up of the work needed for -amd?
[15:48] <Q-FUNK> the details provided by Anti in the bug are as close to a checklist as I've got
[15:58] <bryce_> hmm, I don't remember the bug id offhand
[15:58] <bryce_> ok, going out for a bit.  bbl
[16:36] <ubotu> 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] <tepsipakki> hah
[16:38] <tepsipakki> that bug ^^
[16:38] <tepsipakki> someone actually running hardy
[19:23] <_bernie> hello
[19:24] <Q-FUNK> sbalneav: I found Bernie :)
[19:24] <_bernie> anythink I can do...
[19:25] <_bernie> are you maintainers of amd_drv in Xorg?
[19:25] <Q-FUNK> _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] <Q-FUNK> 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] <Q-FUNK> 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] <Q-FUNK> 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] <ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [High,Triaged] 
[19:28] <Q-FUNK> 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] <Q-FUNK> I cannot sync as-is
[19:29] <Q-FUNK> 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] <Q-FUNK> that's why Jordan has been acting as a sort of gate keeper between both trees
[19:30] <Q-FUNK> 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] <Q-FUNK> yup
[19:30] <Q-FUNK> 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] <Q-FUNK> 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] <Q-FUNK> 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] <Q-FUNK> _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] <Q-FUNK> 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] <Q-FUNK> 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] <Q-FUNK> nothing debian/ubuntu specific
[19:38] <Q-FUNK> 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] <Q-FUNK> on fd.o ?
[19:43] <Q-FUNK> the current 2.7.7.3 includes all the latest.
[19:44] <Q-FUNK> ...except for OLPC additions
[19:44] <Q-FUNK> 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] <Q-FUNK> I just diffed it
[20:02] <Q-FUNK> very few differences, oddly enough
[20:02] <Q-FUNK> mostly DCON stuff
[20:03] <_bernie> looking
[20:07] <Q-FUNK> I also added that diff to the bug.
[20:08] <Q-FUNK> 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] <Q-FUNK> sure
[20:13] <Q-FUNK> midn you, you guys are using a fixed resolution with a config, aren't you?
[20:13] <Q-FUNK> I'm also wondering why you removed amd.h from so many files
[20:32] <ubotu> 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] <Q-FUNK> for that, you'd need to manage to fix the above ubuntu bug :)
[20:45] <ubotu> New bug: #159617 in xserver-xorg-input-hyperpen "tablet does not work" [Undecided,New] https://launchpad.net/bugs/159617
[20:45] <_bernie> :-/
[20:50] <Q-FUNK> basically, BIOS parsing has to be cleaned up and parts of it shuffled around, for autoconfiguration to work.
[20:50] <Q-FUNK> our Anti did most of the ground work in his coments to the bug
[22:08] <Q-FUNK> _bernie: I get a big hard freeze with the olpc tree, as soon as X tries to load