| Sarvatt | guess I had a saved session or something -- Window manager warning: Failed to read saved session file /var/lib/gdm/.config/metacity/sessions/108b2bba67abe815cb1259blahblah | 00:00 |
|---|---|---|
| === dyek_ is now known as dyek | ||
| Sarvatt | tjaalton: progs/objviewer is now huge -- yeah we're deleting everything in there in edgers, huge chunk of stuff thats not even shipped | 00:06 |
| Sarvatt | looks like just adding the inputclass stuff bumps the abi, and it was already bumped to 8 earlier just before 1.7.99.2. probably would be easier to just go with xserver 1.8 than try to backport all those patches, that seems a bit tricky? | 00:58 |
| === Amaranth__ is now known as Amaranth | ||
| ara | tseliot, feliz año! | 08:05 |
| tseliot | ¡Gracias ara! ¡Feliz año nuevo! | 08:07 |
| tseliot | ara: no se si te has enterado de que hay drivers Nvidia en mi PPA | 08:08 |
| ara | tseliot, I saw something, how do I install them? | 08:09 |
| tseliot | ara: you'll have to install/update all of the packages in my PPA | 08:11 |
| ara | tseliot, OK, I will do. How do you want me to report back to you? trough the ubuntu-x mailing list? | 08:12 |
| tseliot | ara: and edit your xorg.conf (I haven't uploaded the new jockey yet) | 08:12 |
| tseliot | ara: sure, that would be fine | 08:13 |
| tjaalton | tseliot: you should mention the ppa on the bug too :) | 08:13 |
| tseliot | tjaalton: right | 08:18 |
| mvo | what bugnumber is that? | 08:18 |
| tjaalton | bug 494166 | 08:19 |
| ubottu | Launchpad bug 494166 in nvidia-graphics-drivers-96 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166 | 08:19 |
| mvo | thanks | 08:19 |
| === ripps|sleep is now known as ripps | ||
| === seb128__ is now known as seb128 | ||
| === seb128_ is now known as seb128 | ||
| ripps | ati kms video playback isn't as good as it used to be. Must be because of the lack of overlay video now. Actually, I find that using gl:yuv=4 is faster and causes less tearing than xv does now. | 11:13 |
| ripps | in mplayer, that is. | 11:14 |
| tseliot | is that with compiz enabled? | 11:16 |
| ara | tseliot, I cannot see lucid packages in your ppa | 11:28 |
| tseliot | ara: in this PPA? https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements | 11:32 |
| ara | tseliot, cool, I was looking at your general ppa | 11:32 |
| ara | tseliot, grazie | 11:32 |
| tseliot | ara: yes, that's what I figured ;) | 11:33 |
| tseliot | de nada | 11:33 |
| mvo | is anyone working on bug #494627 ? I got a local build of the nv package now because I was bitten by this error (minus two patches I had to disable) | 12:21 |
| ubottu | Launchpad bug 494627 in xserver-xorg-video-nv "nv driver crashing with segmentation fault in libpthread.so.0" [High,In progress] https://launchpad.net/bugs/494627 | 12:21 |
| tjaalton | mvo: it works now? what did you do? | 12:33 |
| mvo | tjaalton: I meged the git fix and that seems to do the trick, if you don't mind I will upload and you can merge it into git | 12:35 |
| mvo | tjaalton: or I send you the debdiff, whatever you want | 12:35 |
| tjaalton | mvo: either is fine | 12:36 |
| mvo | tjaalton: thanks, I will upload then, let me just tidy up my changelog :) | 12:36 |
| tjaalton | I suspect it was the "g80: Add a no-op gamma hook so we don't crash on 1.7 servers" commit? | 12:36 |
| mvo | yes | 12:37 |
| tjaalton | cool, included in .16 | 12:37 |
| mvo | yeah, .16 is a bit tricky, needs some tweaking to the quilt patches | 12:37 |
| mvo | and I was too lazy^Wbusy for that ;) | 12:38 |
| tjaalton | heh, ok | 12:38 |
| mvo | but it works too (once the patches are commented out) | 12:38 |
| ara | tseliot, successfully running nvidia drivers from your PPA, ta! | 14:49 |
| ara | tseliot, I will report any issues I may find | 14:49 |
| tseliot | ara: I'm glad to read that they work for you. Thanks for testing | 14:50 |
| bjsnider | tseliot, i wanted to mention the control file description should say that vdpau is supported on geforce 8 or newer, not 7, and the driver itself works on geforce 6 or newer, not 7 | 14:52 |
| tseliot | bjsnider: let me check what I wrote in the control file | 14:53 |
| tseliot | bjsnider: good point. Thanks for reporting, I'll correct it. | 14:55 |
| bjsnider | cool | 14:56 |
| superm1 | tseliot, are those transitional packages actually needed? | 15:04 |
| tseliot | superm1: we have the chance to make things work even for upgrades from the command line, so why not? | 15:05 |
| superm1 | tseliot, right | 15:05 |
| superm1 | tseliot, well let me put it this way, are that many of them needed? | 15:06 |
| tseliot | superm1: what would you like to remove? | 15:07 |
| superm1 | the 185-modaliases and the 185-kernel-source seem superfluous if the nvidia-185-glx already depends on nvidia-current | 15:07 |
| superm1 | if someone has the glx package installed it will pull them up to nvidia-current | 15:07 |
| tseliot | superm1: but if you remove/update nvidia-glx-185, its kernel-source package won't be removed | 15:08 |
| tseliot | and this can cause problems | 15:08 |
| tseliot | because the module in that package is named nvidia.ko | 15:09 |
| tseliot | and we're now using nvidia-$FLAVOUR with aliases to load the right module | 15:09 |
| superm1 | Ah right | 15:09 |
| superm1 | and we dont want to be in conflicts/replaces hell with a list of every variant that's been done as c/r | 15:10 |
| superm1 | sounds sensible then | 15:10 |
| tseliot | right | 15:10 |
| superm1 | lets see what else do i see, --- nvidia-graphics-drivers-190.53.orig/debian/nvidia-current.postrm.in, it's just a skeleton, is that intended so it's easy to add something to later? | 15:13 |
| tseliot | superm1: yes and it allows me to share most of the code between the different flavours | 15:13 |
| superm1 | cool, sounds good | 15:13 |
| tseliot | as it's (mostly) a matter of renaming the same file as nvidia-$FLAVOUR.postrm.in | 15:14 |
| tseliot | etc. | 15:14 |
| tseliot | the new packaging scripts are thought to make my life (and the life of the ones who will deal with nvidia) a little easier :-) | 15:15 |
| tseliot | I'm still simplifying the debian/rules and other files | 15:15 |
| bjsnider | tseliot, i was studying the code and am i right in assuming that the only thing i need to change from one minor release to another is the changelog? | 15:16 |
| tseliot | superm1: BTW execstack seems to work well when called from the command line but fails with signal 8 (at times) if called from the makefile. Any ideas? | 15:16 |
| tseliot | bjsnider: yes, this is correct | 15:16 |
| superm1 | that's awesome! :) | 15:17 |
| tseliot | :-) | 15:17 |
| bjsnider | wow, that's going to make my life a whole lot easier | 15:17 |
| superm1 | tseliot, you'll want to go and swing a bat at kees a little bit about that execstack stuff | 15:17 |
| bjsnider | i can't screw things up anymore | 15:17 |
| superm1 | tseliot, i'm not too sure on it | 15:17 |
| tseliot | superm1: sure, I'll talk to him again. Some time ago he mentioned some weird behaviour in execstack... | 15:18 |
| superm1 | tseliot, do you have a particular example that consistently fails? | 15:18 |
| tseliot | bjsnider: yes, things should be much easier to change and maintain | 15:18 |
| bjsnider | i already added some .in files and an extra variable to reduce the possible screwups in the old version | 15:19 |
| kees | superm1, tseliot: I'd noticed the SIGFPE stuff before when I called it on multiple files at once, so I reworked all my earlier packaging examples to call execstack on one file at a time. | 15:19 |
| kees | superm1, tseliot: which build is exploding? | 15:19 |
| tseliot | superm1: if I extract an nvidia installer and do this manually it works: find . *.so* | xargs execstack -q | 15:19 |
| tseliot | kees: it's the new nvidia and here's what fails if done from the makefile ^^ | 15:20 |
| kees | tseliot: do xargs -n1 and I bet it'll work. | 15:20 |
| tseliot | kees: ok, let me try | 15:20 |
| kees | tseliot: I only did the -q calls so I could try to figure out which file was blowing it up originally, but the very act of doing one at a time seemed to solve it. | 15:22 |
| tseliot | kees: you already mentioned this to me before, therefore I used a for loop so as to call execstack for each file | 15:23 |
| tseliot | I'm rebuilding the packages with n1 as we speak | 15:24 |
| tseliot | and it didn't fail. Let's see if the markings were disabled | 15:24 |
| tseliot | kees: yes, it looks like that did it | 15:25 |
| tseliot | thanks a lot :-) | 15:25 |
| superm1 | tseliot, have you put any thought into how to make beta drivers available to users with this type of packaging? | 15:26 |
| tseliot | kees: it's a bit weird that something like this fails though: http://pastebin.ubuntu.com/351824/ | 15:27 |
| tseliot | superm1: they would replace -current, I guess | 15:27 |
| superm1 | it looks like it would probably be a s/nvidia-current/nvidia-195/ in debian/rules or similar and rename the tarball appropriately | 15:27 |
| superm1 | it would probably be good to mention that in your README.Debian.in | 15:28 |
| superm1 | just so people know how to do that in the future | 15:28 |
| tseliot | superm1: aah, you mean how to create a new flavour | 15:28 |
| superm1 | tseliot, yeah | 15:28 |
| kees | tseliot: yeah, it's really odd. I was never able to track it down. :( | 15:28 |
| tseliot | sure, I can and will document it | 15:28 |
| superm1 | i figure you'll probably want flavours in both directions (old and beta) | 15:29 |
| tseliot | kees: well, in that specific case it's just two files and I really don't need the loop ;) | 15:29 |
| superm1 | especially for PPA's like bjsnider's, so a consistent way of doing them will be good | 15:29 |
| tseliot | kees: the xargs -n1 is a real life saver though | 15:30 |
| tseliot | superm1: creating a new flavour with digits (e.g. -195) would be ok while using letters would break nvidia-common | 15:31 |
| tseliot | I can document this as well | 15:31 |
| superm1 | Yeah that's good to mention | 15:31 |
| tseliot | superm1: also if nvidia-common had to deal with -current vs -195 to recommend a driver for jockey, the former would always win | 15:32 |
| superm1 | yeah that would be the expected behavior | 15:33 |
| bjsnider | what about nvidia-beta, and nvidia-old? | 15:33 |
| bjsnider | would that break nvidia-common? | 15:33 |
| superm1 | bjsnider, the problem with using words like that is what happens when you have multiple old's | 15:33 |
| superm1 | or multiple betas in different series' at the same time | 15:33 |
| bjsnider | no, i wouldn't allow multiple betas | 15:34 |
| bjsnider | nvidia doesn't release multiple betas at the same time | 15:34 |
| tseliot | bjsnider: yep, that would break it | 15:35 |
| tseliot | nvidia-195 or -200 or whatever would be fine though | 15:35 |
| bjsnider | tseliot, so if i've got nvidia-200 and nvidia-current, will jockey recommend nvidia-current? | 15:36 |
| tseliot | there's really no way (apart from ascii string comparison) to tell which driver is newer/better than the other (when using strings) | 15:37 |
| tseliot | bjsnider: yes, that's correct | 15:37 |
| tseliot | because nvidia-current = nvidia-1000 and 1000 will always win against versions < 1000 | 15:39 |
| bjsnider | but would the average user not want to pick nvidia-200 if he sees it there, even with the current one being recommended? | 15:40 |
| bjsnider | in other words, it might be good to be able to call it "beta" instead of a number | 15:41 |
| bjsnider | or even "nvidia-unstable" | 15:41 |
| tseliot | we wouldn't support the beta driver but if you really want to call it beta etc. you can modify nvidia-common and put it in your PPA | 15:41 |
| tseliot | just replace self.__driver_aliases = {'current': 1000} with self.__driver_aliases = {'current': 1000, 'beta': 2000} | 15:42 |
| tseliot | and so on | 15:42 |
| tseliot | this is in nvidiadetector.py | 15:42 |
| bjsnider | i'll jot that down | 15:42 |
| tseliot | a one line patch would do it | 15:42 |
| bjsnider | but i don't see why there should only be one nvidia blob in there for each series of cards | 15:42 |
| tseliot | or, even better I could make it possible to put the additional driver in a text file | 15:43 |
| tseliot | e.g. beta 2000 | 15:43 |
| tseliot | current 1000 | 15:43 |
| tseliot | bjsnider: what do you mean? | 15:44 |
| tseliot | if your card is compatible with the driver you can install any of them | 15:44 |
| bjsnider | right now the current stable release by nvidia is the 190.53 | 15:44 |
| tseliot | right | 15:45 |
| bjsnider | it breaks sound over hdmi, which worked int he 185. so some people need the 185 | 15:45 |
| bjsnider | kde people should unquestionably be using the beta 195 driver, which has huge xrender improvements | 15:45 |
| bjsnider | and really, ubuntu isn't supporting this driver, nvidia is. you're supporting the packaging scripts, but the driver is pre-built | 15:46 |
| bjsnider | if the packaging scripts are bullet-proof, then you just say "go tak to nvidia about this" if someone complains | 15:46 |
| tseliot | it should be ok to keep additional drivers in a PPA. The fact that I have the time to work on this depends only on the fact that I'm on team swap which means that I can spend most of my time working for the desktop team (as usually I do OEM stuff) | 15:47 |
| tseliot | or, in other words, we lack manpower | 15:47 |
| bjsnider | oh, i will keep them in the ppa | 15:48 |
| bjsnider | manpower is the only problem? | 15:48 |
| superm1 | bjsnider, so if the modaliases for any of the beta drivers aren't installed they wont be offered in the first place | 15:50 |
| superm1 | and since i expect beta drivers will live exclusively in a PPA, none of those modaliases would be installed unless intentionally done by a user | 15:51 |
| tseliot | superm1: good point | 15:51 |
| tseliot | bjsnider: yes, manpower has been the main problem so far | 15:51 |
| bjsnider | as far as packaging multiple drivers is concerned? | 15:52 |
| tseliot | yep and for bug triaging too | 15:52 |
| superm1 | just so long as it's possible to produce beta drivers and have experienced users be able to install (albeit if they need to use command line or synaptic that's fine) i'm happy | 15:52 |
| tseliot | superm1: there's still the problem of setting alternatives with a command | 15:53 |
| superm1 | tseliot, well wouldn't they just be treated as a new flavour though that gets registered in the alternatives system (assuming the same packaging base is used)? | 15:53 |
| tseliot | superm1: yes but users would still have to set the alternative that they want to use (as we use Manual mode for alternatives) | 15:54 |
| superm1 | tseliot, oh in this line of thinking, normally is jockey the one setting that alternative that they want to use? | 15:55 |
| tseliot | the alternative would be "installed" but not "set" (as the current one) | 15:55 |
| tseliot | superm1: yep | 15:55 |
| superm1 | tseliot, ah well as long as it's documented somewhere i think that's fine | 15:55 |
| tseliot | superm1: and it switches back to the alternative for open drivers when a driver is uninstalled/deactivated | 15:55 |
| tseliot | sure | 15:56 |
| bjsnider | how do they set it as the current one? | 15:56 |
| tseliot | hmm... maybe I should make it switch to the open drivers alternative only if the driver that we're disabling is the one in use | 15:57 |
| tseliot | bjsnider: update-alternatives --set gl_conf path_to_the_driver | 15:58 |
| tseliot | example: update-alternatives --set gl_conf /usr/lib/standard-x11/ld.so.conf | 15:58 |
| tseliot | for open drivers | 15:58 |
| tseliot | or | 15:58 |
| tseliot | for nvidia-current | 15:58 |
| tseliot | update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf and so on | 15:58 |
| tseliot | (with sudo) | 15:58 |
| bjsnider | yeah but that's in the packaging scripts right? | 16:00 |
| tseliot | ? | 16:00 |
| tseliot | the debian/rules contains 3 lines (I'm not sure about the readme) which explain what to do to set the alternative | 16:01 |
| bjsnider | in other words, users don't have to do this every time they update a driver, it's done for them | 16:01 |
| tseliot | of course not. Once you set the alternative to a certain driver in remains such (unless you uninstall that driver) | 16:02 |
| tseliot | updates won't alter that | 16:02 |
| tseliot | to be honest, I fixed this today ;) | 16:05 |
| bjsnider | but if i want to go from the 190 to the 195, say i'm using kde for instance, i would have to use jockey or run the update-alternative commands manually, correct? | 16:09 |
| tseliot | yep | 16:09 |
| bjsnider | ok. i have to know this when people start sending me emails complaining about it | 16:09 |
| tseliot | jockey will work only if after the modaliases are installed | 16:09 |
| bjsnider | well, yes i know that much | 16:10 |
| bjsnider | but that's a change from the old system | 16:10 |
| tseliot | right | 16:10 |
| bjsnider | the diversions were done by the packaging scripts and what jockey did was properly mark the xorg.conf file | 16:10 |
| tseliot | yep | 16:11 |
| bjsnider | so i suppose this is philosophical. you want more people using jockey to handle driver installs | 16:11 |
| Sarvatt | [drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged :( | 16:13 |
| tseliot | bjsnider: true | 16:14 |
| tseliot | ouch | 16:15 |
| bjsnider | what would theoretically happen if someone were to have the nvidia-current package installed, and then nvidia releases a new driver update, and this person goes to the nvidia site, grabs the nvidia installer and uses it to update the driver? | 16:15 |
| tseliot | bjsnider: the nvidia installer will stop | 16:17 |
| tseliot | thanks to some hooks that I put in nvidia-common | 16:18 |
| tseliot | but I haven't tested yet | 16:18 |
| bjsnider | haha, really? that's awesome | 16:18 |
| bjsnider | i love that | 16:18 |
| tseliot | :-) | 16:18 |
| bjsnider | it stops even if they run it with sudo | 16:19 |
| tseliot | yep | 16:19 |
| bjsnider | is there a message that says "you really don't want to be doing this" or something? | 16:19 |
| tseliot | the nvidia installer has supported distro hooks for a while (I requested this feature) | 16:19 |
| tseliot | it simply says that the installation failed because of the distro hook | 16:20 |
| tseliot | but it's still possible to override the hooks | 16:20 |
| tseliot | as the install | 16:20 |
| bjsnider | well, the average user wouldn't know that | 16:20 |
| tseliot | as the installer has an option for that | 16:20 |
| tseliot | right | 16:20 |
| bjsnider | and if hte hooks are overridden i suppose he would bork his system | 16:21 |
| tseliot | yes, but there's nothing we can do about it | 16:22 |
| tseliot | and it's ok, as long as users understand that we don't support such altered systems | 16:22 |
| bjsnider | one other thing, about nvidia-settings. what's the deal on the elevated-permissions patch? | 16:23 |
| tseliot | we use policykit to save settings in xorg.conf | 16:23 |
| tseliot | so that you don't have to run nvidia-settings with sudo | 16:23 |
| tseliot | (as you're not supposed to do so) | 16:24 |
| bjsnider | right but is there a patch? the bug report just kind of died at some point | 16:24 |
| superm1 | with the xorg.conf.d stuff that's gonna land, we might need to change what's being written to as well | 16:24 |
| tseliot | bjsnider: in the package in my PPA | 16:24 |
| tseliot | it requires screen-resolution-extra | 16:25 |
| tseliot | (from my PPA) | 16:25 |
| bjsnider | xorg.conf.d? | 16:26 |
| tseliot | superm1: yes, we might end up either patching nvidia-settings and nvidia-xconfig or, even better, talk to Nvidia about it. The latter is what I plan on doing first | 16:26 |
| superm1 | tseliot, the sooner the better with how long the delay is until stuff is in stable drivers | 16:27 |
| tseliot | superm1: I'll do it soon | 16:27 |
| tjaalton | nvidia-settings is open source | 16:28 |
| tjaalton | so it can be patched | 16:28 |
| tjaalton | but.. is there any need? | 16:28 |
| tjaalton | local changes should still live in xorg.conf | 16:29 |
| tjaalton | admins can use xorg.conf.d, but I don't think tools should | 16:29 |
| tseliot | tjaalton: the problem is that nvidia-settings writes input settings in xorg.conf too | 16:30 |
| tseliot | thus overriding what's in xorg.conf.d | 16:30 |
| tseliot | e.g. touchpad quirks, etc. | 16:30 |
| tjaalton | ok | 16:31 |
| tjaalton | yeah it should only touch the device section | 16:31 |
| * tseliot -> desktop meeting | 16:31 | |
| tjaalton | and maybe screen etc for multihead | 16:31 |
| tjaalton | superm1: does fglrx in lucid work with server 1.7? | 16:32 |
| === \vish is now known as mac_v | ||
| === mac_v is now known as \vish | ||
| hggdh_ | can someone please have a look at bug 503041, and suggest a possible package? | 16:47 |
| ubottu | Launchpad bug 503041 in ubuntu "Mouse lags while copying highlighted text." [Medium,Confirmed] https://launchpad.net/bugs/503041 | 16:47 |
| superm1 | tjaalton, not sure, i've not tested it. | 16:48 |
| superm1 | i've just been maintaining packaging blow ups that are happening with new versions of the driver | 16:49 |
| \vish | FWIW , that ^bug is also present in Lucid... I dont see lags that the user mentions but the mouse pointer does jump .. if you are moving the pointer during copy... oddest user scenario though ;) | 16:49 |
| tjaalton | superm1: ok | 16:52 |
| tjaalton | hggdh_: can't reproduce it on either | 16:52 |
| hggdh_ | tjaalton: neither can I, but at least three others (\vish included) can. I am tending to x-x-input*, but I am really not sure | 16:55 |
| \vish | tjaalton: it happens only while moving the pointer and doing a keyboard copy... i even wonder how the user triggered it unless looking to find this bug ;) | 16:56 |
| Sarvatt | tseliot: do you know if your changes to the inputclass matching are going to bump the input abi again? | 17:19 |
| Sarvatt | dont want to rebuild all the drivers against abi 9 if so is why I ask | 17:19 |
| tseliot | Sarvatt: we're still discussing the right approach with upstream therefore I'm afraid I can't answer your question | 17:20 |
| Sarvatt | gotcha, wasnt sure if adding new matches would be something that guarantees the need for an abi bump or not. thank you very much for working on that by the way, seems silly to expect people to fix things post install with how it is now :) | 17:23 |
| Sarvatt | i think its really going to be needed in the touchscreen land as well | 17:24 |
| Sarvatt | can you just add matches to subsystem vendor and product id's instead of exporting dmi info though? | 17:25 |
| jcristau | i still don't understand why quirky hardware can't be fixed in the hardware driver, but oh well. | 17:25 |
| tseliot | Sarvatt: what do you mean? Where are you suggesting to do that? | 17:26 |
| tseliot | jcristau: feel free to fix things in the kernel if you like ;) | 17:26 |
| Sarvatt | like there is a matchvendor and matchproduct which returns devices product/vendor id, but theres a subsystem vendor and product id specific to the hardware that everything has too that could maybe be used without needing the dmi info | 17:27 |
| Sarvatt | 04:00.4 System peripheral [0880]: JMicron Technology Corp. xD Host Controller [197b:2384] | 17:27 |
| Sarvatt | Subsystem: Acer Incorporated [ALI] Device [1025:015b] | 17:27 |
| Sarvatt | the 1025:015b part | 17:27 |
| jcristau | tseliot: my touchpads work fine thank you. | 17:28 |
| tseliot | ;) | 17:28 |
| jcristau | you're the one trying to add ugliness to X and xf86-input-synaptics, so i'm just asking why this needs to be there, and so far not getting an answer | 17:29 |
| Sarvatt | ahh have to run, i'll read the logs :) | 17:29 |
| tseliot | Sarvatt: as regards touchpads, those details are not enough for quirks | 17:29 |
| tseliot | jcristau: why do quirks exist? Same answer | 17:30 |
| === \vish is now known as vish | ||
| jcristau | not really no | 17:33 |
| === ripps is now known as ripps|sleep | ||
| bryyce | morning | 17:46 |
| Sarvatt | that -nv gamma fix works here, -nv works again. | 18:00 |
| Sarvatt | matching subvendor/product id's seems like it would let the quirks work for multiple oem's rebranding the same machine too, for instance I can use packard bell acer or gateway bios's on this machine and it returns a different manufacturer to DMI even though the pci subsystem id's are still the same acer oem ones, I've got a problem with dmi quirk matches in the kernel for i8042 reset not getting applied because they need the manufacturer to be | 18:12 |
| Sarvatt | acer even though the product is the same AOA150 to dmi. | 18:12 |
| Sarvatt | my keyboard layout is also screwed up because udev does the same, i have to manually go in and change the gateway quirk to match the acer one for this bios | 18:12 |
| Sarvatt | the brightness up key gives me ± unless I change it | 18:13 |
| bjsnider | ok, nvidia is now including opencl libs with the 195 driver | 18:26 |
| Sarvatt | ahh i see where that line of thinking is wrong, I'm thinking windows where that info is exposed for all devices and OEMs release their own customized drivers for their subsystem id ranges but I dont even see that info for a touchpad on linux | 18:43 |
| bjsnider | i've found the reason for the huge file size increase in the 195 nvidia blob. it now includes a file called libnvidia-compiler.so | 20:10 |
| Sarvatt | hope I'm doing this right - https://bugs.edge.launchpad.net/gtg/+bug/458545 | 23:30 |
| ubottu | Ubuntu bug 458545 in xserver-xorg-video-intel "[Needs -intel 2.10] Cairo/Gdk shapes not visible on Intel gpu since Karmic" [High,In progress] | 23:30 |
| Sarvatt | i dont know how to nominate it for release for xserver-xorg-video-intel, when I try to nominate it it only lets me for gtg | 23:37 |
| Sarvatt | so I haven't subscribed ubuntu-sru to it because of that | 23:39 |
| tjaalton | https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/458545 | 23:39 |
| ubottu | Ubuntu bug 458545 in xserver-xorg-video-intel "[Needs -intel 2.9.1] Cairo/Gdk shapes not visible on Intel gpu since Karmic" [High,In progress] | 23:39 |
| tjaalton | use that url instead | 23:39 |
| jcristau | why do the titles disagree? :) | 23:41 |
| tjaalton | it was edited in between :) | 23:42 |
| Sarvatt | yeah i edited it, saw it said 2.10 when i linked it there | 23:46 |
| Sarvatt | but was fixed in 2.9.1 | 23:46 |
| Sarvatt | thanks tjaalton, i tried changing it to https://bugs.edge.launchpad.net/xserver-xorg-video-intel/+bug/458545 but that didnt work | 23:48 |
| ubottu | Ubuntu bug 458545 in xserver-xorg-video-intel "[Needs -intel 2.9.1] Cairo/Gdk shapes not visible on Intel gpu since Karmic" [High,In progress] | 23:48 |
| tjaalton | you need to have "ubuntu" in there | 23:49 |
| tjaalton | no project named x-x-v-i | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!