[00:05] i dont know what to do about the gallium stuff though, Replaces: wouldn't work because someone removing libgl1-mesa-dri-gallium wouldn't have the files replaced over libgl1-mesa-dri restored. for now I was just shipping nouveau in libgl1-mesa-dri [00:07] So, options include: fixing the DDXs to load from the appropriate search paths & names, using the alternatives system, or conflicts/replaces/provides. [01:10] ugh, alternatives just might be the best option there :( [01:12] If intel had a non-sucky gallium driver I'd plump for conflicts/replaces/provides. [01:14] Actually, that could still work - just duplicate i*_dri.so into both packages. What fun! [01:15] duplicate every other non-gallium driver too? :D [01:16] it's just swrast and r300, could just divert those two? [01:17] llvmpipe swrast seems pretty important if we're going to package r300g, swtnl cards can use it for a huge speedup [01:17] in 7.9 that is [01:20] i hate diversions but i think that might be a better option since its just the 2, all the rest of the gallium stuff can just go in /usr/lib/dri and we dont need the dri-searchpath hack if we did that [01:21] i915g isn't bad at all btw, its just i965g that sucks [01:23] i915g and i965g have the same names as the classic ones so if you --enable-gallium-intel in the confflags-dri section you get gallium instead of classic btw [01:26] Do I need to install libkms in xorg-edgers? what's if for exactly? [01:26] if you have libdrm-dev installed yeah [01:26] otherwise nope [01:27] it'll probably be used for plymouth in MM [01:28] Sarvatt: Only if you take files from the installed directory. If I remember correctly, they get put under gallium/ in the build directory, which is where I take them from. [01:28] I was just wondering, because It wasn't pulled with the other libdrm updates and it sounded kinda important [01:30] RAOF: they dont here, they go in debian/tmp/usr/lib/dri when i build [01:30] That's after running make install. I take them from build/dri/glx/gallium [01:30] if i build without --with-dri-driverdir=/usr/lib/dri in the confflags-dri target they do go in gallium/ though [01:31] ah gotcha [01:31] ripps: nah not important now, not used for anything [01:32] it's only used for the xorg gallium state tracker now, and plymouth is planning on switching to it [01:32] Z [01:32] I think that the vmwgfx dri also wants it. [01:32] that needs the xorg state tracker [01:33] Fair 'nuff. [01:33] Given that we've got the relevant kernel module I was thinking of enabling that. [01:35] yeah planning on doing it in xorg-edgers once all this stuff is worked out for sure, thats why i was messing with enabling libkms before [01:36] mesa is going to take 2 hours to build in a few weeks at this rate :D [01:38] Feel like running that by the Debian dudes? I don't think they'd have a problem with enabling vmwgfx in experimental. [01:38] would like to see if it even works first [01:38] i think it's picky about mesa and kernel versions [01:39] Fair enough. [01:40] Woot! I've got Chase's xorg log from 2.6.34+lucid. Nouveau dies as expected, but fbdev picks up the slack. [01:40] That's pretty much the best possible outcome. Hurray! [01:41] wow, nice! [01:41] *that* i didn't expect, thats perfect [01:41] and makes sense, why didnt that work before? [01:41] i mean you have the framebuffer fine [01:41] ohhh i know [01:41] Did you test it after VESA stopped trying to claim the device? I'm not sure if I did. [01:42] it was because we had vesa loading for kms [01:42] Hah :) [01:42] sweetness :) [03:28] Hm. Is xorg-server 1.8.1+x-x-v-intel 2.11 actually faster at moving windows with all the bling, or is it just vsync working? [03:31] Ahem. Note to self: actually install the new -evdev before loading the new xserver. [04:09] Gah. -synaptics is a much better synaptics driver than evdev :) [04:10] that's why they call it synaptics? [04:12] Yup. [04:20] RAOF: did you build it locally and install with dpkg or in a ppa? i'm curious if you are getting nvidia-current and radeonhd force installed if you did ppa [04:20] Built locally, installed with dpkg. [04:21] i did it in a PPA on top of xorg-edgers and was getting nvidia-current and radeonhd installed after an apt-get upgrade for some reason [04:22] If you installed from a PPA I presume you also updated xorg-server? [04:24] Installing nouveau_dri into /usr/lib/dri-gallium seems to work fine, too. [04:26] it's not in /usr/lib/dri/ also? [04:26] Nope. [04:26] Well, AIGLX does complain trying to load it, but compiz swims along happily [04:26] hmm, and it loaded from /usr/lib/dri-gallium in Xorg.0.log? [04:26] ah [04:26] how many GLX fbconfigs/visuals do you have? [04:27] http://pastebin.com/JsWNk1rs [04:28] Many fewer [04:28] 24 and 40 respectively. [04:29] there's something really screwed up with that combination on ATI at least [04:29] compiz flips out and crashes all over the place unless the gallium one is in /usr/lib/dri/ [04:30] Well, I don't have an old enough card to test that, sadly. [04:31] trying to dig through phoronix forums to find the people that had the problem and see if i can get morei nfo [04:31] oh yeah, ripps has the problem too [04:36] http://pastebin.com/gh6uAmfh (in /usr/lib/dri-gallium) vs http://pastebin.com/csr5BUZi (in /usr/lib/dri) with i915g [04:39] Yup, it definitely changes things. [04:47] Hm. virt-manager doesn't like Maverick one little bit. [04:53] hmm all these people having problems are using gpu's with no hardware TNL that are sketchy anyway [04:53] ripps: what gpu did you have again? [04:54] Sarvatt: me? radeon 9600 pro - r300 [04:55] I stopped using gallium a while ago, because it had would create a huge lag when rendering subtitles with gl output in mplayer [04:55] Sarvatt, some of the people you're looking for might be in the #phoronix channel [04:57] https://bugs.freedesktop.org/attachment.cgi?id=35434 -- i pity the foo trying to run piglet on that [04:57] 192 visuals sheesh [05:05] Man, my intel only has 34 [05:20] yeah intel cut back on the worthless ones just for piglet cus they use it for QA testing every day, it takes a year to run through all those visuals for every test.. [05:22] added a 2.6.34 compatibility patch to x-updates fglrx-installer, just in time for xserver 1.8 to land soon and break it again :) [06:19] bryceh: did you get that xserver update into -proposed? [06:21] could have sworn you did but i dont see it [06:22] RAOF: hey master ... how are things going? [06:24] asac: just curious, you guys know you will need to package up the proprietary libgles/egl/etc for each arm platform to even do anything once you get things building right? [06:25] Sarvatt: yeah ... but we dont need to build against the proprietary drivers [06:25] asac: he's doing the work in debian-experimental it looks like and its almost done - http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/debian-experimental [06:25] just drop in the drivers and stuff built against that mesa gles stuff should work [06:25] cooool [06:25] have you seen how mameo is doing it? [06:26] nope [06:26] what are they doing? [06:26] they have a libgles-qemu package with the headers and its even debianized [06:26] ah ... yeah [06:26] meego sorry [06:26] thats a qemu gles emulation [06:26] Not quite as useful for us, at least as far as I'm aware. [06:26] we want to do that too [06:26] but its a bit of a pain to package afaiui [06:27] * RAOF wonders if vmwgfx does egl too. [06:27] Hm, yes it does. [06:28] So, if that *works* then we'd get gles under vmware (and I'm pretty sure that qemu is at least partially supported). [06:28] hmm. no clue about vmware ... [06:28] do they support arm? [06:29] (/me has doubts about that) [06:29] http://meego.gitorious.org/qemu-maemo/gles-libs and http://repo.meego.com/MeeGo/releases/1.0/core/repos/source/libgles2-qemu-1.3.0-1.1.src.rpm are interesting [06:30] hmm. so we font have the gles-libs? [06:30] dont [06:30] depends on what you want from gles libs, the mesa stuff isn't going to work on any arm systems [06:30] ah ok ... now i see its a gl to gles wrapper (actually the other way around) [06:31] qemu supports arm, and I know that airlied at least has played at passthrough 3d support. [06:31] yes qemu supports arm [06:31] Sarvatt, haven't done any xserver updates since before uds so probably wasn't me [06:31] Sarvatt: mesa doesnt support arm? e.g. not even software rendering? [06:32] anyway, as long as we can build stuff and then drop in the proprietary drivers that would be a big win [06:33] That should work, assuming sanity. The proprietary drivers should be providing their own libGLES*, right? [06:33] I have no idea, gallium has a hard requirement of DRI2/KMS, dont think the gallium swrast it's using will work on anything outside of maybe omap [06:34] RAOF: i guess so ... i talked to vendors here and they said it should be binary compatible (plus some vendor specific extensions) [06:34] RAOF: does mesa provide a libGLES.so with software implementation? [06:34] or dont we have a libGLES.so at all? [06:35] In debian-experimental it provides libGLES{v1,v2}, with swrast. [06:35] sounds like that should work [06:35] With swrast, radeon and nouveau drivers. [06:35] For both x11 and raw kms framebuffers. [06:35] yeah ... swrast should work unless i am mistaken [06:36] RAOF: so we the package is ready for synching and then pushing to lucid ppa? [06:37] It still needs some cleanup, but mostly in non-egl parts. [06:37] It takes forever to build mesa :( [06:37] heh [06:38] RAOF: you mean it takes forever on arm? [06:38] or even on intelA [06:38] ? [06:38] * RAOF shudders. [06:38] i'm scared how long it'll take on arm [06:38] It takes ~30minutes or so on my box. [06:38] how long is "foregver"> [06:38] heh [06:38] More if I'm not building on a tmpfs. [06:38] RAOF: thats decent. your CPU is idle most of the times anyway :) [06:39] Heh. [06:39] so finally there is somethign to do [06:39] You'd probably be happy with something that does egl in a pretty-much final state now, and then get the final package later, I guess? [06:40] RAOF: all i want is someth9ing i can get clutter build against :) [06:40] so yeah ... i dont care if its clean or anything [06:40] as long as its build and exports all the headers etc. in the -dev i am more than happy [06:40] Cool. I'll do that now, then. [06:41] The egl bits are pretty much ok. [06:41] you will do what? building clutter:) ? [06:41] j.k. [06:41] :) [06:41] let me know when its in mverick... i will push that to some arm ppa then [06:41] Build mesa in a PPA for you to copy from. [06:41] waste some build cycles most likely :) [06:42] RAOF: oh ... if you do that i would be3 eve happpier [06:42] e.g. already do the backport [07:00] RAOF: oh yeah need to hold off upgrading xserver and friends until pkg-config works on maverick also.. [07:00] I haven't seen any of that breakage. [07:01] pkg-config --cflags xorg-server [07:01] Right, yes. [07:01] I just haven't seen it break any of the packages I've been building. [07:01] Presumably because they haven't been pkg-configing xorg-server [07:02] ati nv radeonhd [07:02] I'm pretty sure there are some patches we can drop from xorg-server, too. [07:03] xorg-edgers only has 6 patches [07:04] not suggesting dropping a lot but a bunch dont make sense there like the arm one [07:04] So… why does 1.8.1-1ubuntu1 in pkg-xorg git have so many? [07:05] because none of them were submitted with attribution to push them upstream :D [07:06] So most of them are now upstream? [07:10] I wish! I've emailed 6 of the original authors of them asking for a git formatted patch that I could push upstream but haven't had any responses and stopped, a lot of them are really old [07:17] ok finally got a chroot set up to play around with this debian-experimental build since it doesn't build against newer libdrm. lets see if i can stay awake long enough to see the results :) [07:26] Sarvatt: You don't have a Maverick chroot already? [07:27] looks like sis, nouveau, nv, dove, and savage are broken by pkg-config 0.24 [07:27] (still grepping though) [07:28] video-vmware [07:28] radeonhd [07:29] i have *many* but none were in a position to build it [07:29] not exactly going to to build it on this atom for instance :D [07:31] Whyever not? [07:31] Hm… [07:32] takes around 1.5 hours [07:32] and i'm on battery [07:32] Only 1.5 hours? I'm surprised. [07:32] awwh heck i have the HDD space on my 16 core xeon vps for mesa! [07:36] Where do you have a 16 core xeon vps? [07:37] thenynoc.com [07:37] i just dont have much hdd space on it, hard to build kernels with 10gb [07:39] whoa baby, 7 second git clone of mesa from git.debian.org [07:40] That be hella fast. [07:43] RAOF: looking at the gles-libs readme it says: [07:43] Firstly, download and extract Mesa-7.6 and build it after applying a patch to [07:43] enable OpenGL ES 2.0 shader features. [07:43] do we apply that patch? [07:43] We do not. [07:43] is that a bad idea? [07:43] or could ew just do that so i can play with gles-libs? [07:44] Let me check if that's already enabled in mesa 7.8. [07:44] yeah thats what i was thinking ... at best it would already have made its way upstream [07:45] That'll also be enabling support in a diffrent codepath; I'm pretty sure the packages wending their merry way into a PPA will have GLES 2.0 shader features enabled via a different codepath. [07:46] that gles-libs meego uses doesn't actually build everything there, check out the .spec in the srpm [07:46] i am looking at the git clone of gles-libs atm ... not the rpm [07:47] RAOF: not sure what that means:) [07:47] if it means we dont need to apply that patch i am happy ... if i end up having issues i can come back [07:47] asac: That, while we might not have that specific patch, the egl packages in mesa 7.8.1-2 should have that feature anyway. [07:48] ah ok. then lets try without it [07:48] RAOF: what ppa will you push this to? [07:48] (mesa that is) [07:48] ppa:raof/mesa-egl [07:48] alf__: ^^ [07:49] RAOF: cool. i am going to bed soon. if the package arrives today pleas ping alf__ who might want to ry building clutter on that [07:49] RAOF: what timezon are you in btw? [07:50] UTC+10 [07:50] I'm approaching EOD Friday :) [07:50] ah :) [07:50] heh ok. [07:50] so i guess the package wont be there till monday [07:50] unless you are one of those crazy guys that work on sat :) [07:51] thanks again. talk to you soon [07:52] RAOF: Great! Thanks a 10^6! [07:52] :) [08:14] RAOF: dh_install -s --list-missing [08:14] cp: cannot stat `debian/tmp/usr/lib/libGLESv1_CM.so': No such file or directory [08:14] dh_install: cp -a debian/tmp/usr/lib/libGLESv1_CM.so debian/libgles1-mesa-dev/usr/lib/ returned exit code 1 [08:15] Sarvatt: Sorry. Try again now. [08:16] oh sweet ya merged it to origin/ubuntu too, thanks [08:19] Bah! No pkg-config files in 7.8.1 [08:21] 7.8-gles branch... :D [08:22] Or just steal them from master [08:26] lets see if master builds with origin/ubuntu debian/ [08:26] Probably not. [08:26] We'll need at least to switch to --enable-gles-overlay [08:27] DEB_BUILD_OPTIONS="parallel=16" is insane [08:27] You're running out of parallelism at that point. [08:28] Sweet. There's all the mesa demos built. [08:28] 4 minutes and its almost done with dri [08:29] insane, building the debs now [08:30] symbols are screwed up [08:32] Really? [08:33] I only have x86-64 and i386 to test build on, but I thought I'd captured all the relevant processor-specific symbols, and the internal symbols. [08:33] http://sarvatt.com/downloads/patches/7.8-gles.patch [08:33] one sec i'll give you the build log when its done, still creating the debs [08:34] that patch is a git diff origin/7.8 origin/7.8-gles [08:34] Ah, right. [08:34] 09:13.02elapsed [08:34] I was wondering :) [08:35] thats setting up the pbuilder and installing all the deps too, sheesh [08:35] BAH. [08:35] * RAOF wants [08:36] Well, gles v1 & v2 & openvg work. [08:37] http://paste.ubuntu.com/440744/ [08:37] symbols [08:37] want to use my vps RAOF? [08:37] Oh, yeah. Those symbols. [08:38] Wait. That's an i386, 16 core xeon builder? [08:43] resultant packages are here - http://sarvatt.com/downloads/mesa-gles/ [08:46] doesnt look like clutter needs the .pc's anyway [08:47] http://git.clutter-project.org/cgit.cgi?url=clutter/tree/configure.ac [08:53] RAOF, yo... [08:54] Well, they can get some pc files anyway. mesa-demos need them, and I like having something to test. [08:54] apw: Yo! [08:54] are you aware of reports that ati graphics using the kms drivers makes laptops hot and bothered, presume its doing poor power management [08:54] Yes. [08:54] It's not so much doing poor power management as having power management totally unimplemented. [08:54] Fixed in 2.6.35 [08:55] RAOF, hrm, thats going to be annoying for lucid, at least maverick may fix it then [08:55] At least, I think that got pulled in with the rest of the drm-next stuff. [08:55] Users can turn off kms to get power management, at least. [08:56] They'll loose dri2 by doing that, so it's not an unqualified win. [08:56] just turning off KMS gets them power management ? [08:56] Yup. [08:56] The UMS code has power management. [08:56] people are reporting goodness from switching over to prop. drivers [08:56] ahh ok ... will ask them to test that then and confirm awsome [08:57] The prop drivers also have power management, surprisingly enough :) [08:58] apw: Aaah, Sarvatt reminded me: are we going to be building the agp modules into the maverick kernel? [08:59] RAOF, do we need to be, i forget already, so many discussions at UDS [09:00] there doesn't seem to be another way to ensure agp init happens before drm init aiui [09:00] apw: It eliminates a class of bugs where the drm module gets loaded before the agp platform driver and breaks. [09:00] There's at least one launchpad bug, let me find it. [09:01] apw: it's only a problem on laptops supported by fglrx at least [09:01] i did think that at least the intel driver had a link to the AGP driver to make it load first as a dependancy [09:02] apw: intel is easy, there's only 1 chipset [09:02] so you can just load intel-agp and be happy [09:02] for non-igp, not so much [09:03] nouveau has it worse off by far regarding laptops getting hot [09:03] yeah i see i915 depends on intel-agp directly [09:04] Sarvatt, and nouveau is kms only i assume [09:04] Right. If you're lucky the card gets initialised to the lowest power state by the bios; that's what happens on my laptop. [09:06] oh dear, what a disaster kms is in .32 ... "but its pretty" [09:08] Well, nouveau has never had power management. I don't think nv does, either. [09:08] I *think* I read that nouveau it's starting to get power management [09:09] Man, my bandwidth up to launchpad sucks. [09:10] There haven't been any power-management related commits for nouveau yet, and I haven't seen a branch implementing it. [09:10] Heh. Ben Skeggs commits from the future. [09:12] * tseliot has suddenly become a fortune teller :-P [09:28] alf__: https://edge.launchpad.net/~raof/+archive/mesa-egl/+packages ← they haven't built yet, but I see no reason why they shouldn't. [09:34] pulled 7.8-gles into origin/ubuntu and installed the gles and egl pc's, lets see if this builds :) [09:36] i want to play with the demos too [09:37] RAOF: Thanks! [09:38] RAOF: you uploaded to lucid? [09:39] Requested 'libdrm_intel >= 2.4.19' but version of libdrm is 2.4.18 [09:49] 7.8-gles branch doesn't even build [10:00] Balls. Oh, well. One lucid libdrm backport coming right up. [11:43] has rendercheck been debianized? [12:25] Oh, curses. I should really have bumped the dpkg build-depends for mesa. Oh, well. That's now Monday. [12:34] might be better to just --enable-egl --enable-gles1 --enable-gles2 to get the headers and libEGL and drop gallium for now [12:35] As long as you're not building from 7.8.1, yeah. Those options don't exist in mainline. [12:35] huh? [12:36] oh I see [12:36] They're probably in the 7.8-gles branch, and they're in master. [12:36] Anyway, *this* build will probably work :) [12:37] And with that, I disappear. Like a phantom, into the night. [12:38] 7.8-gles doesn't build, and the openvg lib isn't there in master [12:38] done like 30 builds now trying to get things working [12:41] well your original one is working, I just want .pc's for mesa/demos :D [12:55] see ya RAOF! [12:56] well, packaged up rendercheck for the heck of it, i'm not sure about the license though (probably why it isn't in debian yet) [12:58] 2 files are MIT/X11, the rest are - http://pastebin.com/DBkfk3TR [14:30] is it acceptable to say make get-orig-source targets for some packages that are basically always going to be vcs snapshots because of infrequent releases? packaging up rendercheck and it looks like it hardly ever has releases even though it's been around since 2004, intel-gpu-tools is the same way [14:34] was thinking about something like this - http://paste.ubuntu.com/440869/ [14:35] not sure if there's more files I should exclude from the newly packed orig.tar.gz though [14:35] autom4te.cache? [14:36] oops minus the rm snapshot-date at the end there [14:38] openchrome could really use a get-orig-source target [17:55] hello, i have two similar issues in two different systems [17:56] 1) low end machine running 10.04 with vesa driver (s3 card). once X is started i can't switch to VTs or shutdown/reboot because the screen corrupts [17:56] 2) high end machine with nvidia-current closed driver, VTs aren't working. the rest is all fine [17:56] any clue on this? [18:25] well debianized that for the heck of it - http://sarvatt.com/git/cgit.cgi/rendercheck/ [18:25] C10uD: how long have you waited for a VT switch to happen with nvidia-current? [18:25] it's taken me close to a minute before.. [18:27] C10uD: for both cases I'd try doing a echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-local.conf && sudo update-initramfs -u to see if its any better [18:27] i think almost a minute, i'll try again.. i'm asking because i wanted to see if with the new beta driver i could get any improvement [18:27] thanks Sarvatt i'll try [18:27] C10uD: did you install the new beta driver from nvidia.com? [18:27] not yet [18:27] thats a recipe for disaster and it doesn't work on anything newer than karmic [18:28] use this PPA instead - https://launchpad.net/~ubuntu-x-swat/+archive/x-updates [18:28] oh, thanks for the info then, btw i was more interested in the problem 1) :p [18:28] i'll wait for a new nvidia [18:28] the new nvidia is in the PPA, drivers from nvidia.com aren't compatible with lucid or newer and probably wont be for a long time [18:29] to downgrade back to the lucid ones when you have x-updates activated if you don't like the newer beta drivers, just sudo apt-get install ppa-purge && sudo ppa-purge -p x-updates ubuntu-x-swat [18:29] bad nvidia :) thanks for the link though, i watched the good ol' nvidia-vdpau repo for updates but no luck for lucid.. [18:30] any reason why you are using vesa with s3? [18:30] that's because the driver is in the x-updates ppa [18:30] the guy working on nvidia-vdpau is helping us do the x-updates :) [18:30] * Sarvatt points at bjsnider [18:31] jerk, not guy. i prefer jerk [18:31] Sarvatt, in this system i don't really need a graphics card, so i just moved the xorg failsafe conf [18:31] well if vesa is causing problems which is does it might be worth using xserver-xorg-video-s3 instead :D [18:32] but, is the x driver capable of corrupting the screen after x is killed? (x noob here) [18:32] anyway, now i'll try moving back to auto-recognizing of video card [18:33] pretty sure vesa is capable of that, yeah. vga16fb/plymouth might be adding an additional layer of screwed up on top of that too :) [18:34] i'll try asap then [18:34] just remove /etc/modprobe.d/blacklist-local.conf and sudo update-initramfs -u again after if blacklisting vga16fb doesn't help [18:34] what GPU do you have thats screwing up with the nvidia driver? [18:35] nvidia 9400 [18:35] best bet would be to boot the nvidia machine up and run ubuntu-bug xorg and paste the link after you submit it here so we can see the logs [18:35] is it a mobile one? one of the hybrid gpu's? [18:36] nope, plain 40$ desktop [18:36] ah [18:36] 9400 was onboard [18:36] i am doing some potentially bad stuff in grub though, such as telling acpi_enforce_resources=lax and setting GRUB_GFXMODE=1280x720 [18:36] i've seen people with 9400M in macbooks unable to vt switch is why i asked [18:37] bjsnider, thanks for your ppa though, it helped a lot when i wasn't running lucid :P (even if vdpau was (IS) a little screwed though, seems(ed) like it's not vsync'd) [18:38] NVIDIA GPU GeForce 9400 GT (G96) at PCI:1:0:0 (GPU-0) [18:38] C10uD: its also possible you have some cruft left behind interfering with things, would be able to see that right away if you did a ubuntu-bug xorg and filed one [18:38] well ubuntu-bug nvidia-graphics-drivers would be more appropriate [18:39] mind if i update the drivers first? [18:39] hopefully it wont reject the bug because of unverified packages if you do :) [18:39] if it does just do it via ubuntu-bug xorg [18:40] Amaranth, do you have a link to the one report on compiz + intel you had reported on a week or so ago? [18:40] anyway, i put the GRUB_GFXMODE thing in grub because plymouth broke up (i think i was still in ubuntu beta) and 1080p didn't seem to work [18:41] C10uD: yeah you arent gonna get a pretty splash with the nvidia binary drivers, i wouldn't even bother [18:41] 720p was almost nice :p [18:41] i think the text mode splash when you blacklist vga16fb looks better personally [18:42] 720p 16 color splash... [18:42] C10uD, the ppa is stil relevant even with lucid's packages but i spend more time on the cutting-edge multimedia ppa now [18:43] theres a way to use uvesafb with the plymouth framebuffer renderer but its a pain in the butt to set up just for a 5 second splash [18:44] yes, in fact i was tempted to remove all plymouth plugins [18:45] is somebody here using kde? [18:45] just blacklist vga16fb and remove splash from the boot stanza, removing all the plugins will probably break things :) [18:48] the text renderer once you blacklist vga16fb aint bad at all though, just a black screen with ubuntu 10.04 in text on it and 4 dots :) [18:49] packages installing... thanks for the tip, i'll try it [18:57] i need to try the blob with acpi=off, odd nouveau 3D works fine but both karmic and lucid are screwed up and i know karmic's nvidia-185 wasn't screwed up before [19:04] Sarvatt, the trick worked great here (nvidia), thank you very much :) i'll try the other system asap [19:24] Sarvatt, the vga16fb trick worked also in the other system! many thanks! [19:24] no worries, vga16fb is evil :) [19:27] indeed :( [20:24] hey, any ideas how to restrict my wacom tablet to other monitor in lucid? i'm totally stuck... === schmidtm_ is now known as schmidtm [21:50] knome: Option "ScreenNo" "n" ? [21:50] hmm, what is this.. Create a new source package recipe on code.edge.launchpad.net [21:51] yeah I noticed that myself [21:51] recipe [21:51] sounds yummy, I wonder what it is [21:53] mmm bzr help builder [21:53] i'm warming up to bzr so friggin much, if only it wasn't so darn slow [21:54] nice being able to handle git repos in bzr natively, and just bzr pull to git pull and bzr push to push it [21:55] oh wow, my mesa packaging branch + lp:~vcs-imports/mesa/master.... [21:57] yep [21:58] niiice, you can just use upstream git + merge only packaging from ubuntu in one recipe [21:58] thought you'd need a packaging only branch but nope [21:59] hmm guess i would nest a packaging branch inside the other instead of merge packaging since its only packaging [22:00] need to figure out the recipe to get the version names decent [22:00]