[01:06] wazzah, bugbot lives: https://launchpad.net/~bugbot [01:06] heya nigelb [01:06] lessee [01:08] nigelb, neither; looks like the patch is against xserver-xorg-input-evdev [01:08] nigelb, however be careful; I think some input devices prefer the axes oriented the way they are [01:09] it may be that a more sophisticated patch is needed to cover this corner case without breaking the general case [01:09] but I haven't looked at it too deeply [01:10] 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] nigelb, or alternatively forward the patch upstream to bugs.freedesktop.org for review [01:18] bryceh: I'll forwards \o/ [01:18] Thank you for looking :) [01:19] no prob [01:19] * nigelb hugs bryceh :) [01:20] * bryceh hugs nigelb [01:20] :) [01:20] 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] haha [01:21] upstream knows the right way to do things [01:22] Sarvatt, RAOF, prepare for an onslaught of bugbot spam :-) [01:22] Sarvatt, RAOF, at least now it's more easily procmailable [01:23] bugbot? email bugs? [01:23] bryceh: whats bugbot? I've already got 23k unread in my ubuntu-x-swat folder :D [01:23] Sarvatt, prepare for 23k more [01:24] bugbot is basically a new launchpad user account I'm going to use for running my arsenal scripts [01:24] so all the arsenal spam will be nicely disassociated from me now [01:24] my karma shall suffer greatly. ;-) [01:25] lol [01:25] bryceh: you worked on lp team for a cycle, shoulda put in a hack to increase your karma :p [01:27] 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] haha === Amaranth_ is now known as Amaranth [02:02] bugbot has only gotten 2 mails through to my inbox so far :) === virtuald is now known as leagris === leagris is now known as virtuald [04:48] Why did I put maverick's mesa on the ubuntu-maverick branch?? [10:30] 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] It was intel, amd, nvidia, via, right? [10:35] RAOF, hrm i don't think we really talkaed about it, i am happy with those four though [10:36] I only recall saying that we needde them built in, honestly, but I think those are the ones we need. [10:36] RAOF, thats good enough for me :) [10:36] i will start with those and you can tell us if thats not suffiicient :) [10:40] RAOF: built-in? I guess this won't cause issues with proprietary drivers since we blacklist those drivers in the initramfs, right? [10:41] That's a good question; the binary drivers have their own agp drivers, don't they? [10:42] probably a non-issue, since airlied thought about making them mandatory anyway [10:42] some time ago [10:42] I understand that fedora builds in the agp drivers, so yeah. [10:42] right [10:42] well if they are builtin that won't let you blacklist them anymore [10:42] 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] 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] RAOF: yes, they are [10:51] apw: if we cannot blacklist them, then it's not fine [10:51] how does fedora handle this i wonder [10:52] why would you blacklist an agp driver? [10:52] 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] tseliot, do you have an example of what we blacklist when we enable prop drivers ? [10:53] 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] yeah not proposing anything that high in the stack gets built-in [10:54] apw: we simply blacklist nouveau and the other proprietary nvidia flavours when enabling nvidia. [10:54] so i think we are probabally ok then [10:54] but we do need to watch out when the next kernel goes in to be 100% sure [10:55] RAOF, apw: ah, sorry, I misread what you wrote. I missed the "agp" part [10:55] i certainly haven't heard of any issues since we started having the agp drivers builtin [10:55] that's ok [10:55] (we = Debian) [10:55] tseliot, i assume you have some h/w you could test on, if I made up some test kernels [10:55] jcristau, thats a good information point [10:55] (thanks) [10:55] apw: sure, I can test things here but, as I said, it should be ok to build in agp drivers [10:56] ok ... done ... thansk [10:58] apw: thanks. === BlackZ_ is now known as BlackZ === yofel_ is now known as yofel [13:47] intel_agp.sucks=1 passed to grub, blacklisted :) [13:48] way to prevent stuff from working :) [13:49] ah hah [13:49] agp=off [13:50] then nvagp loads [13:50] with agp :) [17:27] hey [17:29] 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] no single week passes without me helping some poor soul fix their system after installing those drivers.. [17:30] 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] this applies only to nvidia [17:32] tseliot: apparently, that's not enough :/ [17:33] 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] it's still on my todo list though [17:34] tseliot: can't you just ask? their current installers pro-actively break systems ;) [17:34] and for some reason people blame us :/ [17:35] kklimonda: I already did. Which is why I said that I "can't" do that [17:35] tseliot, it only works if the nvidia-common package is installed. i think it should be put into jockey.common [17:36] bjsnider: see, I don't even remember how I implemented the whole thing... [17:36] hahaha [17:36] i didn't expect that response [17:36] i think the flaw was putting the hook into a package that is not automatically on everyone's system (nvidia-common) [17:37] but it was a good idea [17:37] bjsnider: maybe, as you said, jockey is a better place for that [17:37] i think it should be in a package that is part of ubuntu-desktop or the like [17:39] that way the user would have to seriously bork their system to even try the nvidia-installer [17:41] 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] bjsnider: that could still be overridden with an option in the installer, something like --override-distro-hooks [17:41] yes but regular users wouldn't know that without a lot of research [17:42] 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] tseliot: if people use such an argument we can just tell them to contact the person who told them to do that. [17:43] 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] tseliot: ah, I see - but only nvidia for now, right? [17:45] 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] 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] Sarvatt: err... maybe the blob was indeed screwed, physically speaking [17:47] put the 200gb 7200RPM drive back in and did a fresh install, still can't use the blob [17:47] oh [17:47] maybe it's a controller thing? [17:48] HDD pulling too much power and killing the GPU, thats a new one [17:48] that would be weird [17:48] I was thinking of some messed up BIOS [17:49] * tseliot likes blaming it on the BIOS [17:49] me too, it almost always is anyway :) [17:50] :) [17:53] 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] does the smart data on the larger drive say it's screwed? [17:59] dunno, can't check now. will check later though [18:06] * bryceh waves [18:06] morning bryce === maxb_ is now known as maxb [18:45] 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] dang, the JumpyCursorThreshold patch for synaptics is awesome now that I have a huge touchpad that constantly freaks out [19:04] hmm actually, wonder if its even needed now with http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e [19:22] ugh, touchpad acceleration is all kinds of screwed up in current synaptics still, JumpyCursorThreshold isn't needed though \o/ [19:29] 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] 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] Sarvatt, I also added your bits to the X Update section at https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-23 [23:14] https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/346289/+activity [23:14] ^ this user is irritating me [23:14] I wrote up a lengthy explanation of the bug, and he keeps reverting the description [23:14] Launchpad bug 346289 in flashplugin-nonfree (Ubuntu) "MASTER: Choppy Flash playback in full screen (affects: 26) (dups: 3) (heat: 200)" [Undecided,New] [23:17] yeesh [23:18] he'll probably edit the duped bug if you make another one the master too [23:18] Sarvatt, speaking of bug 346289, I'd appreciate if you took a quick look at my Discussion and Ideas sections there [23:18] 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] see if I missed anything. [23:19] 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] (and technically, no I don't think this is an X issue) [23:20] bryceh: unredirect fullscreen windows option in compiz :) [23:20] * Sarvatt slaps natty for making all URL's open in firefox [23:21] Unredirect fullscreen windows isn't going to make flash start GPUing, though. [23:21] morning RAOF [23:22] Morning bryceh :) [23:22] Is mesa ready to review? :) [23:22] what the heck! [23:22] [ 17.845] (II) VESA(0): Not using built-in mode "1856x1392" (no mode of this name) [23:22] [ 17.845] (II) VESA(0): Not using built-in mode "1792x1344" (no mode of this name) [23:22] I'd like that chocolateboy to revert me one more time... [23:23] Sarvatt: That's… interesting. Is that a crazywierd VBIOS? [23:25] It might be fun to apply that ‘where does this mode come from, anyway” patch and try again :) [23:25] yeah this is crazy, http://sarvatt.com/downloads/Xorg-maverick.txt [23:25] RAOF, well I fixed the one mesa bug but found another... [23:25] You're building from master, right? [23:25] RAOF, I'd love it if you want to take a look at it now, I feel like it's 95% there [23:26] yeah [23:26] well specifically I'm deriving from one of Sarvatt's xorg-edgers builds [23:26] maybe in reviewing it you'll spot whatever I did wrong [23:26] RAOF, https://launchpad.net/~xorg-edgers/+archive/wayland/ [23:26] 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] RAOF: probably need to merge ubuntu-maverick into ubuntu before merging 7.9+repack-1 [23:27] Sarvatt: Yup. I noticed that. Fortunately, merges are commutative :) [23:28] 5a3ac74 needs to be reverted for mesa 7.10 to compile too in case ya hadn't seen [23:29] tormod brought it up on mesa-dev but no one responded [23:36] There's got to be a better way of doing patches than quilt. [23:42] bzr? ;-) [23:43] Quite possibly. [23:43] bzr looms would work. [23:43] Man. That patch compiles first time! [23:43] I'm on fire! [23:45] Hm. The option should probably be documented, though. [23:46] what's wrong with quilt? [23:48] I always forget to “quilt add” a file before editing it. [23:50] hm, no xorg-edgers/drivers-only ppa for maverick? [23:57] drivers-only doesn't really work these days in the world where every new driver release needs a new libdrm, etc :) [23:58] tormod updated that and haven't seen him around lately