bryceh | wazzah, bugbot lives: https://launchpad.net/~bugbot | 01:06 |
---|---|---|
bryceh | heya nigelb | 01:06 |
bryceh | lessee | 01:06 |
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:08 |
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:09 |
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:10 |
bryceh | nigelb, or alternatively forward the patch upstream to bugs.freedesktop.org for review | 01:12 |
nigelb | bryceh: I'll forwards \o/ | 01:18 |
nigelb | Thank you for looking :) | 01:18 |
bryceh | no prob | 01:19 |
* nigelb hugs bryceh :) | 01:19 | |
* 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:20 |
nigelb | haha | 01:21 |
bryceh | upstream knows the right way to do things | 01:21 |
bryceh | Sarvatt, RAOF, prepare for an onslaught of bugbot spam :-) | 01:22 |
bryceh | Sarvatt, RAOF, at least now it's more easily procmailable | 01:22 |
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:23 |
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:24 |
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:25 |
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:27 | |
nigelb | haha | 01:28 |
=== Amaranth_ is now known as Amaranth | ||
Sarvatt | bugbot has only gotten 2 mails through to my inbox so far :) | 02:02 |
=== virtuald is now known as leagris | ||
=== leagris is now known as virtuald | ||
RAOF | Why did I put maverick's mesa on the ubuntu-maverick branch?? | 04:48 |
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:30 |
RAOF | It was intel, amd, nvidia, via, right? | 10:31 |
apw | RAOF, hrm i don't think we really talkaed about it, i am happy with those four though | 10:35 |
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:36 |
tseliot | RAOF: built-in? I guess this won't cause issues with proprietary drivers since we blacklist those drivers in the initramfs, right? | 10:40 |
RAOF | That's a good question; the binary drivers have their own agp drivers, don't they? | 10:41 |
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:42 |
* apw warns you that the next upload of the kernel will carry the switch from =m to =y for these AGP drivers | 10:45 | |
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:50 |
tseliot | apw: if we cannot blacklist them, then it's not fine | 10:51 |
apw | how does fedora handle this i wonder | 10:51 |
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:52 |
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:53 |
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:54 |
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:55 |
apw | ok ... done ... thansk | 10:56 |
RAOF | apw: thanks. | 10:58 |
=== BlackZ_ is now known as BlackZ | ||
=== yofel_ is now known as yofel | ||
Sarvatt | intel_agp.sucks=1 passed to grub, blacklisted :) | 13:47 |
jcristau | way to prevent stuff from working :) | 13:48 |
Sarvatt | ah hah | 13:49 |
Sarvatt | agp=off | 13:49 |
Sarvatt | then nvagp loads | 13:50 |
Sarvatt | with agp :) | 13:50 |
kklimonda | hey | 17:27 |
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:29 |
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:30 |
tseliot | this applies only to nvidia | 17:31 |
kklimonda | tseliot: apparently, that's not enough :/ | 17:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
bjsnider | that way the user would have to seriously bork their system to even try the nvidia-installer | 17:39 |
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:41 |
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:42 |
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:43 |
kklimonda | tseliot: ah, I see - but only nvidia for now, right? | 17:44 |
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:45 |
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:46 |
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:47 |
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:48 |
* tseliot likes blaming it on the BIOS | 17:49 | |
Sarvatt | me too, it almost always is anyway :) | 17:49 |
tseliot | :) | 17:50 |
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:53 |
bjsnider | does the smart data on the larger drive say it's screwed? | 17:55 |
Sarvatt | dunno, can't check now. will check later though | 17:59 |
* bryceh waves | 18:06 | |
Sarvatt | morning bryce | 18:06 |
=== maxb_ is now known as maxb | ||
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:45 |
Sarvatt | dang, the JumpyCursorThreshold patch for synaptics is awesome now that I have a huge touchpad that constantly freaks out | 18:52 |
Sarvatt | hmm actually, wonder if its even needed now with http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e | 19:04 |
Sarvatt | ugh, touchpad acceleration is all kinds of screwed up in current synaptics still, JumpyCursorThreshold isn't needed though \o/ | 19:22 |
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:29 |
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 | 19:32 |
* bryceh updates https://wiki.ubuntu.com/Wayland with more faqqage | 20:29 | |
bryceh | Sarvatt, I also added your bits to the X Update section at https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-23 | 20:34 |
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:14 |
Sarvatt | yeesh | 23:17 |
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:18 |
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:19 |
Sarvatt | bryceh: unredirect fullscreen windows option in compiz :) | 23:20 |
* Sarvatt slaps natty for making all URL's open in firefox | 23:20 | |
RAOF | Unredirect fullscreen windows isn't going to make flash start GPUing, though. | 23:21 |
bryceh | morning RAOF | 23:21 |
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:22 |
RAOF | Sarvatt: That's… interesting. Is that a crazywierd VBIOS? | 23:23 |
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:25 |
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:26 |
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:27 |
Sarvatt | 5a3ac74 needs to be reverted for mesa 7.10 to compile too in case ya hadn't seen | 23:28 |
Sarvatt | tormod brought it up on mesa-dev but no one responded | 23:29 |
RAOF | There's got to be a better way of doing patches than quilt. | 23:36 |
bryceh | bzr? ;-) | 23:42 |
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:43 |
RAOF | Hm. The option should probably be documented, though. | 23:45 |
bjsnider | what's wrong with quilt? | 23:46 |
RAOF | I always forget to “quilt add” a file before editing it. | 23:48 |
ilmari | hm, no xorg-edgers/drivers-only ppa for maverick? | 23:50 |
Sarvatt | drivers-only doesn't really work these days in the world where every new driver release needs a new libdrm, etc :) | 23:57 |
Sarvatt | tormod updated that and haven't seen him around lately | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!