[00:00] perhaps a note in the PPA would be helpful [00:12] ah [00:12] * ilmari ponders doing the live usb stick dance to test newer intel drivers [00:12] but can't be arsed tonight [00:13] maverick has nasty flickering on my laptop monitor on the diagonal stripy background on http://bbc.co.uk/iplayer/ [00:14] thinkpad x201s, core i7/arrandale [00:18] ilmari: ppa-purge works great for reverting anything xorg-edgers installs on your system [00:18] ooh, neat [00:19] * ilmari gives it a go [00:20] at least on maverick and earlier, apt stores indices compressed now in natty so ppa-purge doesn't work at the moment [00:21] ah, maverick here [00:22] huh, why new ia32-libs? [00:24] because ia32-libs has mesa in it, you'd be using the distro mesa for wine or google earth otherwise [00:24] leads to a lot of problems when the distro mesa advertises opengl 1.5 and the PPA one does 2.1 and people are confused and such :D [00:25] ah [00:25] bah, my internet connection seems to be emulating a piece of wet string: 119kB/s, 7min 52s remaining [00:26] I usually get ten times that [00:46] if anything, the flicker is worse with xorg-edgers [00:46] * ilmari tries upgrading the kernel too [00:56] RAOF, had a chance to look through my mesa rules file? [00:57] bryceh: Have you pointed me at it yet? [00:57] RAOF, yes [00:57] Ah. I have therefore missed it. [00:57] RAOF, direct link... https://launchpad.net/~xorg-edgers/+archive/wayland/+sourcepub/1372289/+listing-archive-extra [00:57] Oh, it's in wayland PPA? [00:57] Ta. [00:58] yeah https://launchpad.net/~xorg-edgers/+archive/wayland/ [00:58] $ sudo apt-add-repository ppa:xorg-edgers/wayland [00:58] $ sudo apt-get update [00:58] $ apt-get source mesa [00:58] how the heck do you get flickering on an LVDS-connected internal laptop monitor anyway? [00:59] By driving it incorrectly? [00:59] here's the wayland output from the broken case: http://pastebin.ubuntu.com/535723/ [00:59] here it is working, using bits I built manually: http://pastebin.ubuntu.com/535724/ [01:00] mostly that's all with the same versions of everything (more or less), the difference is packaging [01:01] RAOF: I guess. it didn't do it on lucid [01:01] http://static.bbc.co.uk/iplayer/3.11.0/img/module_cf_background.png # horrible flicker [01:01] I see in the working case it's using lib/dri/i965_dri.so, whereas in the broken case it seems to be using lib/egl/egl_gallium.so [01:02] Ah, good old 8086:2a42 [01:02] Yeah. It shouldn't be using that at all. Well, not unless you want your GPU to lock up :) [01:03] It occurs to could use he daily-builds infrastructure for this… [01:03] After we get it to work once, of course :) [01:03] borked grammar be is? [01:03] HAH! [01:03] but yes indeedy [01:04] well, actually what I'd like to do is get the deps into universe (libxkbcommon uploaded today, awaiting review) [01:04] and I'd like to see if we could merge the mesa changes into xorg-edgers [01:05] if that's all done, then yeah wayland git snapshots could just be one more bit in xorg-edgers ppa [01:05] And even the archive mesa, once we flip to 7.10 [01:05] yep [01:06] if I can get wayland into universe for natty I think it'd be awesa mesa [01:08] Hm. We probably want egl-platforms="drm x11", don't we? For the benefit of running wayland under X? [01:09] export EGL_PLATFORM=drm x11 seems to make no difference [01:09] here's the configure string I'm using to build it manually: [01:09] ./autogen.sh --prefix=$HOME/install --enable-egl --enable-gles2 --disable-gallium --with-egl-platforms="drm" [01:09] make [01:12] And you still get a egl_gallium.so in $(HOME)/install/lib/egl? [01:13] $ ls /home/bryce/install/lib/egl/ [01:13] egl_dri2.so* egl_gallium.so* egl_glx.so* pipe_nouveau.so* pipe_r300.so* pipe_swrast.so* st_GL.so* [01:13] $ ls /usr/lib/egl/ [01:13] egl_dri2.so egl_glx.so pipe_r300.so pipe_swrast.so st_GLESv2.so [01:13] egl_gallium.so pipe_nouveau.so pipe_r600.so pipe_vmwgfx.so st_GL.so [01:14] That seems moderately odd, given --disable-gallium [01:14] interesting [01:14] root@lynmouth:/usr/lib# mv egl egl-orig [01:14] root@lynmouth:/usr/lib# cp -r /home/bryce/install/lib/egl . [01:14] after that, it worked [01:20] Does running “EGL_DRIVER=egl_dri2 wstart” work? [01:20] nope, same output [01:21] And if you just plain delete /usr/lib/egl_gallium.so? [01:21] ditto, tried it several times in various ways [01:22] I deleted all the files not present in the hand-built egl too [01:23] if I only copy the egl_gallium.so and egl_dri2.so from the handbuilt stuff, it works [01:23] ok it's definitely egl_dri2.so [01:24] either of the egl_gallium.so's will work [01:24] -rwxr-xr-x 1 root root 79022 2010-11-23 17:14 egl-new/egl_dri2.so* [01:24] -rw-r--r-- 1 root root 22444 2010-11-22 19:22 egl-orig/egl_dri2.so [01:24] Oooh. [01:24] the broken one is much smaller [01:24] What if you disable tls? [01:25] can that be done via env var? [01:25] No, it's a build-time option. [01:25] hrm [01:26] ok let me try [01:26] It seems to be the only interesting #ifdef in egl_dri2 [01:26] --disable-glx-tls ? [01:27] Or --enable-glx-tls on your home build. [01:27] what is tls? [01:28] thread-local-storage. [01:28] oh that might be easier [01:30] http://pastebin.ubuntu.com/535736/ - local build configuration [01:31] I guess the other possibly interesting #ifdef is libudev; do you have the udev devel libs locally? [01:32] Yes is the answer; I can read that from configure :) [01:32] hmm, local build still worked with --enable-glx-tl [01:32] +s [01:34] Aaaah. [01:35] was that a scream of frustration or a sign of discovery? [01:36] A suggestion of discovery. [01:36] libudev isn't available on the buildds, and that's the other interesting #ifdef in egl_dri2 [01:37] Moving /usr/lib/pkgconfig/libudev.pc somewhere pkg-config can't find it should make your local build not use libudev, which'd be an easier test. [01:37] (after you ./configure, of course) [01:38] weird, my local debuild of mesa with --disable-glx-tls failed [01:39] http://pastebin.ubuntu.com/535738/ [01:40] nope, still works with libudev.pc moved aside and mesa rebuilt/reinstalled [01:40] RAOF, I didn't do a make clean first though... think it matters? [01:41] I'll try that just in case [01:41] It might. mesa's build system is moderately stupid, that awy. [01:41] oh whoops also found another flaw [01:41] Your working local copy is definitely following a codepath that's #ifdef HAVE_LIBUDEV [01:42] ok so wasn't a flaw after all [01:42] Actually, it looks like egl_dri2 with egl-platform=drm should be dependent on libudev, as it doesn't look like there's any chance of it working otherwise. [01:44] RAOF, libxkbcommon pulls libudev-dev as a build dependency [01:44] but libxkbcommon-dev doesn't list it as a depends [01:45] "udev" isn't in mesa's debian/control [01:45] [01:45] And the build logs in the PPA show LIBUDEV=/... no [01:46] It's probably correct for libxkbcommon-dev to not pull in libudev-dev. There should just be a bit of a configure patch for mesa to mention that libudev is a requirement for egl_dri2 to work properly :) [01:50] so should I pop that into control ? [01:50] OOH! [01:51] after make clean and make of local mesa, it fails the same way [01:51] btw, strace logs: [01:51] http://www2.bryceharrington.org:8080/files/broken.log [01:51] http://www2.bryceharrington.org:8080/files/working.log [01:57] Yeah. I'll do the same for the archive mesa. After lunch! [01:57] indeed, dinner time here [01:57] * bryceh kicks off mesa build in wayland ppa [01:58] crossing fingers, and now fingering croissants... [07:12] hi, is there anyway we can get the apport-gpu-error-intel script not to fire over 100 times when there's an issue? [07:13] micahg, dunno but I'd love it if we could [07:13] micahg, maybe talk with pitti about it [07:14] bryceh: ok, it's an apport issue then? [07:15] it's a combination apport and kernel thing [07:15] kernel fires, apport reacts [07:15] and that's triggering the script in the driver package? [07:15] yes [07:16] bryceh: great, thanks [07:16] yep [07:38] “It'd be easy to make that fire once per boot” :) [07:38] I get it on resume from suspend a lot [07:39] then pidgin goes bonkers, I thought that was a kernel bug that was fixed in 2.6.35, but apparently it wasn't /end OT rant [07:42] Oh, boo. I forgot my Cedar isn't supported for accel in the natty packages yet. [07:44] Time to fire up the r700 and upgrade to natty... [07:45] ok... new mesa built... installing... [07:47] *blink* [07:47] YAY! [07:47] waylandage [07:47] Why does konsole have a “ZModem upload” button in the “Edit” menu‽ [07:47] bryceh: Yay! [07:47] ZModem! [07:47] I know! [07:48] I used that, like 15 years ago! [07:48] boy I loved that... 15 years ago [07:48] heh [07:49] RAOF, thanks again for your help [07:49] I've made that change in the 7.9 merge, too. [07:49] kewl [07:49] And just as soon as this r700 is updated to natty & I can test it, I'll trawl for sponsorship :) [07:49] last thing I need to do is fix up the client apps. by default they have a hardcoded lib path which doesn't work when they're copied to /usr/bin [07:50] RAOF, thought you were core dev now? [07:50] Why did you think that? [07:50] RAOF, because I saw you on the patch pilots schedule [07:50] coming up soon, too iirc [07:50] * RAOF needs to check that schedule again. He wasn't on there last time he checked! [07:51] You don't have to be core-dev to be on the schedule. [07:51] is the requirement motu or better? [07:52] I think the requirement is actually “Canonical employee” [07:52] ...on the platform team. [07:52] I noticed Jono Bacon wasn't on it [07:53] and I pointed this out to him. ;-) http://www.jonobacon.org/2010/11/20/new-ubuntu-patch-pilot-scheme/ [07:55] anyway, yeah I understood it was also 'all platform team employees', but it seems like we're missing people from it [07:56] RAOF, oh wow, you're on day after tomorrow for US Thanksgiving [07:56] probably will have a nice quiet time [07:56] if you get bored you could sneak a few X patches into the sponsor queue - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/patches.html ;-) [07:57] I actually count that as tomorrow. [07:57] I might just do that :) [07:58] I've been trying to clear a patch or two a day since I got back. The list is a lot shorter than it used to be [07:59] the remaining xorg-server ones may be a bit tricky [07:59] anyway, I'm beat. night, tty tomorrow [07:59] Sleep well! [08:05] Hm. Anyone here have an r300-r500 system? [08:05] And are running Natty, and would like to guiniepig a new mesa switching to gallium? [11:33] Ok. 10:30 is too late. Sponsor hunting begins tomorrow. === apachelogger is now known as releaselogger [16:51] Sarvatt: in order to use r600g from edgers, all I have to do is move r600_dri.so to /usr/lib/dri, right? (just to double-check) [16:52] yep thats one way to do it [16:52] launching your app with LIBGL_DRIVERS_PATH="/usr/lib/dri/gallium" is another way [16:53] Sarvatt, hi [16:53] Sarvatt: ok. I think I've found my 1st bug in gallium then [16:54] r600g, that is [16:54] Sarvatt, do you know about this edid bug with 2.6.37? [16:54] heyo ricotz, still having problems with i915? was meaning to say I think it might have just been the 2.6.37-6 kernel that was busted at the time [16:54] ricotz: hmm I know of a edid problem with displayport monitors on radeon in -rc3 but not intel [16:54] err -rc2 [16:55] yeah, my old nvidia card is broken, i needed to get it to work on this onboard intel, but i had no luck [16:56] now i am on a gf104 with nvidia blob [16:56] which has some weird edid problems [16:57] using dvi connection [16:58] what kind of edid problems? [16:58] it doesnt get any display information [16:59] is this on a sony vaio? [16:59] getting kind of the same with nvidia blob and nouveau [17:00] tseliot, no it isnt a laptop [17:00] ok, it must be a new issue [17:00] new to me, at least [17:01] seems to be kernel problem [17:01] could be a problem of the nvc0 stuff [17:05] ricotz: did you file a bug report about it? [17:05] if not, please do so and I'll ask Nvidia about it [17:06] ricotz: gf104 support is even in the kernel now? I didn't know [17:06] * Sarvatt is on a gf106 atm [17:07] tseliot, no havent reported anything yet [17:07] last time I booted without the blob in early .37 nouveau didnt work still [17:08] just wanted it working since i need this pc ;-) [17:08] I can understand ;) [17:08] Sarvatt, nouveau seems to work with nomodeset [17:08] meaning nouveau doesnt work :) [17:09] (nouveau doesn't work without KMS) [17:10] Sarvatt, on a normal boot nouveau get stuck in some loop with some edid error [17:10] I dont need nomodeset on this thing though, it just spits out an unsupported chipset warning and stops loading nouveau [17:10] tseliot, i think i found the nvidia installer hook. see if this sounds familiar: if the file /usr/lib/nvidia/pre-install exists, the nvidia-installer executes it, which is just an exit command? [17:11] digging now, i've seen quite a few bugs about edid problems on -37 maybe something will pop up [17:11] bjsnider: yes, that's how it works [17:11] so then let's put that file in jockey-common instead of nvidia-common [17:12] https://bugzilla.kernel.org/show_bug.cgi?id=23482 was one of them but just radeon displayport [17:13] Sarvatt: Error: Could not parse XML returned by bugzilla.kernel.org: The read operation timed out (https://bugzilla.kernel.org/xml.cgi?id=23482) [17:14] http://lkml.org/lkml/2010/11/17/169 [17:22] bjsnider: yes, I should talk to pitti about that [17:25] Sarvatt: I'd like to add a udev rule and a configuration file (in /usr/share/X11/xorg.conf.d) so as to enable scrolling with the middle button + the trackpoint on thinkpad x201 models. This is the default behaviour in Windows and it helps a lot since the laptop doesn't have a touchpad [17:26] Sarvatt: I think I should add this to evdev. I'll file a bug report about it so that we can discuss it [17:26] yeah sounds good to me, I've seen that bug [17:26] Sarvatt: ah, is there one open already? [17:26] yeah let me dig it p [17:27] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/554984 [17:27] Launchpad bug 554984 in xserver-xorg-input-evdev (Ubuntu) "[lucid] enable trackpoint scroll emulation by default (affects: 8) (dups: 2) (heat: 42)" [Wishlist,In progress] [17:28] Sarvatt: right. I guess we should apply this only to some models, i.e. when a touchpad is not available [17:29] * tseliot doesn't want too many angry thinkpad users to complain in the bug report [17:29] x201 wouldn't make sense then would it? x201 has a touchpad, x200 doesn't [17:29] just a few would be acceptable ;) [17:29] my x201 doesn't have a touchpad [17:30] oh must be able to configure it out, weird [17:30] I can make sure that wheel emulation is applied only to the model that I have [17:32] x200, x200s, x61, x61s would be good to add to that since you couldn't even get a touchpad on those [17:33] hmm Touchpad Assembly for IBM ThinkPad X61s [17:33] maybe I have bad info :) [17:35] my x201 is pretty new, so maybe things changed a bit [17:37] aah, it seems that the touchpad is available only in certain configurations [17:38] I remember one of the big things in all the reviews when x201 came out a year ago was that it brought back the touchpad, looking at lenovo.com it looks like just trackpoint is the default and trackpoint+touchpad is $20 extra [17:38] http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087¤t-category-id=4F2AFFFF52964FE2BCF0CC608A649A77&action=init [17:39] when I bought it, it didn't allow my to select a touchpad [17:39] dang $899 now, thats tempting [17:39] if you get the model with the touchpad you don't get access to the icore 7 cpu [17:40] ah, you can choose now [17:40] hmm [17:40] heya tseliot! [17:40] wish they would sell x201s again [17:40] hey bryceh [17:41] what's the difference? [17:41] 1440x900 screen, lighter [17:41] oh [17:42] mine is quite light but the 9 cell battery is heavier than the rest of the laptop [17:42] more robust as well, I think ("enhanced roll cage") [17:43] no 3g though :( [17:43] I love my x201s, especially with an intel SSD :) [17:43] oh it use low voltage cpu's too instead of the normal laptop ones [17:43] so half speed GPU in linux most of the time :) [17:44] yes, intel SSDs are great [17:45] I love my 160gb SSD [17:45] x201s was like twice the price the x201's are now when they sold them though [17:45] ilmari, Sarvatt: do you happen to have a thinkpad x201 around? [17:46] I'd like to see the output of "dmidecode" [17:46] tseliot: I have an x201s [17:46] ilmari: that would be fine too [17:46] I'd like to see what it says [17:46] tseliot: nope, I bought a desktop replacement instead at plumbers, was going to get an x201 or a sony Z but decided on this asus G73JW instead since the Z was so flimsy [17:47] so that I don't enable wheel emulation by mistake on that model [17:47] would wheel emulation be bad to enable globally for trackpoints? [17:48] good question. I guess not [17:48] tjaalton: ^^ [17:48] * tseliot knows that tjaalton used to have a thinkpad [17:50] tseliot: you know you can install gpointing-device-settings to enable it in the gui right? [17:51] Sarvatt: is it the tool that used to work with shared memory instead of xinput? [17:51] tseliot: http://paste.scsys.co.uk/57082 [17:51] serial numbers and uuids redacted [17:51] ilmari: thanks [17:52] tseliot: nope it's the newer relacement for gsynaptics [17:52] should I be worried that it says Type: for the memory modules? [17:52] Sarvatt: aah, gsynaptics is the one that's deprecated. I'll have a look at the new tool then [17:52] gsnaptics was that old SHMConfig one [17:53] right [17:53] I'm wondering how the new tool saves settings [17:56] xinput properties and gnome-settings-daemon plugin [17:59] nice. Finally someone developed what I never had the time to complete :) [18:00] one less item on my endless todo list [18:01] ilmari: do you know if wheel emulation is enabled by default in Windows on your laptop === njpatel is now known as njpatel|away [18:01] well, I guess Lenovo enables that [18:01] what is this windows of which you speak? [18:02] i'd be a fan of installing that trackpoint xorg.conf.d snippet with evdev personally but I'm partial to things that makes the experience not suck out of the box :) [18:02] * ilmari never booted the pre-loaded windows [18:02] (for all trackpoints) [18:02] the first thing I did when I got it was to replace the drive with an intel ssd and boot the lucid installer from usb [18:03] the original drive is still sitting on my desk at work [18:03] ilmari: oh that's the machine you had flickering problems with on lucid? [18:03] Sarvatt: no, I have flickering problems on maverick (and edgers), but not on lucid [18:03] use the maverick kernel, I would have recommended that from the start if I knew :) [18:03] ahhh [18:04] Sarvatt: +1000 :) [18:04] let med find a usb stick to build a lucid live thingy to re-test with [18:04] ilmari: so thats one of the ones bitten by 2.6.35-rc7.. [18:05] ilmari: thats ok we probably backported just enough eDP stuff so it doesn't suck and not the breakage, it'll probably break again in lucid-updates at some point :( [18:06] ilmari: 10 bucks says this doesnt flicker on maverick http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc6-maverick/ [18:07] (fictional internet money of course) [18:07] * ilmari installs [18:14] tseliot: yeah i have an x61 [18:14] wheel emulation is great [18:14] tseliot: btw, JumpyCursorThreshold rocks! and looks like it's not needed with synaptics 2.3.0 anymore from my testing, but 2.3.0 has this really nasty acceleration stuff added that is completely screwed up here on every touchpad I've got [18:15] tjaalton: do you remember if it's on in Windows by default on most thinkpads? [18:15] but it wasn't enabled on my friends' win7 t401 when I used it briefly yesterday [18:15] though maybe he turned it off. I'll ask [18:16] Sarvatt: it's a hack that I had to write when I was hired. I'm glad to read that 2.3.0 gets things right. I'd like to try it with a with a Dell mini 10v [18:16] tjaalton: it would be nice to know. Thanks [18:17] pretty sure http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a6ca4d2523904b7ce49edc29ba408979bdf0d45e is what fixed it in 2.3.0 on my asus [18:17] * tseliot felt a bit lost after learning wheel emulation in Win 7 (my 1st time with both the pointer and Win 7) and not finding any in Ubuntu [18:18] Sarvatt: aah, maybe your touchpad supports multiple fingers [18:18] the one on the mini 10v doesn't :( [18:19] with MatchProduct "TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device|Composite TouchPad / TrackPoint" it works great on my dell e64x0 trackpoint too :) [18:19] Sarvatt: no luck :( [18:20] Sarvatt: with stock maverick xorg [18:20] oh, so some dell laptops have trackpoints too [18:20] ilmari: darn, that one didn't have flickering problems on the HP and sony LM eDP machines [18:22] Sarvatt: does that have anything the xorg-edgers kernel doesn't? [18:23] I tried taking the full xorg-edgers hit yesterday, didn't help at all [18:23] ilmari: nope, more specifically it doesn't have what the newer kernels have that regressed it on some machines and fixed it on others :) [18:25] ah, it's an _older_ kernel than the maverick one? [18:25] yeah [18:25] will let ya know if i find anything, digging around for the x201s flickering bugs now [18:25] cheers [18:26] it and the disappearance of ctrl-pgdn in aptitude are my only annoyances with maverick so far [18:29] ilmari: booting with i915.powersave=0 might be worth a try, thats a longshot though [18:31] i think self refresh is enabled unconditionally now regardless of that setting anyway, pretty sure its a problem there [18:32] ilmari: http://bugs.freedesktop.org/show_bug.cgi?id=27589 ahh I thought I forwarded a similar bug about that at some point [18:32] Freedesktop bug 27589 in DRM/Intel "[GM45] Occasional flickering unless powersave=0 is used on lenovo laptops." [Normal,Reopened] [18:33] it got a lot of me-toos including people with arrandale, the gm45 people had it fixed by powersave=0, it was FBC related and it was limited to part of the screen [18:34] x201s flickering probably isn't related [18:36] ilmari: hmm, do you have an enable/disable rc6 option in your bios? [18:36] this only happens where and when a stripy pattern is displayed [18:37] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/680748 [18:37] Launchpad bug 680748 in xserver-xorg-video-intel (Ubuntu) "[arrandale] flicker on LVDS laptop display with stripy patterns (affects: 1) (heat: 6)" [Undecided,New] [18:38] LVDS?! [18:39] LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 261mm x 163mm [18:39] 1440x900 50.0*+ [18:42] sorry for wasting your time with the 2.6.35-rc6 kernel then :( [18:42] 00:58 < ilmari> how the heck do you get flickering on an LVDS-connected internal laptop monitor anyway? [18:42] 00:59 < RAOF> By driving it incorrectly? [18:42] (times in GMT) [18:45] Sarvatt: no problem. any ideas how I can go about troubleshooting it? [18:45] bisect time? [18:48] ilmari: save the intel_reg_dumper output, find a kernel where it doesn't flicker (can just use the mainline kernels or a lucid livecd) then save that intel_reg_dumper output and attach it to the bug, i'll forward it upstream for ya [18:51] forwarding it now [18:51] I'm stumped, hopefully they have ideas. all the intel guys have x201s machines I believe :) === releaselogger is now known as apachelogger === apachelogger is now known as bloglogger [19:07] hm, I wonder if it can boot from the sd card? [19:07] s/\?$// [19:11] ilmari: https://bugs.freedesktop.org/show_bug.cgi?id=31901 [19:11] Freedesktop bug 31901 in Driver/intel "[arrandale] flicker on x201s LVDS laptop display with stripy patterns" [Normal,New] [19:11] depends on the laptop, I dont have any that can boot off SD [19:12] if it's hooked up internally via USB you probably can, like some eee pc's and dells [19:13] ilmari: can you add your email to the cc list on that bug? [19:15] will do [19:15] as soon as I get my password reset email [19:15] ETOOMANYBUGTRACKERS [19:16] I can add ya, just wasn't sure which email address you'd prefer [19:16] ilmari dot org? [19:16] yeah [19:16] thanks [20:21] tseliot: windows has wheel emulation by default, if the proper driver is installed [20:21] yay, no more mesa implementation error: bad renderbuffer format spam http://cgit.freedesktop.org/mesa/mesa/commit/?id=78a340fd487c56468ace7347a53f95a0c751c419 === bloglogger is now known as apachelogger [20:49] tjaalton: ok, thanks [21:39] Sarvatt, a few days ago you mentioned: [21:39] bryceh: already fix up cairo locally or want me to upload it? [21:39] (optional)__gnu_lto_v1@Base 1.10.0 [21:39] what was that change for? Should it go into the wayland cairo build? [21:40] Sarvatt, oh, that was for the natty build of cairo-gl, gotcha [21:40] new symbol picked up in natty because of -flto, i already uploaded that to the ppa and its in the archive cairo? [21:43] wouldn't hurt to have that in the maverick one since its optional [21:44] alright, I can add it [21:44] oh wow, no more edge on launchpad [21:44] yep [21:44] hope that doesn't mean links with edge stop working one day :) [21:45] dont even want to think about how many wiki's i've put edge on [21:46] I'm sure they've got permanent redirects in place [21:50] bryceh, the lto thing is in natty proper [21:50] it's a new symbol which get defined when lto support is available in the build chain [21:51] nothing to do with gl or wayland [21:51] ok [22:21] Sarvatt: reg dump attached (no flicker on 10.04.1) [22:25] (to the fdo bug, not launchpad) [22:38] gotta love intel docs, the differing bits i've checked so far are all just marked "reserved" :) [22:41] "reserved" is just code language for "nobody knows anymore" ;) [22:42] At least none of them are marked “Chicken” [22:42] :) [23:13] darn there really is no point to shipping vmwgfx in edgers anymore, I thought the tools would build vmwgfx since that vmware guy requested we stop building it with the kernel but nope [23:21] RAOF: ya doing crap with mesa? did you reenable nouveau-vieux by any chance? :) [23:21] Hm, I did not. [23:22] Thanks for pinging me; I was about to search for sponsors. [23:22] heh @ http://lwn.net/Articles/416982/ [23:22] We might as well load it into dri-experimental again :) [23:22] they were debating calling it stable on the wiki but stopped when it came to the fact people might actually submit bugs :) [23:24] shoving it in dri has my vote, it's a lot better off than say, savage [23:28] Ok. [23:28]