| RAOF | My r700 likes compiz just fine. | 00:00 |
|---|---|---|
| RAOF | And, with mesa 7.9, is pretty happy with Unity. | 00:00 |
| RAOF | It doesn't run Civ 4 under wine, though. | 00:00 |
| ajmitch | mobility radeon HD 4850, I'm wondering how well it'll go with games instead of using fglrx :) | 00:00 |
| ajmitch | namely WoW under wine, of course | 00:00 |
| RAOF | :P | 00:01 |
| ajmitch | civ iv looks a bit funny even with fglrx | 00:01 |
| RAOF | I'd give it a go; it's possible that the driver doesn't implement something that wine wants, though. | 00:01 |
| ajmitch | quite probably :) | 00:01 |
| ajmitch | I geuss we should be hoping for fglrx to still work by release | 00:02 |
| RAOF | It works now? | 00:02 |
| ajmitch | I mean it works in lucid, having it break for people upgrading could be bad | 00:03 |
| RAOF | Ah. Yeah. | 00:03 |
| RAOF | apw: Is that wedge in mutex_lock_slowpath? There seems to be a deadlock somewhere you can hit, and hit it much more frequently with two monitors. | 00:05 |
| ScottK | RAOF: Thanks. | 00:27 |
| === yofel_ is now known as yofel | ||
| JanC | I'll try my Radeon HD 4350 one of the next days... ☺ | 01:09 |
| apw | RAOF yes its trying to get the dev struct_mutex, from the minimal analysis I did I cannot find anyone holding it and doing anything | 08:34 |
| apw | that one is going to bite us hard after release, do you have a bug open on it? | 08:35 |
| RAOF | apw: I think this is it: https://bugs.freedesktop.org/show_bug.cgi?id=28805 | 10:35 |
| ubot4 | Freedesktop bug 28805 in Driver/intel "[Arrandale] Intermittent freezes - missed interrupt?" [Normal,Resolved: fixed] | 10:35 |
| RAOF | apw: Launchpad bug #568138 | 10:36 |
| ubot4 | Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 11) (dups: 1) (heat: 60)" [Medium,Confirmed] https://launchpad.net/bugs/568138 | 10:36 |
| apw | RAOF, interesting, then its not arrandale specific | 10:38 |
| RAOF | apw: Yeah, I think the bug is mis-titled. | 10:38 |
| apw | mine is certainly something older ... thanks for the ptr | 10:38 |
| RAOF | Hm. I need to re-check my upstream bugmail filtering; I should have noticed that getting marked as resolved. | 10:39 |
| RAOF | I could reproduce it relatively frequently (~1/day) when I plugged in my second monitor. | 10:40 |
| RAOF | I should try the 2.6.36-rc3 kernel to see if it resolves it. | 10:40 |
| seb128 | hey there | 10:44 |
| seb128 | is there any known bug about external monitor on dock stations not activating since recently? | 10:44 |
| seb128 | on intel card | 10:44 |
| seb128 | on a dell latitude serie | 10:44 |
| seb128 | what would be buggy? xorg? intel driver? | 10:44 |
| seb128 | it started a few days ago and it doesn't seem to be the linux version in use | 10:45 |
| RAOF | It's likely to be either the intel driver or the kernel; most likely the kernel. | 10:52 |
| RAOF | We haven't had an -intel upload for a while, so I'd guess at kernel. | 10:55 |
| apw | RAOF, i can reproduce it pretty much once a day as well with just single screen | 11:12 |
| apw | RAOF, and thats with maverick kernel on lucid userspace | 11:13 |
| RAOF | apw: Ah, well. That might be a different bug to mine, then. | 11:30 |
| RAOF | apw: Or it could be exactly the same bug, and it just gets triggered much more infrequently on gm45 | 11:30 |
| apw | RAOF, hard to say isn't it, sounds very similar | 11:34 |
| RAOF | Yeah. | 11:35 |
| RAOF | The kernel PPA has a build of 2.6.36-rc3, right? | 11:35 |
| apw | RAOF, should do yes | 11:36 |
| apw | RAOF, it does indeed | 11:37 |
| RAOF | Man, my arms are so much better after pushups this week than last week. | 11:37 |
| RAOF | But still enervated. | 11:38 |
| RAOF | tseliot: I've investigated the xserver-xorg-video-ati diff. That's the removal of a copy of the XRandR modes code that was added to the -ati in order to build properly against xserver 1.2, but it actually has never been built (as it's conditional on XRandR 1.2 support, which xserver 1.2 didn't have). | 12:09 |
| RAOF | tseliot: It's in upstream git; I haven't found where we've picked up that commit, but it's entirely benign. | 12:14 |
| tseliot | RAOF: can you add it to the changelog, please? | 12:34 |
| RAOF | It wasn't introduced in that change; I can hunt down when it _was_ introduced if you like. | 12:35 |
| RAOF | git is being remarkably unhelpful at working this out. | 12:37 |
| tseliot | RAOF: it would suffice to mention the change in the changelog | 12:38 |
| tseliot | a one line explanation would be fine | 12:38 |
| tseliot | for example what you wrote here on irc | 12:39 |
| ricotz | tseliot, hello, do you still expierencing the docky freeze on application starts? | 12:43 |
| tseliot | ricotz: yes, shall I update my system? | 12:44 |
| ricotz | tseliot, are you using 2.0.6-2 now? | 12:44 |
| RAOF | tseliot: Pushed to pkg-xorg git. | 12:44 |
| tseliot | ricotz: no, I'm using 2.0.5-1 | 12:45 |
| tseliot | RAOF: ok, thanks, I'll have a look at it and upload your changes | 12:46 |
| RAOF | Thanks muchly. | 12:46 |
| ricotz | tseliot, the newer version should be available, i didnt ran into this bug myself, and i thought it might be some glib problem | 12:47 |
| tseliot | ricotz: ok, let me check | 12:52 |
| tseliot | ricotz: yes, I can still reproduce the problem with 2.0.6-2. Let me update the whole system and see if anything changes | 12:56 |
| ricotz | tseliot, this must be related to some dependency and it is only affecting maverick | 12:58 |
| tseliot | ricotz: yes and I recall an update of glib just before the breakage | 13:00 |
| ricotz | tseliot, you are now on glib2.0 2.25.15? | 13:01 |
| tseliot | ricotz: 2.25.14-1ubuntu2 but I'm about to upgrade to 2.25.15-0ubuntu2 | 13:02 |
| ricotz | ok | 13:02 |
| tseliot | I'll let you know how it goes | 13:03 |
| ricotz | tseliot, thanks | 13:03 |
| tseliot | ricotz: same problem with the new glib | 13:36 |
| tseliot | let me know if you need further information | 13:36 |
| tseliot | the last few comments are interesting though: https://bugs.launchpad.net/ubuntu/+source/docky/+bug/628372 | 13:39 |
| ubot4 | Launchpad bug 628372 in docky (Ubuntu) (and 1 other project) "Docky freezes when launching application (affects: 10) (dups: 1) (heat: 52)" [Undecided,Confirmed] | 13:39 |
| tseliot | ricotz: if you tell me how to try the latest code, I'll tests it here | 13:41 |
| tseliot | s/tests/test/ | 13:41 |
| ricotz | tseliot, you can try the trunk version with this ppa https://launchpad.net/~docky-core/+archive/ppa | 13:43 |
| tseliot | ricotz: shall I update gio-sharp too? | 13:44 |
| ricotz | tseliot, if should be the same as maverick ships now | 13:45 |
| tseliot | ah, right | 13:45 |
| tseliot | ricotz: same problem again. Maybe something in the handler of the ButtonReleaseEvent triggers a bug somewhere e.g. in gtk# ? | 13:52 |
| ricotz | tseliot, ok, this really needs some more investigation, thanks for your time, too bad i can't reproduce this | 13:57 |
| tseliot | ricotz: np | 13:58 |
| Sarvatt | hmm I can't reproduce that docky problem on nouveau nvidia or intel on maverick | 14:06 |
| Sarvatt | maybe I need to enable all those plugins and helpers | 14:06 |
| ricotz | i am suspecting nvidia-blob, but didnt want to say it | 14:06 |
| tseliot | ricotz: wait a second, I purged the packages from the PPA, ran docky in debug mode and I can't reproduce the problem any more now. Maybe some cached content (or configuration file in /etc ) was removed | 14:09 |
| Sarvatt | well I didn't test the blob very well, the machine i tested it on can't use the blob because the board is failing and graphics are corrupted all over the place but i didn't see any freeze through all of the corruption | 14:09 |
| tseliot | oh, and I'm using radeon | 14:09 |
| Sarvatt | oh just read the bug | 14:12 |
| Sarvatt | i'm using 2.1.0~bzr1623-0ubuntu1~10.10~dockycore1 | 14:12 |
| Sarvatt | Revision 1622 fixed it on kernel version 2.6.35.19. Thanks! -- Well then 1624 will break it again because I reverted 1622. | 14:12 |
| ricotz | tseliot, could you add a comment to the bug for this purge? | 14:12 |
| ricotz | Sarvatt, yeah someone got motivated doing things | 14:13 |
| tseliot | ricotz: sure | 14:15 |
| Sarvatt | ricotz: wait, so its fixed again in 1625? lol | 14:16 |
| Sarvatt | fixed in 1622, reverted in 1624, revert reverted in 1625? | 14:16 |
| tseliot | it's fixed here with: | 14:17 |
| tseliot | [Info 15:06:51.480] Docky version: 2.0.6 Release | 14:17 |
| tseliot | [Info 15:06:51.486] Kernel version: 2.6.35.20 | 14:17 |
| tseliot | [Info 15:06:51.486] CLR version: 2.0.50727.1433 | 14:17 |
| tseliot | maybe try purging docky? | 14:17 |
| Sarvatt | oh guess it's not related to that then | 14:17 |
| ricotz | tseliot, i cant imaging what a purge could cause to our config, it is all saved in the user dirs, it is pretty weird | 14:19 |
| * tseliot nods | 14:19 | |
| ScottK | Sarvatt: Did you get my ping on intel stuff from over the weekend? | 14:25 |
| Sarvatt | ScottK: I just got up and haven't read the scrollback yet, checking now | 14:26 |
| ScottK | Sarvatt: OK. Thanks. | 14:26 |
| Sarvatt | ScottK: #dri-devel is where all of the mesa developers are and I've never seen a kde dev in there. Is it just intel thats broken or everyone using mesa like it sounds like? It looks like phoronix picked up on the story giving it a lot more exposure and some mesa devs have replied in here - http://www.phoronix.com/forums/showthread.php?t=25907 | 14:38 |
| ScottK | Sarvatt: It's hard for me to tell what's accurate and what's complete crack from that thread. I know the stuff about trolltech controlling KDE development is complete crap. | 14:40 |
| Sarvatt | just the posts from marek and airlied and bridgman basically | 14:41 |
| ScottK | Sarvatt: The feeling among the KDE devs is that the Intel people can't be communicated with. I suspect that's not accurate and would like to find a way to fix the social disconnect. | 14:41 |
| ScottK | Reading it again (knowing who to pay attention to) | 14:42 |
| Sarvatt | ScottK: Intel specifically? They are around every day pretty much all of the time in #intel-gfx and #dri-devel | 14:42 |
| ScottK | I'm not saying they are right, just that's the perception. | 14:42 |
| ScottK | As is usual when people are pissed off, I'm sure it's not so bad as that, just it takes some work to bridge the gap. | 14:43 |
| ScottK | Sarvatt: Do any of the right people come to UDS? | 14:45 |
| Dr_Jakob | ScottK: I only know of Jesse Barnes (from intel) going to UDS. | 14:45 |
| Sarvatt | jbarnes has in the past but not recently, perhaps you can speak to RAOF about bringing it up at the XDS coming up soon? | 14:45 |
| Dr_Jakob | So what is the actuall problem? | 14:48 |
| Sarvatt | <ScottK> Sarvatt: What would be the way to communicate the following to Intel developers in a way that would be constructive and useful (re the ongoing kwin mess): | 14:48 |
| Sarvatt | <ScottK> <ScottK> mgraesslin: While I'm waiting for kdebase-workspace to compile, it would help a lot if I could get a list of the capabilities Intel is misreporting (or some idea how to figure it out). Canonical does have people that can talk to Intel if I can tell them what needs to be communicated. | 14:48 |
| Sarvatt | <ScottK> <mgraesslin> the list is rather short: we need framebuffer objects and shaders and in inderict rendering mode the unsupported (impossible) extensions should be removed. That's nothing I can provide as that's something only the driver developers can know | 14:48 |
| Sarvatt | <ScottK> Additionally: | 14:48 |
| Sarvatt | <ScottK> <mgraesslin> ScottK: if they need a reference: https://bugs.kde.org/show_bug.cgi?id=173556#c41 | 14:48 |
| Sarvatt | <ScottK> <mgraesslin> that's how NVIDIA does it | 14:49 |
| ubot4 | KDE bug 173556 in compositing "Shader support not detected on various systems" [Normal,Resolved: fixed] | 14:49 |
| Sarvatt | the impression that I get is that GL compositing in KDE is designed around the nvidia binary drivers and is messed up with mesa because of extensions being reported that only partially work | 14:51 |
| Sarvatt | which is largely based on hardware limitations.. | 14:52 |
| Dr_Jakob | Well and a totaly crap GLSL compiler. | 14:52 |
| Dr_Jakob | Which intel fixed in 7.9 | 14:52 |
| * Sarvatt nods | 14:52 | |
| Dr_Jakob | Heh, that bug you posted is just some guy who can't get direct rendering work :) | 14:55 |
| Dr_Jakob | But yeah, bug reports from people having problems would be nice. | 14:56 |
| * ScottK has several systems with problems. | 14:56 | |
| ScottK | FWIW, mgraesslin was trying yesterday (and failing, AFAIK) to get ATI working. | 14:56 |
| ScottK | The one Intel system he has access to seems to actually work. | 14:57 |
| Dr_Jakob | ATI prop or ATI mesa? | 14:57 |
| ScottK | IIRC mesa. | 14:57 |
| Dr_Jakob | driver? | 14:57 |
| ScottK | Dunni | 14:57 |
| Dr_Jakob | ok | 14:57 |
| ScottK | Dunno | 14:57 |
| Sarvatt | ScottK: maybe you can suggest to him to just make it so blur/lanczos are never used with mesa by default so a huge blacklist doesn't need to be maintained? | 14:58 |
| ScottK | Having read the thread again it seems like a communication issue primarily. | 14:58 |
| Dr_Jakob | 7.9 will hopefully be a really nice release. | 14:58 |
| Sarvatt | yeah I'm hoping there will be a RC release soon so we can try to get it in maverick, putting a git snapshot is sketchy. it's supposed to branch from master this week at least | 14:59 |
| Dr_Jakob | http://www.x.org/wiki/Events/XDS2010/Program | 15:00 |
| Dr_Jakob | Somebody is going to talk about what is there. | 15:00 |
| Dr_Jakob | "Which functions can app developers rely on ?" | 15:01 |
| Sarvatt | oh nice - Which functions can app developers rely on ? | 15:01 |
| Sarvatt | yeah, thanks for the heads up! | 15:01 |
| Sarvatt | RAOF and cnd are going | 15:01 |
| Dr_Jakob | Ok, I'll say hi | 15:01 |
| ScottK | Sarvatt: No blur plus the new mesa isn't too bad. | 15:22 |
| Sarvatt | I dont get that because your 945GME doesn't support GLSL so it shouldn't be trying to use blur anyway | 15:23 |
| Sarvatt | oh ok looks like theres a non GLSL version in there too, I thought I read there wasn't in that blog.. | 15:35 |
| cnd | RAOF, have you had a chance to take a look at my xorg-server and synaptics changes for maverick? | 15:41 |
| Sarvatt | ScottK: can you try new mesa, install driconf, and disable the "Enable limited ARB_fragment_shader support on 915/945" option and see if blur works? | 15:50 |
| ScottK | Sure | 15:51 |
| Sarvatt | actually you can just put this as ~/.drirc and restart if driconf pulls in too much gtk stuff - http://sarvatt.com/downloads/drirc.txt | 15:56 |
| ScottK | First I have to purge the patched kwin. | 15:57 |
| ScottK | It won't let me activate blur. | 15:57 |
| Sarvatt | it should switch to the GL_ARB_fragment_program blur implementation with that and that might actually work, 7.9 enabled that ARB_fragment_shader option by default which was disabled on 7.8.x and it looks like that's the extension it checks to use the GLSL shader variant instead | 16:00 |
| ScottK | I see. | 16:01 |
| Sarvatt | I don't know enough about this to know whats wrong with the actual shader it compiles if that doesn't work | 16:04 |
| ScottK | Sarvatt: Odd result. Started with effects enabled (inclulding blur). | 16:14 |
| Sarvatt | any problems? | 16:15 |
| ScottK | Not so far (on 30 seconds of using) | 16:15 |
| Sarvatt | so 7.9 is better but that option was making it bad :) | 16:16 |
| Sarvatt | i'm not sure if you can just use fragment_shader=0 in the env when launching kwin to fix that, hmm | 16:16 |
| ScottK | Keeping in mind I know little about this part of the system (and hope to keep it that way), can we suggest a different way to detect to use GLSL that would be more reliable? | 16:20 |
| Sarvatt | ScottK: I'm sorry, got something else that needs my attention ASAP and I need to step away from it for a bit, there are a few ways we can work around it though | 16:24 |
| ScottK | Sarvatt: OK. Let me know when you can chat. | 16:24 |
| === yofel_ is now known as yofel | ||
| Sarvatt | ScottK: sorry, got caught up in some intel sandybridge stuff. I think the first step is to rebase that mesa to the mesa 7.9 branch as soon as it opens any day now and get the output from launching kwin with MESA_GLSL=dump,nopt env variable set to get a good upstreamable bug report. it may already be fixed in git, they've been fixing it crazy amounts since that 0825 snapshot. we can disable that option by default in mesa easily or kwin can export | 17:41 |
| Sarvatt | fragment_shader=false into the env on 915/945 possibly to work around it? | 17:41 |
| ScottK | Sarvatt: I've got roughly 60 seconds until I have to leave for the next 10 hours or so. If the extension isn't working reliably why don't we just globally disable it? | 17:44 |
| ScottK | Let me know when there's an updated package for me to test. | 17:44 |
| Sarvatt | that's a question best asked in #dri-devel, I assume they enable it because it does work for some situations and the benefits outweigh the negatives but I'm not sure :) things like cairo-gl are reliant on that option being enabled or they don't work on this old class of hardware | 17:47 |
| Sarvatt | will do! | 17:47 |
| Sarvatt | i'll patch it to disable by default anyhow | 17:48 |
| Sarvatt | really, convince that guy to discuss this in #dri-devel with the mesa devs somehow if you can instead of just saying its broken, it might be easily fixed but they dont use KDE or something | 17:49 |
| Sarvatt | jcristau: how would you say the results with the legacy 2.12 have been in squeeze? looks quite negative from a quick glance | 18:46 |
| jcristau | Sarvatt: yeah ums is all broken | 18:46 |
| jcristau | my 945 crashes X with a lockup message on startup, and 855 just get hard hangs | 18:47 |
| ScottK | Sarvatt: Kwin upstream doesn't have the right hardware to make it fall over, so it's a little hard for him to report bugs. | 23:44 |
| ScottK | I'd be willing to help, but don't exactly know what to provide. | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!