| === RAOF is now known as raof | ||
| bryce | tjaalton: whoa @ tdflanders on 318276 | 06:53 |
|---|---|---|
| raof | That's pretty weird, yes. | 06:58 |
| bryce | heya raof, how goes? | 06:59 |
| raof | Pretty all right. | 06:59 |
| raof | gnome-do's sauntering towards a release, which is nice. | 07:00 |
| raof | nouveau should be all ready to go shortly, and it's not waiting on me :) | 07:00 |
| bryce | :-) | 07:01 |
| raof | Although someone needs to put the headers back in libdrm-dev before the DDX will build again (at which point I'll merge the new debian version) | 07:03 |
| mvo | nowdays ctrl-alt-backspace is disabled, right? is there a way to re-enable it? | 08:06 |
| tjaalton | mvo: yes, Option DontZap | 08:45 |
| mvo | thanks tjaalton | 09:04 |
| Alexia_Death_ | tjaalton: Wacom has a new package out that contains a bulid switch to navigate around the crash issue. | 09:42 |
| Alexia_Death_ | tjaalton: and the buttons patch does not apply on top of all other patches already in the xorg core package :( | 09:43 |
| Alexia_Death_ | tjaalton: and a question about udev rules for wacoms. How are they maintained and are they cast in iron? My hotplug daemon pesumes some logic from them so Id like to make it come with its own rules. It should be ok as long as /dev/input/wacom is still made. | 09:48 |
| tjaalton | Alexia_Death_: grab the package and look | 16:18 |
| tjaalton | the source | 16:18 |
| tjaalton | whee, nouveau made it in | 16:18 |
| tjaalton | nouveau-kernel-source | 16:18 |
| Alexia_Death | tjaalton: what package is that? | 16:45 |
| Alexia_Death | tjaalton: ignore that question. Stupid me. apt-file tells me that. | 16:47 |
| tjaalton | Alexia_Death: wacom-tools | 16:47 |
| tjaalton | the rules are maintained theree | 16:48 |
| tjaalton | -e | 16:48 |
| Alexia_Death | thats not what apt-file told me the rules were from... | 16:48 |
| Alexia_Death | xserver-xorg-input-wacom was what apt-file returned... | 16:49 |
| tjaalton | yes, but the source package is wacom-tools.. | 16:49 |
| Alexia_Death | aah... | 16:50 |
| Alexia_Death | thanks | 16:50 |
| Alexia_Death | tjaalton: are you aware of any dependendcies related to the udev rules used? Because I have looked at udev ruleset from fedora and find it a lot better for organizing the devices... | 16:52 |
| tjaalton | Alexia_Death: nope | 16:54 |
| tjaalton | haven't looked at it | 16:54 |
| Alexia_Death | so replacing them if needed should not be a problem? | 16:55 |
| tjaalton | well better discuss it with the debian maintainer | 16:56 |
| Alexia_Death | Alternatively the hotplug daemon can just install its own set of higher priority rules but that would be rather dirty. | 16:58 |
| tjaalton | talk to Ron, he's quite reasonable | 17:01 |
| pcjc2 | Hi tseliot | 17:16 |
| tseliot1 | pcjc2: hey, I've just replied in the bug report | 17:23 |
| tseliot1 | pcjc2: I would like to try the fix here too | 17:24 |
| pcjc2 | Its odd you can't reproduce the symptom of the slow probe for the GetScreenSizeRange request | 17:27 |
| pcjc2 | are you using an intel card? | 17:27 |
| tseliot1 | yep | 17:29 |
| pcjc2 | this problem has some strangeness to it | 17:32 |
| pcjc2 | like, its not obvious why it was never a problem in the past | 17:32 |
| pcjc2 | Either the probes weren't expensive, didn't succeed, or the notifications never got through | 17:32 |
| pcjc2 | I think the support for changing backlight via a property is relatively new - and a prerequisite for the bug | 17:33 |
| pcjc2 | but I was using the new intel driver long before I ever saw the problem | 17:33 |
| tseliot1 | pcjc2: I think the backlight property existed in 1.2 too | 17:33 |
| tseliot1 | maybe the notifications didn't go through until the upgrade of libxrandr | 17:34 |
| pcjc2 | that was my pet theory | 17:34 |
| tseliot1 | which would be weird | 17:34 |
| tseliot1 | but not unlikely ;) | 17:35 |
| pcjc2 | there was some brokenness on the wire-protocol for some of those notifications, which got fixed in the upgrade | 17:35 |
| pcjc2 | in theory, the notifications give the interested application enough information so it shouldn't need to call Xrandr | 17:35 |
| tseliot1 | yes but it never worked in the randr applet | 17:36 |
| tseliot1 | which might confirm your theory | 17:36 |
| pcjc2 | That is hidden by GDK unfortunately, so apps doing this "properly" need either to work with Xrandr directly, or GDK needs to proxy the information better | 17:36 |
| pcjc2 | interesting.. it does begin to sound like there is a picture forming. | 17:36 |
| pcjc2 | GTK / GDK doesn't make it easy to write "good" remote X11 apps | 17:37 |
| pcjc2 | I've got to dig through a load of problems with gEDA/gschem over remote X11 connections | 17:37 |
| pcjc2 | (Rather.. see if we can do anything to improve the performance). | 17:38 |
| tseliot1 | hehe | 17:38 |
| pcjc2 | Round-trips to the server -> high latency -> bad user experience. | 17:38 |
| pcjc2 | Assuming the apps are local is a luxury ;) | 17:38 |
| pcjc2 | with regards testing the server's Xrandr extension version at run-time | 17:39 |
| pcjc2 | I'll grant that it is unlikely you want to be running gnome-power-manager remotely | 17:39 |
| pcjc2 | but if you're hosting a server serving thin clients, you may find the X11 proxy / server used for that doesn't support the new extension. | 17:40 |
| pcjc2 | In the thin-client case, the whole gnome-desktop fires up as normal, power-manager included. (Although it is unlikely it would be changing the backlight brightness of the remote X11 server, those code-paths are still "live") | 17:40 |
| tseliot1 | ok, I have no experience with thin clients, this is why I asked | 17:41 |
| pcjc2 | last time I tried, I quickly came to the conclusion that they weren't commonly used | 17:42 |
| pcjc2 | had to debug some rather odd issues | 17:42 |
| pcjc2 | I might be setting up another thin-client server some time over the coming month (the last one's hardware died), so I'll have to revise this all again! | 17:43 |
| tseliot1 | ok, let me know then | 17:43 |
| pcjc2 | That was a SuSE box - due to the political reasons here | 17:44 |
| tseliot1 | new use-cases should lead to better testing | 17:44 |
| tseliot1 | oh | 17:44 |
| pcjc2 | The University has a site-license support contract with Novell, and that's what our IT manager installed on the server for me when we got it. | 17:44 |
| pcjc2 | Ubuntu is among a select few approved Linux operating systems here.. added because I asked nicely ;) | 17:45 |
| pcjc2 | Fedora is banned, as is MacOSX! | 17:45 |
| tseliot1 | hehe | 17:45 |
| pcjc2 | The only reason to use SuSE was so the IT admin guys could manage the machine for me - keep me doing my real work, but I might stick Ubuntu server on once we've figured what part of the machine is fried | 17:46 |
| tseliot1 | can't the admin use Ubuntu? | 17:46 |
| jcristau | tjaalton: ooh, your mesa patch made it to rc3 | 17:47 |
| pcjc2 | I'm sure he could use Ubuntu.. just that all the University / Engineering Department servers run SuSE, and have locally mirrored security fixes etc.. | 17:47 |
| tseliot1 | ok | 17:48 |
| pcjc2 | having a SuSE box I'm "root" on is also handy.. since I put together customised SuSE packages gEDA for the Engineering Department. | 17:48 |
| pcjc2 | got to go now.. | 17:50 |
| pcjc2 | bye! | 17:50 |
| tseliot1 | bye | 17:52 |
| tseliot1 | too late | 17:52 |
| tjaalton | jcristau: whee, nice :) | 18:37 |
| tjaalton | raof: so you wanted to have the nouveau headers in libdrm-dev? | 20:53 |
| raof | tjaalton: Yes. They're not going to be shipped with the kernel anytime soon. | 20:54 |
| tjaalton | right | 20:54 |
| raof | And since we already have the DDX synced, and nouveau-kernel-source just needs to make it through NEW... | 20:54 |
| tjaalton | already accepted ;) | 20:55 |
| raof | Sweet. | 20:55 |
| raof | With the headers I can pull in some bugfixes from the new debian package | 20:55 |
| raof | Heh. Now in _binary_ new :) | 20:56 |
| tjaalton | of course | 20:56 |
| tjaalton | I'm waiting for the new kernel to arrive first | 20:58 |
| jonpackard | Hello. My X unexpectedly restarted on me twice today, both time when I was clicking and dragging on a menu (different applications). The second time I grabbed my Xorg.0.log.. could anybody please take a look at it to help me pinpoint the problem? http://ubuntu.pastebin.com/f3881c852 | 21:28 |
| crevette | ah this is the same crash I had the previous week | 21:34 |
| tjaalton | it's nvidia, so.. | 21:37 |
| jonpackard | yeah =X | 21:38 |
| tjaalton | you can try getting a better backtrace though https://wiki.ubuntu.com/X/Backtracing | 21:39 |
| jonpackard | Thanks tjaalton! | 21:40 |
| jonpackard | The only thing I've changed today was installing moonlight in firefox.. I uninstalled it and will see if it happens again. | 21:43 |
| tjaalton | the trace doesn't mentio nvidia_drv, so it might be a valid bug | 21:45 |
| tjaalton | worth getting a gdb trace | 21:45 |
| jonpackard | thanks again.. gotta run :) | 21:46 |
| tjaalton | me too -> zzz | 21:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!