| NCommander | bryce, how can I get trace messages out of Xorg? | 00:02 |
|---|---|---|
| bryce | NCommander: strace the X binary. However, stracing X rarely produces useful output | 00:06 |
| bryce | I usually end up using some combination of gdb and debugging print messages in key areas | 00:06 |
| NCommander | That will get the TRACE( )informatoion? | 00:06 |
| NCommander | Well, I'm not getting anything out of the fbdev driver | 00:07 |
| NCommander | I can't even tell if its probe function being run | 00:07 |
| bryce | gdb - breakpoints | 00:08 |
| * NCommander grabs his ddebs | 00:08 | |
| bryce | debugging prints use X's internal debug/trace function calls (look around in whatever module you're working on for examples) | 00:08 |
| * NCommander nods | 00:09 | |
| NCommander | Right, but how do I get those trace calls to actually print something, I'm not seeing anything with GDB | 00:09 |
| bryce | they should be printing to your Xorg.0.log; if not then presumably there's some option or flag that needs set | 00:10 |
| NCommander | Oh, thanks | 00:11 |
| * NCommander is an idiot, plain and simple | 00:11 | |
| NCommander | At least I found my issue | 00:11 |
| bryce | heh | 00:11 |
| NCommander | /* For now, just bail out for PROBE_DETECT. */ | 00:12 |
| NCommander | if (flags & PROBE_DETECT) | 00:12 |
| NCommander | return FALSE; | 00:12 |
| NCommander | -_-; | 00:12 |
| NCommander | Why didn't I see that earlier ... | 00:12 |
| bryce | btw fwiw exit error messages print to your /var/log/gdm/ files | 00:12 |
| bryce | (although sometimes I find it useful to shut down gdm and use startx, so the errors show up at the console) | 00:12 |
| NCommander | Debugging Xorg is a whole new ballgame | 00:13 |
| bryce | tell me about it | 00:14 |
| NCommander | bryce, want to wager a guess why probing is disabled by default on the fbdev driver? | 00:18 |
| bryce | unimplemented? | 00:19 |
| NCommander | Well, | 00:22 |
| NCommander | doesn't seem like it | 00:22 |
| NCommander | SCORE! | 00:22 |
| NCommander | I make Xorg segfault! | 00:22 |
| bryce | sometimes I also find it interesting to grab the git tree (cgit.freedesktop.org) and browse the changelog for the specific file... sometimes people include more details in their commit message why bits of code were added | 00:25 |
| NCommander | ah, handy | 00:52 |
| NCommander | I'll try that | 00:52 |
| pwnguin | (10:29:01 PM) Justin Dugger: can you bring up a terminal? | 04:54 |
| pwnguin | (10:29:06 PM) Dave: yes | 04:54 |
| pwnguin | (10:29:27 PM) Justin Dugger: ps aux | grep firefox | 04:54 |
| pwnguin | (10:30:13 PM) Dave: GOD DAMMIT | 04:54 |
| pwnguin | aww | 04:54 |
| pwnguin | crap | 04:54 |
| pwnguin | wrong paste buffer =( | 04:54 |
| pwnguin | jldugger@jldugger:/var/log $ ls -l XFree86.0.log | 04:55 |
| pwnguin | -rw-r--r-- 1 root root 42035 2005-05-08 01:15 XFree86.0.log | 04:55 |
| RAOF | Old school! | 05:11 |
| pwnguin | yea | 05:13 |
| pwnguin | i just upgrade, and upgrade | 05:13 |
| pwnguin | which apparently nobody does | 05:13 |
| pwnguin | because i get random bugs like "oh we switched to adm instead of admin" | 05:14 |
| pwnguin | meanwhile, my poor friend dave has been suffering in 8.04, where compiz seems to be crashing everything | 05:15 |
| pwnguin | wherein he has just admitted to adding things to xorg.conf to fix something | 05:17 |
| bryce | "It was slow, so I turned on some experimental options which sped it up. Btw, it's crashing a lot, do you know what that might be?" | 07:30 |
| RAOF | Heh. | 08:04 |
| tseliot | seb128: I have rewritten my patch but I'm not sure as to whether it solves the problem since I can't reproduce the it: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/314406 | 09:40 |
| ubottu | Ubuntu bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed] | 09:40 |
| tseliot | the patch is in my branch: https://code.edge.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes | 09:41 |
| seb128 | tseliot: I'll give it a try thanks | 09:41 |
| seb128 | tseliot: did you try to use an intrepid config? | 09:41 |
| tseliot | seb128: no, I didn't | 09:41 |
| seb128 | that's what was making it crash | 09:41 |
| tseliot | do you have one | 09:41 |
| tseliot | ? | 09:42 |
| seb128 | there is one on the bug no? | 09:42 |
| seb128 | let me look | 09:42 |
| tseliot | ah, right, it wasn't attached but only copied and pasted | 09:42 |
| seb128 | the xml is in the bug description | 09:42 |
| seb128 | one of the dup has one too | 09:42 |
| tseliot | ok, let me try it | 09:43 |
| tseliot | seb128: when I log in an error dialog tells me that the settings cannot be applied and g-s-d doesn't segfault | 09:52 |
| seb128 | ok good | 09:52 |
| tseliot | seb128: however I was able to reproduce another bug (with my own xml file) which creates an endless loop. I would like to fix this one too | 09:53 |
| seb128 | the one you were discussing on the chan yesterday? | 09:54 |
| tseliot | yep | 09:54 |
| tseliot | I think that when the backlight is changed, the driver reprobes outputs, etc. | 09:55 |
| seb128 | do you want to get that in the same upload? that's also a gnome-desktop change? | 09:55 |
| tseliot | yes, it's in gnome-desktop and it would be nice to have both patches in the same upload | 09:55 |
| seb128 | ok, let me know when you want to get those sponsored | 09:55 |
| seb128 | I'll not upload right now anyway due to the jaunty freeze | 09:56 |
| tseliot | seb128: also I didn't say that my patch fixes bug 314 as I wasn't sure that it could actually fix the bug. I'll correct the changelog too | 09:56 |
| tseliot | ok | 09:56 |
| ubottu | Launchpad bug 314 in baz "Repeated "adding revision" output when archive-mirroring a specific revision" [Medium,Fix released] https://launchpad.net/bugs/314 | 09:56 |
| tseliot | seb128: I can solve the other problem only if I stop both gnome-settings-daemon and gnome-power-manager on my laptop | 10:51 |
| * tseliot tries preventing g-s-d from listening to any kind of randr event | 10:56 | |
| tseliot | no, it doesn't solve the problem | 11:01 |
| tseliot | seb128: I have found a workaround for the 2nd bug | 12:35 |
| tseliot | seb128: the reak problem should be in either X or in the Intel driver though | 12:35 |
| tseliot | s/reak/real | 12:35 |
| seb128 | what is the workaround, wouldn't it better to fix the driver? | 12:36 |
| tseliot | seb128: if I prevent both g-s-d and gnome-power-manager from listening to RandR events I can't reproduce the problem | 12:37 |
| tseliot | yes, it would be better to fix the driver instead. I've never touched Intel code but I'll see what I can do | 12:38 |
| seb128 | ok | 12:38 |
| tjaalton | is this the 'randr-probe bombing' bug, making the session slow? | 12:39 |
| tseliot | yep | 12:39 |
| tjaalton | AIUI it only happens with the updated libxrandr | 12:40 |
| tjaalton | but you already knew that? | 12:40 |
| tseliot | no, I didn't | 12:40 |
| tseliot | ok, I'll have a look at the diff then | 12:40 |
| tjaalton | bug 307306 | 12:41 |
| ubottu | Launchpad bug 307306 in xorg-server "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [Unknown,Confirmed] https://launchpad.net/bugs/307306 | 12:41 |
| * tseliot > lunch | 12:41 | |
| tseliot | thanks | 12:41 |
| tseliot | seb128: I have fixed another issue in my patch so that it doesn't complain that the xml in .gnome2 is missing when no configuration file is available | 14:14 |
| seb128 | tseliot: ah good | 14:14 |
| tseliot | seb128: I'll put it in my branch soon | 14:14 |
| seb128 | cool | 14:14 |
| tseliot | seb128: another thing. Currently if some of the devices described in the xml are not connected you get an error message on login (every time) which says that your settings cannot be applied. Do we really want this? | 14:16 |
| seb128 | I would say we don't no | 14:16 |
| tseliot | ok, in which case do you think we should show the error dialog? | 14:17 |
| tseliot | seb128: shall I simply ignore the error and prevent g-s-d from showing the dialog every time? | 14:23 |
| seb128 | I think that makes sense | 14:25 |
| tseliot | ok | 14:26 |
| NCommander | bryce, w.r.t. to the machine id autoconfiguration mechanism discussed on the list, do you think there will be any issues getting that included in Ubuntu Xorg packages? (I'm working upstream git, but it probably will take some time/effort before the changes would flow from upstream into Ubuntu) | 15:15 |
| tjaalton | NCommander: sure | 15:49 |
| tjaalton | er, I mean it's possible to just add a patch for now | 15:50 |
| tjaalton | when it works | 15:50 |
| NCommander | tjaalton, well, I'm drafting an email to xorg@lists.fd.org | 15:55 |
| NCommander | tjaalton, is there an Ubuntu-X list I can Cc? | 15:55 |
| tjaalton | sure, ubuntu-x@l.u.c | 15:56 |
| NCommander | tjaalton, thanks :-). | 15:57 |
| * NCommander adds this channel to his AJOIN list | 15:57 | |
| NCommander | tjaalton, sent :-) | 16:05 |
| tseliot | seb128: I have updated my patch and the changelog in my branch: https://code.edge.launchpad.net/~albertomilone/gnome-desktop/tseliot-fixes | 16:08 |
| seb128 | tseliot: ok, sponsoring will not be for today they are still working on the alpha but I'll give it a try later and let you know how it works for me | 16:08 |
| tseliot | seb128: ok, great | 16:08 |
| seb128 | tseliot: could you add a comment to the bug to say that you have an updated version? | 16:08 |
| tseliot | sure | 16:08 |
| tseliot | done | 16:10 |
| seb128 | thanks | 16:12 |
| NCommander | tseliot & bryce, I'd like feedback on my load mechanism once you get a few minutes. | 17:56 |
| superm1 | bryce, i'm assuming intel 2.6 will be pulled in for jaunty, correct? If so, i might try to formulate some patches that will get HDMI audio working without jumping to a whole knew alsa version | 19:06 |
| tjaalton | superm1: correct, once it builds against the kernel drm headers | 19:07 |
| superm1 | oh that's still not sorted :( | 19:07 |
| tjaalton | nope | 19:07 |
| superm1 | where's the disconnect right now? | 19:08 |
| tjaalton | it needs some compat stuff in the headers | 19:08 |
| superm1 | so would it make more sense to ship this then in the X package where you guys can control it for most of the release and switch to the kernel one when you know it gets stable then, or is this more of a one off thing that shouldn't be happening very often? | 19:09 |
| tjaalton | well, shouldn't happen anymore after this :) | 19:09 |
| bryce | heya | 19:11 |
| bryce | tjaalton: what's the next step we should do for getting the kernel headers sorted? | 19:12 |
| tjaalton | bryce: filing a bug and assigning it to jbarnes (doing right now) | 19:12 |
| tjaalton | there, freedesktop bug 19591 | 19:14 |
| ubottu | Freedesktop bug 19591 in General "intel driver doesn't build against 2.6.28 drm headers" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19591 | 19:14 |
| bryce | tjaalton: are there any kernel-side changes to be done in ubuntu? | 19:18 |
| tjaalton | bryce: whatever comes from that bug | 19:18 |
| tjaalton | once it's applied upstream, it'll be pretty simple for them to pull | 19:18 |
| tjaalton | them = kernel-team | 19:19 |
| bryce | ok great | 19:19 |
| tjaalton | one fix was pulled in earlier, but it wasn't enough | 19:19 |
| bryce | so.. next question is xserver; how are we with that, anything I can help get sorted out? | 19:20 |
| tjaalton | I've merged it locally.. the only thing that probably should be added is the build-dep on linux-libc-dev, and adding it to xserver-xorg-dev deps | 19:23 |
| tjaalton | *the only thing missing until ok to upload, that is | 19:23 |
| tjaalton | I'll have time tomorrow :) | 19:23 |
| bryce | ok cool | 19:23 |
| bryce | perfect; we're in freeze still today anyway :-) | 19:24 |
| tjaalton | the drm header mess is holding mesa too | 19:24 |
| tjaalton | +back | 19:25 |
| bryce | erk, not fixed in the latest rc? | 19:25 |
| tjaalton | it doesn't build | 19:26 |
| bryce | what's the plan there? | 19:26 |
| tjaalton | the same fix as with -intel | 19:26 |
| tjaalton | the dri driver from mesa doesn't build | 19:27 |
| tjaalton | practically the same error too | 19:27 |
| bryce | ok, do we need a bug in on it too, or will someone (jesse?) address it when intel is addressed? | 19:27 |
| tjaalton | 'drm_i915_flip_t' undeclared | 19:27 |
| tjaalton | once the drm headers are fixed, the dri driver should build | 19:27 |
| tjaalton | so it's the same bug | 19:27 |
| bryce | ok | 19:27 |
| tjaalton | also mentioned there | 19:27 |
| tjaalton | (on the bug) | 19:28 |
| NCommander | bryce, how much do you know about regular autodetection? it *looks* like the FBDevProbe functions are called, so I'm now extremely confused | 20:42 |
| bryce | NCommander: I've tinkered with it only a bit, and more with the PCI stuff than the probe stuff | 20:43 |
| NCommander | Well, I'm just seeing if I'm loosing my mind about how AutoConf works | 20:43 |
| bryce | iow, at this point you may know more than me... but feel free to bounce ideas off me | 20:43 |
| NCommander | Well, it looks like the probe functions ARE called | 20:43 |
| NCommander | (i don't see where, the backtrace says its somewhere in xf86CallDriverProbe from InitOutput) | 20:43 |
| NCommander | Oh wait, this may be one of those **** I'm an idiot things :-) | 20:45 |
| bryce | hehe | 20:45 |
| NCommander | Its getting to the fbdev prober because its falling back on it | 20:46 |
| NCommander | (no other drivers are loading) | 20:46 |
| NCommander | WHich in turn calls its own probe functions. | 20:46 |
| * bryce nods | 20:46 | |
| NCommander | Mystery solved | 20:46 |
| NCommander | Now if I can just figure out how to sanely get info out of FB devices :-) | 20:46 |
| bryce | sometimes the fallback logic feels like pinball ;-) | 20:47 |
| NCommander | This code base burns in all sorts of unclean ways | 20:47 |
| NCommander | Figuring out the build system was the first fun bit | 20:47 |
| NCommander | I always wondered why it was called the X strike force | 20:47 |
| NCommander | Now I know | 20:47 |
| bryce | heh | 20:48 |
| NCommander | Oh | 20:57 |
| NCommander | You are ****ing kidding | 20:57 |
| NCommander | the FB ID string can have nulls in place of spaces | 20:57 |
| NCommander | ARGHHHHHHHHHHHHHHHHHHHH | 20:57 |
| bryce | eww | 20:57 |
| bryce | that's crazy | 20:57 |
| NCommander | Ugh. it makes me want to scream, rant, rave, find the developer who designed this mechanism, and beat into them that NULLs shouldn't be used like this! | 20:58 |
| NCommander | printf(" id : \"" "%c%c%c%c" "%c%c%c%c" "%c%c%c%c" "%c%c%c%c" "\"\n", | 20:59 |
| NCommander | fscreeninfo.id[0], fscreeninfo.id[1], fscreeninfo.id[2], fscreeninfo.id[3], | 20:59 |
| NCommander | fscreeninfo.id[4], fscreeninfo.id[5], fscreeninfo.id[6], fscreeninfo.id[7], | 20:59 |
| NCommander | fscreeninfo.id[8], fscreeninfo.id[9], fscreeninfo.id[10], fscreeninfo.id[11], | 20:59 |
| NCommander | fscreeninfo.id[12], fscreeninfo.id[13], fscreeninfo.id[14], fscreeninfo.id[15] ); | 20:59 |
| NCommander | oops | 20:59 |
| NCommander | http://paste.ubuntu.com/105322/ | 20:59 |
| NCommander | That's what's required to print out the ID string | 20:59 |
| NCommander | MY EYES | 20:59 |
| bryce | oh the fun things you find in the dark corners of that which we call X. ;-) | 21:02 |
| NCommander | That isn't X | 21:02 |
| NCommander | That's kernel madness | 21:02 |
| bryce | ahh, even darker corners | 21:03 |
| kees | er, wrong channel | 21:10 |
| kees | NCommander: http://paste.ubuntu.com/105325/ | 21:10 |
| * NCommander doesn't quite get how xf86MatchDevice works ... | 22:17 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!