[01:06] <bryceh> wazzah, bugbot lives:  https://launchpad.net/~bugbot
[01:06] <bryceh> heya nigelb
[01:06] <bryceh> lessee
[01:08] <bryceh> nigelb, neither; looks like the patch is against xserver-xorg-input-evdev
[01:08] <bryceh> nigelb, however be careful; I think some input devices prefer the axes oriented the way they are
[01:09] <bryceh> it may be that a more sophisticated patch is needed to cover this corner case without breaking the general case
[01:09] <bryceh> but I haven't looked at it too deeply
[01:10] <bryceh> nigelb, probably would be wise to package the patch in a ppa and get a few people with different kinds of mice to test it before putting it in for sponsorship
[01:12] <bryceh> nigelb, or alternatively forward the patch upstream to bugs.freedesktop.org for review
[01:18] <nigelb> bryceh: I'll forwards \o/
[01:18] <nigelb> Thank you for looking :)
[01:19] <bryceh> no prob
[01:19]  * nigelb hugs bryceh :)
[01:20]  * bryceh hugs nigelb
[01:20] <nigelb> :)
[01:20] <bryceh> fwiw, we get axis fiddling patches like that one for the input drivers quite a lot... one set of users send patches to flip the axis one way, another note a regression and send patches to flip them back.  :-D
[01:21] <nigelb> haha
[01:21] <bryceh> upstream knows the right way to do things
[01:22] <bryceh> Sarvatt, RAOF, prepare for an onslaught of bugbot spam :-)
[01:22] <bryceh> Sarvatt, RAOF, at least now it's more easily procmailable
[01:23] <nigelb> bugbot? email bugs?
[01:23] <Sarvatt> bryceh: whats bugbot? I've already got 23k unread in my ubuntu-x-swat folder :D
[01:23] <bryceh> Sarvatt, prepare for 23k more
[01:24] <bryceh> bugbot is basically a new launchpad user account I'm going to use for running my arsenal scripts
[01:24] <bryceh> so all the arsenal spam will be nicely disassociated from me now
[01:24] <bryceh> my karma shall suffer greatly.  ;-)
[01:25] <nigelb> lol
[01:25] <nigelb> bryceh: you worked on lp team for a cycle, shoulda put in a hack to increase your karma :p
[01:27] <bryceh> hmm, well I don't think I can fiddle my karma score directly, but I certainly can disable the accounts of anyone with more karma than I... 
[01:27]  * bryceh rubs hands together "bwahahaha"
[01:28] <nigelb> haha
[02:02] <Sarvatt> bugbot has only gotten 2 mails through to my inbox so far :)
[04:48] <RAOF> Why did I put maverick's mesa on the ubuntu-maverick branch??
[10:30] <apw> RAOF, Sarvatt, yo ... do you remember the discussion on which AGP drivers we needed built-in ... the notes say (only 4) but there are no hints as to which 4
[10:31] <RAOF> It was intel, amd, nvidia, via, right?
[10:35] <apw> RAOF, hrm i don't think we really talkaed about it, i am happy with those four though
[10:36] <RAOF> I only recall saying that we needde them built in, honestly, but I think those are the ones we need.
[10:36] <apw> RAOF, thats good enough for me :)
[10:36] <apw> i will start with those and you can tell us if thats not suffiicient :)
[10:40] <tseliot> RAOF: built-in? I guess this won't cause issues with proprietary drivers since we blacklist those drivers in the initramfs, right?
[10:41] <RAOF> That's a good question; the binary drivers have their own agp drivers, don't they?
[10:42] <tjaalton> probably a non-issue, since airlied thought about making them mandatory anyway
[10:42] <tjaalton> some time ago
[10:42] <RAOF> I understand that fedora builds in the agp drivers, so yeah.
[10:42] <tjaalton> right
[10:42] <apw> well if they are builtin that won't let you blacklist them anymore
[10:42] <apw> well if fedora does it  i guess we must be ok :)
[10:45]  * apw warns you that the next upload of the kernel will carry the switch from =m to =y for these AGP drivers
[10:50] <RAOF> tseliot: fglrx and nvidia are actually working in natty at the moment, right?  We'll be able to spot any problems this might cause?
[10:50] <tseliot> RAOF: yes, they are
[10:51] <tseliot> apw: if we cannot blacklist them, then it's not fine
[10:51] <apw> how does fedora handle this i wonder
[10:52] <jcristau> why would you blacklist an agp driver?
[10:52] <RAOF> These are the agp drivers, not the video drivers - are you sure they're a problem?
[10:52]  * apw cirtainly has no idea
[10:52] <apw> tseliot, do you have an example of what we blacklist when we enable prop drivers ?
[10:53] <RAOF> I don't think we currently blacklist any agp drivers in the proprietary driver voodoo; we blacklist nouveau in nvidia and radeon in fglrx, but that's different.
[10:54] <apw> yeah not proposing anything that high in the stack gets built-in
[10:54] <tseliot> apw: we simply blacklist nouveau and the other proprietary nvidia flavours when enabling nvidia.
[10:54] <apw> so i think we are probabally ok then
[10:54] <apw> but we do need to watch out when the next kernel goes in to be 100% sure
[10:55] <tseliot> RAOF, apw: ah, sorry, I misread what you wrote. I missed the "agp" part
[10:55] <jcristau> i certainly haven't heard of any issues since we started having the agp drivers builtin
[10:55] <tseliot> that's ok
[10:55] <jcristau> (we = Debian)
[10:55] <apw> tseliot, i assume you have some h/w you could test on, if I made up some test kernels
[10:55] <apw> jcristau, thats a good information point
[10:55] <apw> (thanks)
[10:55] <tseliot> apw: sure, I can test things here but, as I said, it should be ok to build in agp drivers
[10:56] <apw> ok ... done ... thansk
[10:58] <RAOF> apw: thanks.
[13:47] <Sarvatt> intel_agp.sucks=1 passed to grub, blacklisted :)
[13:48] <jcristau> way to prevent stuff from working :)
[13:49] <Sarvatt> ah hah
[13:49] <Sarvatt> agp=off
[13:50] <Sarvatt> then nvagp loads
[13:50] <Sarvatt> with agp :)
[17:27] <kklimonda> hey
[17:29] <kklimonda> would it be possible to contact ati/nvidia and ask them to add a command some line argument, to their driver installers, like "--i-am-aware-that-by-installing-those-drivers-i-void-the-ubuntu-warranty" or something similar, and refuse to install on newer Ubuntu systems without it being set?
[17:30] <kklimonda> no single week passes without me helping some poor soul fix their system after installing those drivers..
[17:30] <tseliot> kklimonda: in theory there's already a hook for something like that. It only works if the nvidia packages are already installed though (I guess)
[17:31] <tseliot> this applies only to nvidia
[17:32] <kklimonda> tseliot: apparently, that's not enough :/
[17:33] <tseliot> kklimonda: I can't really force more invasive changes into their installers though. I should really work to improve the situation though. The main problem is my lack of time
[17:33] <tseliot> it's still on my todo list though
[17:34] <kklimonda> tseliot: can't you just ask? their current installers pro-actively break systems ;)
[17:34] <kklimonda> and for some reason people blame us :/
[17:35] <tseliot> kklimonda: I already did. Which is why I said that I "can't" do that
[17:35] <bjsnider> tseliot, it only works if the nvidia-common package is installed. i think it should be put into jockey.common
[17:36] <tseliot> bjsnider: see, I don't even remember how I implemented the whole thing...
[17:36] <bjsnider> hahaha
[17:36] <bjsnider> i didn't expect that response
[17:36] <bjsnider> i think the flaw was putting the hook into a package that is not automatically on everyone's system (nvidia-common)
[17:37] <bjsnider> but it was a good idea
[17:37] <tseliot> bjsnider: maybe, as you said, jockey is a better place for that
[17:37] <bjsnider> i think it should be in a package that is part of ubuntu-desktop or the like
[17:39] <bjsnider> that way the user would have to seriously bork their system to even try the nvidia-installer
[17:41] <bjsnider> kklimonda, there's a thread on the nvforums website created by the nvidia devs which tells users not to use their installer, but to use the distro installers instead. nobody cares i guess.
[17:41] <tseliot> bjsnider: that could still be overridden with an option in the installer, something like --override-distro-hooks
[17:41] <bjsnider> yes but regular users wouldn't know that without a lot of research
[17:42] <kklimonda> bjsnider: that's why I've suggested actually modifying the installer - it's been proven that users don't read and are generally bunch of.. -ECOCINCOMPATIBLE
[17:42] <kklimonda> tseliot: if people use such an argument we can just tell them to contact the person who told them to do that.
[17:43] <tseliot> kklimonda: the installer already supports that argument that I mentioned (even though maybe that's not the exact name). It's just a matter of making sure that the hook is there when Ubuntu is installed
[17:44] <kklimonda> tseliot: ah, I see - but only nvidia for now, right?
[17:45] <Sarvatt> what the heck, swapped out the HDD in my 8400M GS laptop and now the nvidia blob works on both linux and windows, I haven't been able to use the blob on that thing since karmic because it had nasty corruption and lockup problems and would blue screen on boot in windows. I thought the GPU was just screwed
[17:46] <tseliot> kklimonda: yes, only nvidia. fglrx (when it generates deb packages) uses more or less the same sources of the packages in Ubuntu (since I maintain both). The problem is when it acts like the Nvidia installer I guess (i.e. without generating packages)
[17:47] <tseliot> Sarvatt: err... maybe the blob was indeed screwed, physically speaking
[17:47] <Sarvatt> put the 200gb 7200RPM drive back in and did a fresh install, still can't use the blob
[17:47] <tseliot> oh
[17:47] <tseliot> maybe it's a controller thing?
[17:48] <Sarvatt> HDD pulling too much power and killing the GPU, thats a new one
[17:48] <tseliot> that would be weird
[17:48] <tseliot> I was thinking of some messed up BIOS
[17:49]  * tseliot likes blaming it on the BIOS
[17:49] <Sarvatt> me too, it almost always is anyway :)
[17:50] <tseliot> :)
[17:53] <Sarvatt> 200gb hitachi 7200rpm drive = cant use blob, 250gb WD 5400rpm drive = blob works fine. on more than one OS.. anyway the wife is happy she can play her minecraft again, nouveau 3D wasn't quite fast enough :)
[17:55] <bjsnider> does the smart data on the larger drive say it's screwed?
[17:59] <Sarvatt> dunno, can't check now. will check later though
[18:06]  * bryceh waves
[18:06] <Sarvatt> morning bryce
[18:45] <bjsnider> kklimonda, it ooks l ike the nvidia installer hook is a file -- /usr/lib/nvidia/pre-install. it is a one-line shell script. now, if it were moved from nvidia-common to jockey-common it would be more effective.
[18:52] <Sarvatt> dang, the JumpyCursorThreshold patch for synaptics is awesome now that I have a huge touchpad that constantly freaks out
[19:04] <Sarvatt> hmm actually, wonder if its even needed now with http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e
[19:22] <Sarvatt> ugh, touchpad acceleration is all kinds of screwed up in current synaptics still, JumpyCursorThreshold isn't needed though \o/
[19:29] <Sarvatt> guess I still need to revert http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=4e0e53fcba6fd99d458df1905d055d63360155c0 , it's unusably jumpy/slow. move the cursor in a straight line in a smooth motion and it accelerates/decelerates constantly
[19:32] <Sarvatt> maybe the gnome knobs mentioned in http://who-t.blogspot.com/2010/06/new-synaptics-acceleration-mechanism.html would help but the default is still crap here
[20:29]  * bryceh updates https://wiki.ubuntu.com/Wayland with more faqqage
[20:34] <bryceh> Sarvatt, I also added your bits to the X Update section at https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-23
[23:14] <bryceh> https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/346289/+activity
[23:14] <bryceh>  ^ this user is irritating me
[23:14] <bryceh>  I wrote up a lengthy explanation of the bug, and he keeps reverting the description
[23:14] <ubot4> Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New]
[23:17] <Sarvatt> yeesh
[23:18] <Sarvatt> he'll probably edit the duped bug if you make another one the master too
[23:18] <bryceh> Sarvatt, speaking of bug 346289, I'd appreciate if you took a quick look at my Discussion and Ideas sections there
[23:18] <ubot4> Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New] https://launchpad.net/bugs/346289
[23:19] <bryceh> see if I missed anything.
[23:19] <bryceh> I'm gathering there is nothing we can do, and the two ideas I've had seem a bit kludgy.  But I'd like to hear your take
[23:19] <bryceh> (and technically, no I don't think this is an X issue)
[23:20] <Sarvatt> bryceh: unredirect fullscreen windows option in compiz :)
[23:20]  * Sarvatt slaps natty for making all URL's open in firefox
[23:21] <RAOF> Unredirect fullscreen windows isn't going to make flash start GPUing, though.
[23:21] <bryceh> morning RAOF
[23:22] <RAOF> Morning bryceh :)
[23:22] <RAOF> Is mesa ready to review? :)
[23:22] <Sarvatt> what the heck!
[23:22] <Sarvatt> [    17.845] (II) VESA(0): Not using built-in mode "1856x1392" (no mode of this name)
[23:22] <Sarvatt> [    17.845] (II) VESA(0): Not using built-in mode "1792x1344" (no mode of this name)
[23:22] <bryceh> I'd like that chocolateboy to revert me one more time...
[23:23] <RAOF> Sarvatt: That's… interesting.  Is that a crazywierd VBIOS?
[23:25] <RAOF> It might be fun to apply that ‘where does this mode come from, anyway” patch and try  again :)
[23:25] <Sarvatt> yeah this is crazy, http://sarvatt.com/downloads/Xorg-maverick.txt
[23:25] <bryceh> RAOF, well I fixed the one mesa bug but found another...
[23:25] <RAOF> You're building from master, right?
[23:25] <bryceh> RAOF, I'd love it if you want to take a look at it now, I feel like it's 95% there
[23:26] <bryceh> yeah
[23:26] <bryceh> well specifically I'm deriving from one of Sarvatt's xorg-edgers builds
[23:26] <bryceh> maybe in reviewing it you'll spot whatever I did wrong
[23:26] <bryceh> RAOF, https://launchpad.net/~xorg-edgers/+archive/wayland/
[23:26] <RAOF> I'm merging 7.9+repack-1 from debian, and doing the gallium/classic selection stuff now, so more mesa is in my headspace :)
[23:27] <Sarvatt> RAOF: probably need to merge ubuntu-maverick into ubuntu before merging 7.9+repack-1
[23:27] <RAOF> Sarvatt: Yup.  I noticed that.  Fortunately, merges are commutative :)
[23:28] <Sarvatt> 5a3ac74 needs to be reverted for mesa 7.10 to compile too in case ya hadn't seen
[23:29] <Sarvatt> tormod brought it up on mesa-dev but no one responded
[23:36] <RAOF> There's got to be a better way of doing patches than quilt.
[23:42] <bryceh> bzr?  ;-)
[23:43] <RAOF> Quite possibly.
[23:43] <RAOF> bzr looms would work.
[23:43] <RAOF> Man.  That patch compiles first time!
[23:43] <RAOF> I'm on fire!
[23:45] <RAOF> Hm.  The option should probably be documented, though.
[23:46] <bjsnider> what's wrong with quilt?
[23:48] <RAOF> I always forget to “quilt add” a file before editing it.
[23:50] <ilmari> hm, no xorg-edgers/drivers-only ppa for maverick?
[23:57] <Sarvatt> drivers-only doesn't really work these days in the world where every new driver release needs a new libdrm, etc :)
[23:58] <Sarvatt> tormod updated that and haven't seen him around lately