| Sarvatt | darn, i really need to check patches more carefully to see if they are upstream, quite a number are applying with fuzz and duplicating themselves while mass rebuilding the stack from git | 02:41 |
|---|---|---|
| RAOF | Mmm, delicious. | 02:47 |
| RAOF | Sarvatt: Have you asked the kernel team for a build of nouveau/linux-2.6? Since they're already doing drm-next and drm-intel-next, it should be easy for them to do one for nouveau, too. | 02:57 |
| Sarvatt | <Sarvatt> if by kernel team you mean apw who I think is the only one that does those builds, then nope because he's been so busy. i dont think they are fully automated and are going through a transition due to the karmic-lucid config stuff because they dont build a lot of days now | 03:18 |
| Sarvatt | <Sarvatt> the drm-next daily kernel isn't that far behind usually | 03:18 |
| Sarvatt | this xserver 1.8 patch removal hook is getting nuts :D | 04:23 |
| RAOF | Hm. I wonder what http://lists.freedesktop.org/archives/intel-gfx/2010-April/006611.html fixes? | 04:45 |
| RAOF | That might be yet another part of the 855 problems. | 04:45 |
| Q-FUNK | re | 06:21 |
| === raof is now known as RAOF | ||
| RAOF | Man, I hate bugs with logs that show every sign of being perfectly normal. | 08:00 |
| Sarvatt | yeeep | 08:01 |
| Sarvatt | especially when theres no signs of being anything wrong, then you ask them to reproduce and reattach all of the logs and they run apport-collect using a totally different driver with no problems either :) | 08:04 |
| Sarvatt | and you're subscribed to it so you get spammed with 20-30 emails from the apport-collects | 08:04 |
| RAOF | It looks like disabling DRI has had unexpected side-effects. | 08:04 |
| RAOF | I should add an evolution filter for apport-collects. | 08:05 |
| RAOF | Oh, no. I have a *horrible* feeling that disabling KMS might be partially responsible for this. | 08:07 |
| Sarvatt | link? | 08:07 |
| RAOF | Bug #566103 is one, bug #566133 is another. | 08:08 |
| ubottu | Launchpad bug 566103 in xserver-xorg-video-intel "blank screen and complete lockup when X starts on Intel 855GM Chipset " [Undecided,New] https://launchpad.net/bugs/566103 | 08:08 |
| ubottu | Launchpad bug 566133 in xserver-xorg-video-intel "xserver fails to start after splash, screens turns black, no response, hard reboot needed" [Undecided,New] https://launchpad.net/bugs/566133 | 08:08 |
| RAOF | You know how in the pre-.33 drm days vga16fb was dependably breaking nouveau? And it wasn't breaking intel, or ati, because they got their drmfb loaded first? | 08:08 |
| RAOF | Possibly that only matters with kms, but I remember playing with this intel laptop making vga16fb load before i915 and got slightly strange behaviour… | 08:10 |
| Sarvatt | so its got the xrandr info attached, but didn't attach any xorg logs.. | 08:11 |
| RAOF | bug #566133 has an xorg log. | 08:13 |
| ubottu | Launchpad bug 566133 in xserver-xorg-video-intel "xserver fails to start after splash, screens turns black, no response, hard reboot needed" [Undecided,Incomplete] https://launchpad.net/bugs/566133 | 08:13 |
| RAOF | A curiously gzipped log, but a log nonetheless. | 08:13 |
| Sarvatt | did -20 have the 8xx blacklist? | 08:16 |
| Sarvatt | (WW) intel(0): i845 or i855 chip detected. Disabling DRI to prevent system instability. | 08:16 |
| Sarvatt | (**) intel(0): Kernel mode setting active, disabling FBC. | 08:16 |
| Sarvatt | ... | 08:16 |
| RAOF | Hah. More fool me. | 08:16 |
| RAOF | Yeah. I *read* that! | 08:16 |
| Sarvatt | ah ok [ 13.070621] fb0: inteldrmfb frame buffer device | 08:16 |
| RAOF | It'd be nice if we could make it clear that you should run apport-collect *after* experiencing a bug, not after having worked-around it. | 08:22 |
| seb128 | hey there | 11:18 |
| seb128 | where should bugs about login screen not taking keyboard input in vmware be reassigned? | 11:18 |
| Sarvatt | depends, can ya link one of the bugs so I can take a look? /var/log/gdm/:0-greeter.log (or /etc/default/console-setup contents) from an affected system would be useful to have, I've seen reports of the vmware autoinstall stuff screwing up the xkb layout settings causing that exact problem in lucid | 11:47 |
| seb128 | Sarvatt, bug #565858 | 11:49 |
| ubottu | Launchpad bug 565858 in xorg-server "login screen does not accept keyboard input on vmware fusion" [Undecided,New] https://launchpad.net/bugs/565858 | 11:49 |
| Sarvatt | go figure 0 logs.. | 11:49 |
| seb128 | bug #565037 | 11:49 |
| ubottu | Launchpad bug 565037 in xorg-server "gdm does not take input on login" [Undecided,New] https://launchpad.net/bugs/565037 | 11:49 |
| Sarvatt | seb128: https://bugs.edge.launchpad.net/ubuntu/+source/console-setup/+bug/548891 | 11:50 |
| ubottu | Launchpad bug 548891 in console-setup "keyboard input broken due to invalid "SKIP" keyboard model" [High,Confirmed] | 11:50 |
| seb128 | Sarvatt, thanks | 11:51 |
| Sarvatt | no worries, i'll note that as the master bug to dupe others to if i come across any and look into it a bit more when I have some free time, thanks for getting me to look :) | 12:05 |
| Sarvatt | got a xserver 1.8 PPA for testing before I merge it all into edgers if anyones interested - https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+packages?field.series_filter=lucid | 12:06 |
| Sarvatt | it requires both that and edgers activated | 12:06 |
| ricotz | Sarvatt, hi, why arent you creating proper tarballs, so like running ./autogen.sh; ./configure --prefix=/usr ? | 12:16 |
| ricotz | and then using "make dist" or "make distcheck" if possible | 12:17 |
| Dr_Jakob | So I have updated bug 545298 with a solution that works for me. | 13:13 |
| ubottu | Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [Undecided,Confirmed] https://launchpad.net/bugs/545298 | 13:13 |
| jcristau | tjaalton: ^^ | 13:15 |
| tjaalton | Dr_Jakob: ok, thanks for finding the root cause | 13:18 |
| === \vish is now known as vish | ||
| Dr_Jakob | tjaalton: I think I found a better fix in the udev rule for vmmouse instead of xorg.conf.d | 14:48 |
| tjaalton | Dr_Jakob: it's ok to match the path, the other driver do it as well | 14:50 |
| tjaalton | and I uploaded it already, waiting in the queue | 14:51 |
| Dr_Jakob | tjaalton: ok thanks for the quick turn around. | 15:36 |
| Dr_Jakob | I did opt for the udev rule instead but I have sent out a patch to xorg-devel, lets see if I get any comments. | 15:37 |
| ara | hello, one user is reporting (lucid, nvidia driver) xorg eating huge amounts of CPU | 15:37 |
| ara | is there anything like that reported already? | 15:37 |
| tseliot | with what flavour of the driver? | 15:38 |
| tjaalton | Dr_Jakob: heh, yeah that's basically the same | 15:38 |
| tjaalton | same result | 15:38 |
| Dr_Jakob | yeah | 15:38 |
| ara | let me ask him | 15:39 |
| ara | nvidia-current | 15:40 |
| tseliot | ara: no, I don't think there are any bug reports about that | 15:42 |
| ara | how is the best way to debug it? | 15:42 |
| ara | tseliot, do you mind if I tell the user to join here to better explain the issue? | 15:42 |
| tseliot | ara: some logs would be fine, to begin with | 15:43 |
| tseliot | yes, sure | 15:43 |
| ara | tseliot, thanks | 15:45 |
| tseliot | np | 15:45 |
| bigjools | hi ara | 15:46 |
| ara | hey bigjools, tseliot, who is responsible of packaging the nvidia driver, will help you debugging your issue | 15:47 |
| bigjools | great# | 15:47 |
| ara | tseliot, bigjools is part of the launchpad team (soyuz?) | 15:47 |
| tseliot | bigjools: can you put the following files on pastebin, please? | 15:47 |
| bigjools | yeah Soyuz | 15:47 |
| tseliot | ara: let me check | 15:47 |
| tseliot | ara: no, I'm not | 15:48 |
| ara | tseliot, no, I was introducing you to bigjools :-) | 15:49 |
| tseliot | bigjools: /var/log/Xorg.0.log and the output of dmesg | 15:49 |
| tseliot | hehe, sorry, I misread what you wrote | 15:49 |
| tseliot | too much multitasking here ;) | 15:49 |
| * bigjools pastes | 15:49 | |
| bigjools | http://pastebin.ubuntu.com/418640/ and http://pastebin.ubuntu.com/418641/ | 15:50 |
| bigjools | also, every time I boot I get the "X won't start" dialog and have to select the option to reconfigure the Xorg.conf | 15:52 |
| * tseliot has a look at the logs | 15:56 | |
| tseliot | bigjools: can you reproduce the problem on boot and archive the logs from failsafe X, please? | 15:58 |
| bigjools | tseliot: sure thing - I might reboot now as this desktop is getting unusable, do you need any more logs or anything before I do that? | 15:59 |
| tseliot | bigjools: nothing else, thanks | 15:59 |
| bigjools | ok, brb | 16:02 |
| bigjools | tseliot: ha, the archive logs/configs option told me it had archived them in $backup_location or something like that...! | 16:10 |
| bigjools | I viewed the log, it said the Xserver was already running... weird | 16:10 |
| tseliot | bigjools: look in either your home directory or in /var/log and you should file an archive which has "failsafe" in its name | 16:11 |
| bigjools | tseliot: right, got them | 16:12 |
| tseliot | bigjools: ok, please upload the archive somewhere | 16:13 |
| bigjools | tseliot: http://people.canonical.com/~ed/failsafeX-backup-100419160532.tar | 16:16 |
| tseliot | bigjools: can you boot without the "splash" parameter, please? | 16:21 |
| tseliot | (you can do it in the grub menu before booting) | 16:21 |
| bigjools | tseliot: ok, gimme 10 | 16:21 |
| bigjools | tseliot: right, removing splash made it boot fine | 16:28 |
| tseliot | bigjools: some weird interaction with plymouth, perhaps? Maybe try asking Keybuk in #ubuntu-devel (show him the :0.log file from the archive) | 16:30 |
| bigjools | will do, thanks | 16:30 |
| tseliot | np | 16:31 |
| bigjools | any thoughts on the slowness? | 16:31 |
| tseliot | I can't see any obvious problem in the logs. Please file a separate report about that and I'll subscribe upstream so that they can investigate the issue | 16:32 |
| bigjools | tseliot: against which package should I file the bug? | 16:43 |
| bigjools | well, I guess I can just use ubuntu-bug | 16:44 |
| bigjools | well if it didn't start asking about sound stuff after I selected the display option :/ | 16:45 |
| tseliot | bigjools: try plymouth. If it's the wrong package we can reassign the bug | 16:47 |
| bigjools | copy | 16:47 |
| Sarvatt | eww, logs look funky now - http://pastebin.com/9iNWREvC | 17:47 |
| sithlord48 | hi can someone help me i upgraded to lucid and can't install new video drivers for ati card keep getting a set FORCE_ATI_UNINSTALL enviromental var to force removal | 18:24 |
| === Sinnerman is now known as Cobalt | ||
| umarux | Is there a way to improve the graphical performance of a Radeon x1600 under Lucid? I get very poor FPS when watching movies and such. | 19:02 |
| umarux | The default drivers are very slow | 19:02 |
| Sarvatt | umarux: boot with nomodeset added to grub | 19:10 |
| Sarvatt | won't be pretty but it's significantly faster | 19:11 |
| umarux | What will it do? | 19:11 |
| Sarvatt | you wont notice the difference between KMS and UMS speeds on intel because intel has UXA and DRI2 under UMS, using DRI1+EXA was always alot faster | 19:12 |
| umarux | I'll give it a shot, thanks | 19:13 |
| Sarvatt | it disables kernel mode setting, mostly the only thing you'd notice is suspend/resume speed, faster VT switching and a prettier boot process | 19:13 |
| umarux | oh ok | 19:13 |
| Sarvatt | thats stuff you'd notice losing if you switched to UMS with nomodeset I mean | 19:14 |
| umarux | Sarvatt: Wow, thanks for the nomodeset tip, my FPS have a huge jump, I can even watch 720p video now without a problem and before i couldn't even watch 480 | 21:10 |
| umarux | Now to figure out my final problem. Why lucid doesn't recognize my laptops support for changing the screen brightness, doesn't even show up like it should in /proc/video/ | 21:12 |
| Sarvatt | nothing I do will turn off vsync on this latest git everything + xserver 1.8 branch.. | 22:08 |
| === skimj1 is now known as skimj | ||
| Sarvatt | and if i change the swap intervals in driconf to anything but never sync I get 45 fps instead of a constant 60, argh | 22:10 |
| Sarvatt | guess thats a change some people might like compared to not having any sync to vblank support on 1.7.x :D | 22:13 |
| tormod | Sarvatt, woohoo running your xserver 1.8 now | 22:19 |
| tormod | kind of tricky though that the 1.7 -ati in xorg-edgers has a higher version than the 1.8 in xorg-testing.... | 22:21 |
| Sarvatt | tormod: oh did I upload -ati to edgers by mistake? whoops! | 22:22 |
| tormod | no, I think it is ~/+ issue :) | 22:22 |
| Sarvatt | ah crap, sorry | 22:23 |
| tormod | was kind of bummed here, b/c I cannot configure wireless on the console, iwconfig seems to mess up | 22:23 |
| Sarvatt | tormod: almost ready to copy over ya think? it just needs vmmouse and wacom changes (the input changes are a pain to do manually atm) a metapackage and a quick upload of all the video drivers | 22:24 |
| tormod | works fine here | 22:24 |
| Sarvatt | that changelog is a monster | 22:25 |
| Sarvatt | its down to 6 patches \o/ | 22:25 |
| Sarvatt | * + debian/xdmx-tools.install: handle xdmx binary being renamed Xdmx | 22:26 |
| Sarvatt | * + debian/xserver-xorg-core.install: install evdev xorg.conf.d snippet built with the server in /usr/share/X11/xorg.conf.d/. | 22:26 |
| tormod | maybe instead of hooks we should create a xorg-edgers branch on git.d.o? | 22:26 |
| Sarvatt | those are the only manual changes | 22:26 |
| tormod | then just use -d origin/xorg-edgers | 22:27 |
| Sarvatt | yeah I was going to ask if that would be a possibilty, maybe having the changes in git would help when its eventually merged | 22:27 |
| Sarvatt | but I wouldn't want to spam the debian-x lists :) | 22:28 |
| jcristau | Sarvatt: xdmx got renamed dmxinfo or so, not Xdmx. Xdmx is the server. | 22:28 |
| tormod | just ask around here :) | 22:28 |
| jcristau | and we can disable the commit hook for edgers, or send it somewhere else, if needed. | 22:29 |
| tormod | Sarvatt, oh you mean the commits go there? | 22:29 |
| Sarvatt | ohh ok thats makes more sense | 22:29 |
| tormod | jcristau, sounds good | 22:29 |
| Sarvatt | libdrm mesa and xorg-server are the biggies, everything else is easily synced with experimental/unstable/ubuntu. libdrm especially because of the frequent symbol changes, thats the | 22:33 |
| Sarvatt | biggiest pain to keep sed hooks up to date :) | 22:33 |
| tormod | Sarvatt, what do think about the ever-increasing gem object bytes? is bug 565981 a real bug or red herring? | 22:34 |
| ubottu | Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981 | 22:34 |
| Sarvatt | I get it too on intel, no idea at all whats causing it | 22:34 |
| Sarvatt | somethings leaking objects for sure though, i got up to 2.5k once and wrapped back to a negative number of gem objects. if i use compiz with bo reuse enabled on intel right now with chrome I get about 2 hours before my system is stuck swapping forever and unresponsive with 1.5GB memory and no swap | 22:38 |
| Sarvatt | but disabling BO reuse in driconf and not using compiz stops it from happening.. | 22:38 |
| tormod | so it seems to be quite serious, and touching many people | 22:44 |
| Sarvatt | 9897 objects | 22:46 |
| Sarvatt | 1234710528 object bytes | 22:46 |
| Sarvatt | hah | 22:46 |
| * Sarvatt found an old saved one | 22:47 | |
| tormod | wow, I usually have only some hundred objects, but maybe I reboot too often | 22:47 |
| Sarvatt | thats on a 965, i cant get 945 over 2.5k before its totally dead | 22:48 |
| bryceh | is this leak on lucid or just xorg-edgers? | 22:49 |
| bryceh | I saw a bug report earlier complaining about leaks, but it was not clear what the issue was | 22:49 |
| tormod | it's in lucid AFAIU, and also with edgers and 2.6.34 FWIW | 22:50 |
| bryceh | hrm | 22:50 |
| Sarvatt | its in lucid, I had this problem with 2.9.1 as well | 22:50 |
| Sarvatt | switched back to edgers awhile back just to see if it was any different :) | 22:50 |
| tormod | I think the bug reports are spread out, many apps get the blame | 22:51 |
| tormod | maybe search lp for OOM reports | 22:52 |
| bryceh | do we know precisely which package and/or version causes it? | 22:52 |
| tormod | bryceh, then it wouldn't have been so bad :) | 22:52 |
| tormod | it's not a kernel leak, since memory gets back after restarting Xorg | 22:53 |
| tormod | but you can not see Xorg or any app growing. could be Xorg holding references to the objects | 22:54 |
| Sarvatt | tormod: check out upstream drivers/gpu/drm/drm_gem.c and see if theres any changes :) | 22:54 |
| Sarvatt | since its not just intel | 22:54 |
| jcristau | it's only with compiz running? | 22:56 |
| jcristau | (or any gl compositor?) | 22:56 |
| Sarvatt | i haven't tried poking it to figure out more yet, compiz + bo reuse + texture tiling + flash seems to be the main ingredients and its fine with metacity (no compositing) and bo reuse/texture tiling disabled | 22:57 |
| * Sarvatt reboots into mutter | 22:57 | |
| tormod | I turned off compiz now and I can not reproduce with my eog case | 22:58 |
| jcristau | and does it come back down when you run metacity --replace, or killing X is needed? | 22:59 |
| Sarvatt | tormod: whatever you do don't grab the compiz source and look at the patches we have to it :) | 22:59 |
| jcristau | just to get some data points... | 22:59 |
| tormod | hmm we used to blame compiz for everything before, but nowadays it's upstart :) | 22:59 |
| jcristau | tormod: when you can't blame upstart, blame plymouth | 22:59 |
| jcristau | ;) | 22:59 |
| tormod | jcristau, killing X is needed | 22:59 |
| bryceh | heh, was just gonna say | 22:59 |
| bryceh | plymouth is the new upstart | 23:00 |
| Sarvatt | metacity --replace still has the problem yeah | 23:00 |
| Sarvatt | restarting X was needed here too after the driconf changes | 23:00 |
| tormod | stopping compiz dropped the number of objects a lot, but I guess that is normal? | 23:01 |
| tormod | bytes count did not drop much | 23:01 |
| Sarvatt | it didn't here - 1793 objects 703676416 object bytes | 23:01 |
| Sarvatt | 1788 objects 703811584 object bytes -- before | 23:02 |
| jcristau | bleh | 23:02 |
| Sarvatt | the number doesn't really go down, it'll go down 20 or so then go up 50 and back down 20 eventually (just rough numbers) | 23:03 |
| Sarvatt | 3 hours uptime here :D | 23:04 |
| jcristau | with no compiz i have ~800 objects, 20MB | 23:06 |
| jcristau | otoh with compiz all windows are redirected so you get more offscreen pixmaps | 23:07 |
| jcristau | but, probably not by that much.. | 23:07 |
| Sarvatt | 965? | 23:09 |
| jcristau | gm45 | 23:10 |
| Sarvatt | tormod: hold off upgrading from xorg-testing, i'm uploading a compiz with no patches to it since it needs an insane amount of build deps :) | 23:11 |
| tormod | Sarvatt, you'll be pushing compiz snapshots now? | 23:13 |
| Sarvatt | no I just want to test without all of these patches from the dapper days to fix the blob that are probably not needed :) | 23:14 |
| tormod | sounds like a good idea | 23:16 |
| tormod | how does one debug the gem objects? for instance, cat /sys/kernel/debug/dri/0/clients gives me the xorg pid + another process which does not exist | 23:19 |
| tormod | that was probably the compiz I stopped, a new compiz shows up in clients | 23:22 |
| jcristau | heh the ioctls number for X is, err, big. :) | 23:23 |
| tormod | jcristau, some hundreds per second | 23:24 |
| tormod | and compiz does some tens per second | 23:25 |
| jcristau | i guess at least one per frame :) | 23:27 |
| === raof is now known as RAOF | ||
| Sarvatt | tormod: using he plymouth drm renderer? | 23:37 |
| tormod | Sarvatt, no not yet | 23:38 |
| tormod | lp lost its CSS now? | 23:40 |
| tormod | nice 90's look, but I can not find any "send comment" button | 23:41 |
| RAOF | When it does that, I hit refresh and it fixes it. | 23:41 |
| tormod | nvm there is a add comment or attachment link under the useless comment field | 23:42 |
| bryceh | it's not fixing it now | 23:42 |
| bryceh | RAOF, cjwatson sees the problem too... edge seems to have busted css | 23:42 |
| RAOF | :( | 23:42 |
| bryceh | at least launchpad is still up | 23:43 |
| bryceh | (for now) | 23:43 |
| * bryceh distracts RAOF with a volcano | 23:43 | |
| RAOF | It's a *long* way away; even something as shiny as a volcano needs to be a little closer for distraction :) | 23:44 |
| jcristau | it's far away, but it still prevents me from flying tomorrow. | 23:44 |
| * jcristau just got a cancellation email | 23:45 | |
| RAOF | bryceh: What's your feeling about i855 & i845? It seems that dri-disablement hasn't helped (enough?), and strangely seems to have regressed things like resume-from-suspend for some people on i855. | 23:45 |
| bryceh | RAOF, apparently there's a larger volcano that this little guy can fire up, let's see if that one makes a better distraction for you | 23:46 |
| bryceh | RAOF, yeah I'm wondering about that too | 23:46 |
| jcristau | it seems there's a chance you can get 855 fixed in .1; no progress on 845 it seems. | 23:47 |
| RAOF | bryceh: That one *would* be cool. Volcanos under glaciers make for fun! | 23:47 |
| bryceh | RAOF, it would be helpful if the DRI disablement could be opted around with an xorg.conf setting or some such, so we can see if by re-enabling it it makes the issues go away | 23:47 |
| bryceh | RAOF, I'm not convinced that disabling KMS caused the issues | 23:47 |
| bryceh | I'd like to see more data to prove that | 23:48 |
| bryceh | also changing the kernel is hard | 23:48 |
| RAOF | jcristau: Right. That big intel-agp patch seems to be landing in drm-intel-next. | 23:48 |
| bryceh | RAOF, maybe set up a PPA with the DRI change reverted, so we can get data on if just re-enabling it resolves the issues? That could be a simpler fix | 23:48 |
| jcristau | yeah it's likely to end up in .35 first, and then get backported, afaict | 23:48 |
| bryceh | one thing I'm wondering is if we've been chasing a corner case | 23:49 |
| RAOF | jcristau: It looks a tiny bit scary; it refactors code common to all the intel cards, right? | 23:49 |
| bryceh | as in, if 90% of 8xx was just working, the remaining 10% might have been especially active in the bug reports, and we assumed they represented a tip of the iceberg, when they were really just a small but vocal minority | 23:49 |
| bryceh | and so by addressing their issue we could have busted stuff for some (small?) portion of the other 90% | 23:50 |
| RAOF | bryceh: Possibly; there's certainly been “my i855 was working wonderfully, and now it's terribly slow and compiz doesn't work” bugs, and (at least one) thread on ubuntuforums. | 23:50 |
| bryceh | so it may be that there is simply no configuration which will work 100% of the time with what we've got | 23:50 |
| jcristau | RAOF: i assume there's a way to just change stuff for 8xx when backporting. danvet's current series looks big and scary, yeah. | 23:50 |
| bryceh | this makes me think that we just make all the various permutations user-settable, list it as a known issue in the release notes, and document well how to configure things, and wish users the best. | 23:51 |
| jcristau | but i assume he moved stuff around in the process of understanding the code and the bug.. | 23:51 |
| bryceh | kind of late in the release to do substantial fixing | 23:51 |
| Sarvatt | someone actually said 855 worked well before? i dont believe it! :D | 23:52 |
| RAOF | bryceh: That seems like a good idea; default to vesa, allow fbdev by i915.modeset=1, allow 3D by an xorg.conf | 23:52 |
| jcristau | Sarvatt: probably not since gem or so.. | 23:52 |
| RAOF | jcristau: Yeah. It looked to me like backporting the patch in such a way as to make it only apply to 8xx would mean taking the idea and rewriting it. | 23:53 |
| jcristau | if i were you i'd just release note 855 and 845, and punt to .1 :) | 23:53 |
| bryceh | Sarvatt, yeah our feedback mechanisms with X are piss poor, as we really only hear when things are broken | 23:54 |
| bryceh | so gets really hard to judge when an issue is serious or just one guy with bad hardware | 23:54 |
| jcristau | srsly. http://cgit.freedesktop.org/~danvet/drm/commit/?h=stuff/i8xx_cache_coherency_for_oga&id=925114122c4bc9864951478e62169e9f34f9d41c "write random stuff, and wait until it sticks" | 23:54 |
| RAOF | Yes. | 23:55 |
| jcristau | this hardware is messed up :) | 23:55 |
| RAOF | Yes :) | 23:55 |
| jcristau | from the tested-by list, it seems he's rounded up most of the remaining 855 owners ;) | 23:55 |
| bryceh | heh, "probabilistic" | 23:56 |
| bryceh | "We use a monte carlo approach to getting graphics to your screen" | 23:56 |
| jcristau | "if it doesn't work, blame the volcano" | 23:56 |
| bryceh | sounds good to me | 23:57 |
| Sarvatt | 2298 objects 970698752 object bytes whee | 23:59 |
| bryceh | RAOF, what do you think about updating that DRI patch to use an xorg.conf settable parameter, and then just listing this as a known issue with the workarounds documented? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!