| Sarvatt | mlankhorst: no quantal in winehq? :( | 01:23 |
|---|---|---|
| Sarvatt | finally updated | 01:23 |
| Sarvatt | jeeze having a DE up in 3 seconds is nuts, sata3 ssd's are really worth it | 01:27 |
| bjsnider | it takes me about 8 secs in precise, is quantal faster? | 01:28 |
| Sarvatt | maybe its quantal, not sure | 01:28 |
| bjsnider | i've got an intel 520 here, very fast | 01:28 |
| Sarvatt | upgraded from a sandybridge macbook air to a thinkpad x1 carbon with a 2x faster ssd and now its 3 instead of 7 | 01:28 |
| bjsnider | home is mounted on the ssd too? | 01:30 |
| Sarvatt | one big drive yeah | 01:30 |
| bjsnider | ok, maybe that's it, because i've only got root on the ssd here | 01:30 |
| bjsnider | maybe i should mount more of home on the ssd | 01:31 |
| Sarvatt | just going by [ 3.063] X.Org X Server 1.13.0 and wifi being ready 5 seconds into the boot in dmesg, takes me way longer to type a password to actually log in | 01:31 |
| Sarvatt | X is up 7 seconds in in the macbook air | 01:31 |
| Sarvatt | other laptop has a crappy broadcom that needs the proprietary driver to work that takes way longer to associate, might have something to do with it seeming more laggy | 01:34 |
| bjsnider | crappy broadcom, but you repeat yourself | 01:51 |
| === ripps_ is now known as ripps | ||
| tjaalton | ha, darktama closed the nvd9 dp bug after i sub'd to it, saying it's supported. need to file a new bug then | 03:57 |
| RAOF | Heh | 04:00 |
| Sarvatt | tjaalton: supported on 3.7 after the rewrite? | 04:00 |
| tjaalton | Sarvatt: no, 3.5 | 04:01 |
| tjaalton | it almost works, just claims there's no edid | 04:02 |
| tjaalton | but testing with just the discrete I got it hung with 3.6rc and then it confused the monitor so bad that I had to pull the power plug | 04:03 |
| RAOF | Awesome! | 04:07 |
| Sarvatt | tjaalton: sounds like typical DP fare | 04:10 |
| tjaalton | with debug output I could see the modes, but in the end nouveau would just throw in the towel | 04:11 |
| Sarvatt | i've had to pull the battery and hold power for 2 minutes to drain the backup on every eDP system at some point :P | 04:11 |
| mlankhorst | Sarvatt: erm the quantal package for wine is the same as precise, so just set it to precise | 05:58 |
| mlankhorst | I just didn't want to upload twice | 05:58 |
| Sarvatt | mlankhorst: but but its compiled with gcc-4.6, thats blasphemy for phoronix | 05:58 |
| RAOF | What? Not compiled with clang?!?!?!!1111 | 06:00 |
| * ricotz is pushing nvidia 304.48 to xedgers | 06:01 | |
| Sarvatt | no -ffruit-loops by default from 4.7 :( | 06:01 |
| Sarvatt | yeah its no big deal, thats how the wine ppa has always worked, quantal doesnt go in till after it releases :P | 06:01 |
| mlankhorst | oh it's mostly laziness really | 06:01 |
| mlankhorst | I cba to do the extra work | 06:01 |
| ricotz | mlankhorst, hi, there is no extra work though | 06:02 |
| ricotz | ;) | 06:02 |
| ricotz | just a dch and debuild -S -sd | 06:02 |
| mlankhorst | ^extra work | 06:02 |
| Sarvatt | there was when ia32-libs was a thing | 06:02 |
| Sarvatt | ricotz: i'm almost thinking no xserver 1.13 in edgers for precise, what do you think? | 06:04 |
| Sarvatt | not much point when it will be in the backport ppa | 06:04 |
| mlankhorst | just alter the scripts to rename *ducks* | 06:05 |
| Sarvatt | and 12.04.2 come jan | 06:05 |
| ricotz | Sarvatt, hmm, i see, updating the 1.12 package might be useful then | 06:06 |
| mlankhorst | xorg-server-crack-edgers | 06:06 |
| Sarvatt | thats easier, just reuse the old debian/ from the current one once a month or something :) | 06:07 |
| mlankhorst | oops, need to copy the prime xxv's over | 06:08 |
| Sarvatt | i woulda said noone would notice if you just left it but yeah people thought we were on mesa 8.x in quantal because of that ppa | 06:09 |
| mlankhorst | there, now qbp has prime, assuming we get xrandr updated in time and/or the autobind server patch | 06:09 |
| mlankhorst | yeah I'll update it | 06:09 |
| Sarvatt | i dont know how you're updating it so hesitant to | 06:10 |
| mlankhorst | ...? | 06:10 |
| Sarvatt | dont want to screw it up :) | 06:10 |
| mlankhorst | I don't understand what you mean there | 06:10 |
| Sarvatt | oh you already updated it all, was just wanting to update it last week when things changed a lot in quantal but didnt want to step on any toes | 06:11 |
| mlankhorst | yeah don't worry about that, I do need to push the changed scripts though :) | 06:12 |
| mlankhorst | -extraversion="~precise1~ppa3" | 06:13 |
| mlankhorst | +extraversion="~precise1~ppa4" | 06:13 |
| Sarvatt | which scripts? | 06:13 |
| Sarvatt | ah in xorg-pkg-tools, how did i miss that | 06:13 |
| mlankhorst | you didn't think I would do it by hand did you? :p | 06:14 |
| mlankhorst | only xorg and xorg-lts-quantal, but I need to update those still | 06:15 |
| Sarvatt | blob naming might be a PITA | 06:16 |
| ricotz | i dont think blob needs to be renamed | 06:16 |
| Sarvatt | need to somehow move people from nvidia-current-updates onto nvidia-current-updates-quantal | 06:16 |
| mlankhorst | Sarvatt: no, we just make nvidia-current-updates work for both.. | 06:17 |
| Sarvatt | true | 06:17 |
| mlankhorst | iirc that was a bit harder for fglrx though | 06:17 |
| Sarvatt | artifical abi restrictions are a thing of the past all the sudden, where tseliot made them provide multiple ones | 06:18 |
| mlankhorst | but hey if that plan fails it's going into the rename bin | 06:18 |
| Sarvatt | not sure he made 304.xx provide xserver 1.13's abi in -updates in the precise-proposed one though | 06:18 |
| Sarvatt | but still people would need to be moved from nvidia-current to nvidia-current-updates | 06:19 |
| mlankhorst | yeah nvidia-current-updates might need provides: nvidia conflicts nvidia to join the rest | 06:19 |
| Sarvatt | would be nice if the transition from nvidia-current to nvidia-current-updates was automatic somehow, needs to be | 06:20 |
| mlankhorst | add those conflicts and provides, and it will be.. | 06:21 |
| mlankhorst | or at least probably, not 100% sure | 06:22 |
| Sarvatt | post release, upload another nvidia-current moving people over to -updates? good idea | 06:22 |
| Sarvatt | except some people want to stay with a working driver | 06:22 |
| mlankhorst | I don't think it will be impossible | 06:22 |
| mlankhorst | don't forget, the rest of the stack already works in a similar way | 06:23 |
| Sarvatt | best we can do is keep people on a long term support branch, its silly to stay on one driver forever imo | 06:23 |
| mlankhorst | yeah I plan on just making the old one the default, so if people update they just have to update to newer nvidia driver first, or afterwards | 06:24 |
| Sarvatt | its really crappy the first lts backport wont even be useful :( | 06:26 |
| Sarvatt | being done for haswell, but quantal wont work | 06:26 |
| Sarvatt | limited to the kernel though, we'll have to ship 3.7 or 3.8 even with quantal userspace | 06:27 |
| mlankhorst | you say that as if it's a bad thing | 06:34 |
| mlankhorst | would rather test while it's less useful than when it's really a must have | 06:35 |
| Sarvatt | it was a must have weeks ago, we have a bunch of OEM haswells people are freaking out about :) | 06:36 |
| mlankhorst | so do what we always do, backport drm into current kernel? | 06:36 |
| mlankhorst | :D | 06:36 |
| Sarvatt | oems dont pay for that to happen, everything has to be SRUed :P | 06:37 |
| mlankhorst | business as usual then :-) | 06:38 |
| Sarvatt | yep | 06:38 |
| Sarvatt | every tock is a problem apparently | 06:40 |
| RAOF | That's been the general case, yes. | 06:40 |
| RAOF | Although I don't think the GPU side is actually following the tick/tock cadence the same way. | 06:40 |
| mlankhorst | it's tocktock | 06:40 |
| RAOF | Probably because the GPU world moves faster. | 06:40 |
| Sarvatt | sandybridge we shipped with no acceleration at all in 10.10 | 06:40 |
| RAOF | But it did support KMS! That's a pretty neat feature :) | 06:41 |
| mlankhorst | well with llvmpipe fallback I don't know how useful it is to only support kms | 06:41 |
| RAOF | Actually, kms + llvmpipe on haswell will probably be reasonably useable :) | 06:41 |
| mlankhorst | oh I mean that last time I tried llvmpipe glitched quite badly | 06:42 |
| RAOF | Ah. I think unity's fixed that. | 06:42 |
| RAOF | If not, they know *exactly* what they need to do to fix it. | 06:42 |
| Sarvatt | yeah pretty sure i saw them mention a ccsm change that fixed llvmpipe compiz a few weeks ago | 06:44 |
| Sarvatt | in the cirrus kvm bug | 06:45 |
| mlankhorst | ah :-) | 06:45 |
| Sarvatt | https://bugs.launchpad.net/compiz/+bug/1021104 | 06:45 |
| ubottu | Launchpad bug 1021104 in Compiz Core "Severe damage artefacts and flickering when using LLVMpipe" [Medium,Triaged] | 06:45 |
| tjaalton | unity is better, but compiz still crashes quite easily with llvmpipe | 06:57 |
| Sarvatt | tseliot: have you given any thought to the q-lts-backports ubuntu-x-swat ppa that is going to go into q after release? -updates drivers you upload to precise need to provide newer abis if they support it for that i think | 06:58 |
| tseliot | Sarvatt: nvidia-current-updates is already in proposed (same version as the one in quantal), as for the rest, we don't have drivers which support the new ABI yet | 07:00 |
| Sarvatt | nvidia-current-updates in proposed does, does the precise-proposed one provide the xserver 1.13 abi too? | 07:01 |
| Sarvatt | somehow blobs are going to need to work with all of that, its going to be a headache | 07:01 |
| tjaalton | new abi support can be added as soon as the driver (properly) supports it, despite the release it's targeted at | 07:01 |
| tjaalton | hope that was engrish | 07:02 |
| tseliot | Sarvatt: we have 304.43-0ubuntu0.1 in precise-proposed but I'll have to hardcode the ABI there too | 07:03 |
| tjaalton | you have to hardcode the supported abi's in every release since it started :) | 07:05 |
| tjaalton | *since the package started to hardcode the abi | 07:06 |
| Sarvatt | going to be extra weird with nvidia-304 starting next release | 07:08 |
| tjaalton | how so? | 07:09 |
| Sarvatt | they're already at 306.xx on the windows side after dropping 6xxx and 7xxx | 07:09 |
| tseliot | also the 304.xx is gonna be a legacy driver... | 07:10 |
| Sarvatt | somehow transitioning people on 6 and 7xxx using nvidia-current to the new nvidia-304 package, don't even see how thats possible | 07:11 |
| tseliot | shall I call it nvidia-304? | 07:11 |
| tseliot | it would make sense | 07:12 |
| Sarvatt | well you already set that precident with 96 and 173 | 07:12 |
| tseliot | right | 07:12 |
| tseliot | but no, transitioning won't be easy unless we add some code in Update manager (as we did in the past) | 07:12 |
| mlankhorst | :( | 07:16 |
| === lilstevie_ is now known as lilstevie | ||
| RAOF | tseliot: We should really have a debian/supported_abis file for the nvidia/fglrx drivers and generate the Depends from that :) | 07:33 |
| * ogra_ thought you can do that with a var like ${slib:depends} | 07:34 | |
| ogra_ | *shlib | 07:34 |
| tseliot | RAOF: that's a good idea. Are there any other packages that do this already or would I have to write new code for it? | 07:35 |
| RAOF | tseliot: You'd need to write new code for it, I think. | 07:35 |
| tseliot | ok | 07:35 |
| mlankhorst | I don't see how updating some other file instead of control would help matters? | 07:35 |
| RAOF | tseliot: I don't suppose there's an easy way to *automatically* discover what ABIs are supported? | 07:36 |
| tseliot | mlankhorst: right now we update the debian rules which, in turn, uses debian/control.in to generate debian/control | 07:36 |
| mlankhorst | can't you just use a simple .vars file? | 07:37 |
| RAOF | Yes. | 07:37 |
| RAOF | Well, ish. | 07:37 |
| ogra_ | what about ${xviddriver:Depends}, couldnt that just include the abi ? | 07:37 |
| RAOF | ogra_: It does; but the binary drivers support more than one ABI. | 07:37 |
| tseliot | RAOF: I'm not sure, maybe I should see if there's something we can extract from their README file | 07:37 |
| ogra_ | RAOF, well, they will only support one in one distro release :) | 07:37 |
| RAOF | So we want to Depends: xorg-video-11 | xorg-video-10 | xorg-video-13 | ... | 07:38 |
| ogra_ | why ? | 07:38 |
| ogra_ | your xorg will only provide one ABI anyway | 07:38 |
| tjaalton | tseliot: you can't automate that part.. | 07:38 |
| RAOF | Partially because it's a more accurate description of their dependencies. Partially because I don't think we particularly want to rename+backport the nvidia packages, so having them be forward-compatible is pretty nice. | 07:39 |
| tjaalton | tseliot: knowing what happened last time | 07:39 |
| tseliot | tjaalton: yes, it's better if we are in control | 07:40 |
| tjaalton | xserver has debian/serverminver, similar plumbing would work with the blobs | 07:40 |
| tjaalton | so debian/control has ${blob:Provides} and debian/rules then replaces that with some string | 07:41 |
| tseliot | tjaalton: that's just for one ABI though | 07:41 |
| ogra_ | RAOF, apart from the fact that nvidia rarely even keeps up (or is ahead) with the ABi i would agree :) | 07:41 |
| tseliot | the serverminver | 07:41 |
| tjaalton | tseliot: I meant the mechanism | 07:41 |
| * ogra_ is still waiting for a tegra release that supports more than ABI 12 | 07:41 | |
| tjaalton | have a file with the abi's, then rules replaces a string in control | 07:41 |
| tseliot | tjaalton: right, I'll see how that works and see if I can reuse the code | 07:42 |
| RAOF | tjaalton, tseliot: Have a file with the abis, and then a rules fragment that dumps them in .substvars. | 07:42 |
| RAOF | That's more idiomatic; that's how ${shlibs:Depends} et al are done. | 07:43 |
| tjaalton | hmm right the xserver example was something else :) | 07:43 |
| tseliot | either way it's fine by me | 07:43 |
| tjaalton | use what RAOF suggested | 07:44 |
| RAOF | gen-abi-substvars: cat substvars >> nvidia-current.substvars ☺ | 07:44 |
| tseliot | ok then | 07:44 |
| ogra_ | RAOF, that would brak on the smiley :P | 07:45 |
| ogra_ | *break | 07:45 |
| RAOF | Lies! dash is perfectly capable of writing to utf-8 filenames! | 07:46 |
| tseliot | :D | 07:46 |
| mlankhorst | ugh guess i better work on my presentation | 08:26 |
| tjaalton | about? | 08:30 |
| mlankhorst | optimus | 08:30 |
| tjaalton | of course.. | 08:31 |
| mlankhorst | and all the kerne lcrap I've been working on I suppose | 08:31 |
| === lool- is now known as lool | ||
| mlankhorst | ok the xorg-server patch for autobinding seems to work on my laptop | 09:49 |
| mlankhorst | can someone push out a new xorg-server version? | 09:50 |
| tjaalton | what's there? | 10:00 |
| tjaalton | oh that | 10:01 |
| tjaalton | forgot the udev patch, but I have it here.. | 10:01 |
| tjaalton | need to run though | 10:02 |
| tjaalton | next week is soon enough :) | 10:02 |
| mlankhorst | hehe sure | 10:02 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!