bryceh | http://www.bryceharrington.org/files/nv_exp.png | 05:05 |
---|---|---|
tjaalton | the parentheses look confusing :) | 05:39 |
bryceh | tjaalton, the ones around (**experimental** beta) ? | 05:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
bryceh | tjaalton, good work | 05:49 |
bryceh | btw, I had a call with Intel today in regards to stack updates on 12.04 | 05:49 |
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:50 |
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:51 |
tjaalton | -intel 2.20.9, libdrm 2.4.39, mesa 8.0.5.. what else?-) | 05:52 |
bryceh | that, and cairo, intel-vaapi-driver, libva, and... | 05:53 |
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:54 |
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:55 |
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:56 |
tjaalton | bryceh: shouldn't matter | 05:57 |
bryceh | yeah I know. But I just want to make sure we're all in agreement. | 05:57 |
RAOF | I'm perfectly happy for intel to push updates into x-updates; that seems eminently sensible. | 06:02 |
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:04 |
tjaalton | gen4 chips seem to be getting gpu lockups on quantal | 06:05 |
tjaalton | more than the others | 06:05 |
tjaalton | bryceh: so it's them pushing the updates there, or they'll suggest the versions and we upload? | 06:06 |
tjaalton | guess the latter would work best | 06:07 |
bryceh | tjaalton, so far it's the latter | 06:07 |
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:08 |
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:09 |
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:10 |
tjaalton | bryceh: you could use x-staging for that | 06:15 |
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:16 |
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:17 |
bryceh | tjaalton, they may prefer to have a new ppa just for complete isolation. But I'll think about it tomorrow. | 06:18 |
bryceh | now that we can fairly easily delete ppas, no harm in creating extras. | 06:19 |
tjaalton | it's empty now | 06:19 |
tjaalton | time to delete x-retro?-) | 06:21 |
tjaalton | oh well, deleted the obsolete packages (for hardy, jaunty, karmic) | 06:24 |
tjaalton | hmm so x-staging & x-testing, what's the difference? | 06:25 |
tjaalton | cleaning up -testing | 06:26 |
bryceh | theoretically x-retro should still have a use, although admittedly there's probably nothing for it now | 06:42 |
bryceh | yeah, x-staging and x-testing are probably redundant. | 06:43 |
tjaalton | they're all clean now :) | 06:44 |
tjaalton | =empty | 06:44 |
tjaalton | sorry, left a couple of packages in retro | 06:44 |
bryceh | we need more community contributors. | 06:48 |
jcristau | bryceh: you had timo, but then you hired him! | 07:18 |
jcristau | :) | 07:18 |
bryceh | jcristau, indeed... sensing a pattern... | 07:20 |
tjaalton | ha | 07:22 |
bryceh | of course, once wayland takes over, we won't have anymore bugs. | 07:22 |
jcristau | rrrright | 07:23 |
mlankhorst | morning | 07:28 |
* bryceh waves | 07:29 | |
mlankhorst | bryceh: can you endorse my dev application? Also nice work on that nv_exp screen :-) | 07:30 |
bryceh | mlankhorst, alright | 07:32 |
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:34 |
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:35 |
mlankhorst | but ok I'll just upload all drivers to the ppa again in a bit | 07:36 |
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:37 |
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:38 |
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:39 |
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:40 |
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:41 |
tjaalton | mlankhorst: sure | 07:42 |
mlankhorst | https://wiki.ubuntu.com/MaartenLankhorst/DeveloperApplication | 07:42 |
mlankhorst | rebuilding q-lts-backports atm :-) | 08:31 |
mlankhorst | weird, my other system has the corrupted bg too | 09:41 |
mlankhorst | oh | 09:44 |
mlankhorst | it was still trying the old background but that one was probably removed | 09:44 |
mlankhorst | so instead it did the insane thing and never drew anything at all :-) | 09:45 |
tjaalton | hehe | 09:54 |
mlankhorst | now I fear that my -all package might not show up in armhf :( | 09:56 |
ogra_ | mlankhorst, why wouldnt it ? | 10:08 |
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:09 |
mlankhorst | trying to get armhf q-lts-backports too | 10:11 |
mlankhorst | https://launchpad.net/~mlankhorst/+archive/ppa armhf enabled version | 10:16 |
ricotz | mlankhorst, you probably want to use the newer wayland snapshot while you are using one | 10:17 |
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:18 |
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:20 |
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:21 |
ricotz | mlankhorst, yes, if you want to keep it working ;) | 10:22 |
mlankhorst | RAOF: ping? | 10:22 |
tjaalton | lets just update wayland/weston in precise | 10:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
mlankhorst | :P | 10:31 |
mlankhorst | -EAGAIN really | 10:31 |
mlankhorst | and I didn't even upload xorg-server yet :( | 10:34 |
mlankhorst | although at that part the fun stops since everything is easy from there.. | 10:35 |
ricotz | tjaalton, thanks :) | 10:44 |
mlankhorst | I should probably add the renamed linux kernel to recommends as well | 10:46 |
tjaalton | ricotz: the other one needs an ffe first | 10:47 |
tjaalton | libbluray looked more like a bugfix release | 10:47 |
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:49 |
tjaalton | ooh, syncpackage supports fakesync | 10:52 |
mlankhorst | nice | 12:27 |
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:35 |
tjaalton | just file the bug | 13:38 |
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:41 |
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:42 |
tjaalton | there should be instructions for setting it up with -evdev | 13:43 |
cos- | thanks, found it | 13:43 |
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:44 |
tjaalton | yeah, iirc | 13:45 |
cos- | i believe i tried everything in this post http://who-t.blogspot.fi/2012/07/elographics-touchscreen-setup.html | 13:46 |
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:47 |
tjaalton | ok, that's a bug then | 13:49 |
cos- | should i file it? | 13:50 |
smartboyhw | cos-, should | 13:50 |
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:51 |
cos- | i'm coming to wärk:fest in 3 weeks and could bring the hw with me if needed | 13:53 |
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] | 13:58 |
* mlankhorst wonders if launchpad will time out from simply copying over mesa for 4 archs | 14:18 | |
=== yofel_ is now known as yofel | ||
mlankhorst | well my local system is definitely beating the launchpad builders | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!