[05:05] <bryceh> http://www.bryceharrington.org/files/nv_exp.png
[05:39] <tjaalton> the parentheses look confusing :)
[05:43] <bryceh> tjaalton, the ones around (**experimental** beta) ?
[05:44] <bryceh> they appear traditional
[05:44] <tjaalton> the double ones
[05:44] <tjaalton> not just for the new driver
[05:44] <bryceh> oh, gotcha.  yeah, that is a bit weird.  But yeah, traditional
[05:44] <tjaalton> right
[05:44] <bryceh> the first set is part of the title, the second set is added by "something else"
[05:45] <tjaalton> yeah
[05:45] <bryceh> the important thing here is *yay* experimental drivers install and work
[05:45] <bryceh> and, *yay* patched up jockey displays everything properly
[05:46] <tjaalton> isn't 304 the stable series and not beta?
[05:46] <bryceh> pretend it's beta
[05:46] <tjaalton> heh
[05:46] <bryceh> the important thing is it's getting sorted as *last*.  Currently the sort is random.
[05:47] <tjaalton> ah
[05:47] <tjaalton> on another note, the #1 intel bug seems to be fixed now, been surprisingly quiet the past 10h
[05:47] <bryceh> and actually the version in beta right now is a new version (3.04.48) not otherwise available via jockey in precise
[05:48] <tjaalton> not in the distro yet though
[05:48] <bryceh> tjaalton, sweet, what was the bug?
[05:48] <tjaalton> bug 966744
[05:48] <ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Precise) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
[05:48] <bryceh> oh hells yeah
[05:48] <tjaalton> there's an additional kernel commit that ickle sent to intel-gfx
[05:49] <bryceh> tjaalton, good work
[05:49] <bryceh> btw, I had a call with Intel today in regards to stack updates on 12.04
[05:50] <tjaalton> most of it was convincing ickle that the bug with suspend & resume is the same one with a normal dmps cycle that people were hitting (as well) :P
[05:50] <tjaalton> not the backports stuff?
[05:51] <bryceh> they'll be providing us with new packaged versions of all the various pieces they want updated on 12.04.  ddx driver, mesa, cairo, etc. etc.
[05:51] <tjaalton> oh
[05:51] <bryceh> tomorrow I will be hooking them up
[05:51] <bryceh> with a PPA they will be posting this stuff to for testing.
[05:52] <tjaalton> -intel 2.20.9, libdrm 2.4.39, mesa 8.0.5.. what else?-)
[05:53] <bryceh> that, and cairo, intel-vaapi-driver, libva, and...
[05:54] <bryceh> they're creating a dkms package of i915 kernel module + dependent modules.
[05:54] <tjaalton> so they'll run the tests and then later ack them for SRU?
[05:54] <tjaalton> ouch
[05:54] <tjaalton> that'll be fun :)
[05:54] <tjaalton> (dkms)
[05:54] <bryceh> no SRU; ultimate goal will be to get into x-updates.
[05:54] <tjaalton> ok
[05:55] <bryceh> tjaalton, so in fact I need to touch base with you, Sarvatt, RAOF, and other folks concerned about x-updates, that updating these pieces in x-updates is going to be acceptable.
[05:55] <tjaalton> no objections there
[05:56] <tjaalton> it's opt-in anyway
[05:56] <bryceh> think I'll post an email to xorg-devel tomorrow
[05:56] <bryceh> right.
[05:56] <tjaalton> ubuntu-x you mean?-)
[05:56] <bryceh> yeah
[05:56] <bryceh> there might be some concern about changing mesa for x-updates since it's also used for updating nvidia and fglrx
[05:56] <tjaalton> i've not used x-updates at all.. will take a closer look soon
[05:57] <tjaalton> bryceh: shouldn't matter
[05:57] <bryceh> yeah I know.  But I just want to make sure we're all in agreement.
[06:02] <RAOF> I'm perfectly happy for intel to push updates into x-updates; that seems eminently sensible.
[06:04] <tjaalton> let's trick their qa folks into subscribing to -intel bugs.. ;)
[06:04] <bryceh> RAOF, thanks.  Yeah that's my opinion as well.
[06:04] <bryceh> tjaalton, haha
[06:05] <tjaalton> gen4 chips seem to be getting gpu lockups on quantal
[06:05] <tjaalton> more than the others
[06:06] <tjaalton> bryceh: so it's them pushing the updates there, or they'll suggest the versions and we upload?
[06:07] <tjaalton> guess the latter would work best
[06:07] <bryceh> tjaalton, so far it's the  latter
[06:08] <tjaalton> oh hey, looks like the xserver regression with the previous sru for precise that got reverted is fixed now
[06:08] <bryceh> tjaalton, tomorrow I'll create a staging ppa for them under ubuntu-x-swat.  Later when they feel things are sufficiently good to go they'll cue us to pull stuff into x-updates
[06:08] <tjaalton> [PATCH] dix: fix crash on XI 1.x grabs on disabled devices. (#54934)
[06:09] <tjaalton> unless I'm mistaken
[06:09] <tjaalton> bryceh: ok
[06:09] <bryceh> great, what's the bug #?
[06:09] <tjaalton> bug 1021517 (fixed by reverting the sru)
[06:10] <ubottu> Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/1021517
[06:15] <tjaalton> bryceh: you could use x-staging for that
[06:16] <tjaalton> which reminds me, time to clean it up
[06:16] <bryceh> tjaalton, ah good idea, I'll consider that
[06:16] <tjaalton> it's only used once per release
[06:17] <tjaalton> and now with -proposed not even that
[06:17] <bryceh> re bug 1021517, good to hear that's finally getting sorted
[06:17] <ubottu> Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/1021517
[06:18] <bryceh> tjaalton, they may prefer to have a new ppa just for complete isolation.  But I'll think about it tomorrow.
[06:19] <bryceh> now that we can fairly easily delete ppas, no harm in creating extras.
[06:19] <tjaalton> it's empty now
[06:21] <tjaalton> time to delete x-retro?-)
[06:24] <tjaalton> oh well, deleted the obsolete packages (for hardy, jaunty, karmic)
[06:25] <tjaalton> hmm so x-staging & x-testing, what's the difference?
[06:26] <tjaalton> cleaning up -testing
[06:42] <bryceh> theoretically x-retro should still have a use, although admittedly there's probably nothing for it now
[06:43] <bryceh> yeah, x-staging and x-testing are probably redundant.
[06:44] <tjaalton> they're all clean now :)
[06:44] <tjaalton> =empty
[06:44] <tjaalton> sorry, left a couple of packages in retro
[06:48] <bryceh> we need more community contributors.
[07:18] <jcristau> bryceh: you had timo, but then you hired him!
[07:18] <jcristau> :)
[07:20] <bryceh> jcristau, indeed... sensing a pattern...
[07:22] <tjaalton> ha
[07:22] <bryceh> of course, once wayland takes over, we won't have anymore bugs.
[07:23] <jcristau> rrrright
[07:28] <mlankhorst> morning
[07:29]  * bryceh waves
[07:30] <mlankhorst> bryceh: can you endorse my dev application? Also nice work on that nv_exp screen :-)
[07:32] <bryceh> mlankhorst, alright
[07:34] <bryceh> mlankhorst, btw time to start thinking about how we can start getting folks testing the LTS point release X stack.  you probably should get in contact with Jono about getting some attention on it in Oct.
[07:34] <mlankhorst> I think that's a topic for uds
[07:35] <tjaalton> there's some oibaf dude doing stuff all on his own: https://launchpad.net/~oibaf/+archive/graphics-drivers
[07:35] <tjaalton> never heard of him
[07:36] <mlankhorst> but ok I'll just upload all drivers to the ppa again in a bit
[07:37] <mlankhorst> I sort of want to have wine-1.5 upgrading properly with the q-lts-backport ppa before I want more widespread testing on it
[07:38] <bryceh> mlankhorst, good.  Yeah I think UDS may be postponing it too far, you may regret it later.  But if you can get testing started now, you'll be in a much better position when UDS rolls around.
[07:38] <mlankhorst> well the real challenge IS going to be getting fglrx working, the rest should be fine
[07:38] <tjaalton> there's a compatible version in quantal now
[07:39] <tjaalton> 9.000000
[07:39] <bryceh> yeah I saw there's a new version today
[07:39] <mlankhorst> ok in that case I'll just re-upload the entire stack
[07:39] <bryceh> tjaalton, "oibaf" sounds familiar for some reason
[07:39] <tjaalton> it was on phoronix once, I think
[07:40] <bryceh> tjaalton, would you mind touching base with him and see if he'd be interested in joining swat?  Looks like a useful fellow.
[07:40] <mlankhorst> tjaalton/raof: can you endorse my dev application?
[07:41] <bryceh> might be he's only interested in building a side-empire; of course that's fine too.  We should invite him to be part of the team none-the-less.
[07:41] <tjaalton> bryceh: yeah, I could
[07:42] <tjaalton> mlankhorst: sure
[07:42] <mlankhorst> https://wiki.ubuntu.com/MaartenLankhorst/DeveloperApplication
[08:31] <mlankhorst> rebuilding q-lts-backports atm :-)
[09:41] <mlankhorst> weird, my other system has the corrupted bg too
[09:44] <mlankhorst> oh
[09:44] <mlankhorst> it was still trying the old background but that one was probably removed
[09:45] <mlankhorst> so instead it did the insane thing and never drew anything at all :-)
[09:54] <tjaalton> hehe
[09:56] <mlankhorst> now I fear that my -all package might not show up in armhf :(
[10:08] <ogra_> mlankhorst, why wouldnt it ?
[10:09] <mlankhorst> copied it from a ppa that didn't have it enabled and it didn't list it
[10:09] <ogra_> oh, yeah, PPAs are spethial
[10:09] <mlankhorst> so just rebuilding now, just in case
[10:11] <mlankhorst> trying to get armhf q-lts-backports too
[10:16] <mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa armhf enabled version
[10:17] <ricotz> mlankhorst, you probably want to use the newer wayland snapshot while you are using one
[10:18] <mlankhorst> ricotz: I just take whatever is going to end up in quantal, it's just to satisfy build-depends
[10:18] <ricotz> alright
[10:20] <ricotz> mlankhorst, updating wayland like this will break the current precise mesa if this matters
[10:20] <mlankhorst> sigh, I guess the solution would be to rename wayland too?
[10:20] <ricotz> i guess so
[10:21] <mlankhorst> does weston need updates too in that case?
[10:21] <ricotz> not sure if this is worth a trouble to prevent runtime breaks but it will break the precise mesa build at least
[10:22] <ricotz> mlankhorst, yes, if you want to keep it working ;)
[10:22] <mlankhorst> RAOF: ping?
[10:23] <tjaalton> lets just update wayland/weston in precise
[10:24] <tjaalton> not that it's any use, but neither is the old version
[10:24] <mlankhorst> yeah and have it depend on the renamed packages
[10:24] <tjaalton> +of
[10:24] <mlankhorst> it should be possible to just use new mesa with old xorg
[10:24] <tjaalton> ahh right
[10:24] <tjaalton> now i see
[10:24] <mlankhorst> won't be really useful
[10:24] <tjaalton> damn build-depends
[10:25] <tjaalton> or just remove the old wayland/weston :)
[10:25] <tjaalton> maybe not possible, dunno
[10:25] <ricotz> tjaalton, removing them sounds like a better idea
[10:25] <tjaalton> hmm, same effect really
[10:26] <mlankhorst> it's in universe though
[10:26] <tjaalton> mesa needs newer libwayland-dev, so it has to be updated, and no reason to keep the old one
[10:26] <tjaalton> really?
[10:26] <tjaalton> weston maybe
[10:26] <tjaalton> it doesn't matter
[10:26] <mlankhorst> oh its not, in main
[10:26] <mlankhorst> :(
[10:27] <mlankhorst> however we could probably update it and make it depend on the new stack if needed
[10:27] <tjaalton> right
[10:27] <tjaalton> the old one is obsolete anyway
[10:27] <tjaalton> so just sru whatever ends up in quantal
[10:27] <mlankhorst> I'll leave it at the new version for now, I think it builds just fine without the new mesa so there shouldn't be an issue
[10:28] <tjaalton> hmm, there's still the old version in precise, new will end up in -updates
[10:28] <tjaalton> or is it
[10:28] <tjaalton> I don't know how that archive s*it works :)
[10:29] <tjaalton> right, you can use the old one explicitly, -updates will have the new one
[10:29] <mlankhorst> yeah it's great fun with all those depends
[10:29] <tjaalton> and mesa is happy
[10:30] <mlankhorst> could try if old mesa builds against new wayland
[10:30] <tjaalton> unless the old mesa isn't happy with the new version (in case there'll be bugfixes)
[10:30] <tjaalton> echo :)
[10:31] <mlankhorst> :P
[10:31] <mlankhorst> -EAGAIN really
[10:34] <mlankhorst> and I didn't even upload xorg-server yet :(
[10:35] <mlankhorst> although at that part the fun stops since everything is easy from there..
[10:44] <ricotz> tjaalton, thanks :)
[10:46] <mlankhorst> I should probably add the renamed linux kernel to recommends as well
[10:47] <tjaalton> ricotz: the other one needs an ffe first
[10:47] <tjaalton> libbluray looked more like a bugfix release
[10:49] <ricotz> tjaalton, libaacs is fine already
[10:49] <ricotz> tjaalton, hmm, my name doesnt come up as uploaded in launchpad for libbluray
[10:49] <ricotz> *uploader
[10:52] <tjaalton> ooh, syncpackage supports fakesync
[12:27] <mlankhorst> nice
[13:35] <cos-> hello, ubuntu-bug asks to get technical help first before submitting a new bug but i guess i'll just do it first
[13:38] <tjaalton> just file the bug
[13:41] <cos-> i'm a bit confused about how to set up a elo serial touchscreen.
[13:41] <cos-> i tried to follow these instructions https://help.ubuntu.com/community/EloTouchScreen
[13:41] <cos-> .. but it says evtouch has been removed from ubuntu
[13:42] <cos-> the touch screen is detected by xorg (after running inputattach) but i'm not sure how to configure it
[13:42] <tjaalton> google for peter hutterer's blog
[13:42] <cos-> should the InputClass definition in xorg work without evtouch?
[13:43] <tjaalton> there should be instructions for setting it up with -evdev
[13:43] <cos-> thanks, found it
[13:44] <cos-> i already filed this, but i suppose evdev is the way to go https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-elographics/+bug/1058109
[13:44] <ubottu> Launchpad bug 1058109 in xserver-xorg-input-elographics (Ubuntu) "Elographics touch event freezes Xorg" [Undecided,New]
[13:45] <tjaalton> yeah, iirc
[13:46] <cos-> i believe i tried everything in this post http://who-t.blogspot.fi/2012/07/elographics-touchscreen-setup.html
[13:47] <cos-> i don't have the touchscreen here at work so i could verify but i'll try again next week
[13:47] <cos-> the actual problem is that y-coodrinate is reversed and the evdev InvertY option does nothing
[13:49] <tjaalton> ok, that's a bug then
[13:50] <cos-> should i file it?
[13:50] <smartboyhw> cos-, should
[13:51] <cos-> if it helps, i can lend the hardware to devs in finland if needed.. and possibly elsewhere unless shipping is very expensive
[13:51] <tjaalton> heh, i'm in espoo
[13:53] <cos-> i'm coming to wärk:fest in 3 weeks and could bring the hw with me if needed
[13:58] <cos-> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1058120
[13:58] <ubottu> Launchpad bug 1058120 in xserver-xorg-input-evdev (Ubuntu) "InvertY option is ignored on ELO touchscreen" [Undecided,New]
[14:18]  * mlankhorst wonders if launchpad will time out from simply copying over mesa for 4 archs
=== yofel_ is now known as yofel
[23:10] <mlankhorst> well my local system is definitely beating the launchpad builders