| === mzz_ is now known as mzz | ||
| lesshaste | hi all | 10:30 |
|---|---|---|
| lesshaste | hi.. I have a firefox problem where it freezes when uploading files... The strace at http://pastebin.com/f118d9b2e seems to actually imply it's an X server problem as firefox is waiting for something from the server which never arrives. the important part starts at line 1770 | 10:32 |
| tjaalton | lesshaste: do you have /tmp/.X11-unix/X0 or not? | 10:39 |
| lesshaste | ls -lat /tmp/.X11-unix/X0 | 10:40 |
| lesshaste | srwxrwxrwx 1 root root 0 2009-09-16 08:38 /tmp/.X11-unix/X0 | 10:40 |
| lesshaste | tjaalton: sorry that was meant for you | 10:40 |
| tseliot | tjaalton: did you investigate what pitti reported about vmmouse? | 10:41 |
| tjaalton | tseliot: yes, the fix was in git but never uploaded | 10:41 |
| tseliot | tjaalton: ah, ok. So we shall wait until the freeze is over | 10:42 |
| tjaalton | lesshaste: ok. can't tell why it fails then | 10:42 |
| tjaalton | tseliot: yes | 10:42 |
| tseliot | ok, thanks | 10:42 |
| lesshaste | tjaalton: disabling all extensions fixed it! | 10:43 |
| lesshaste | all add-ons I mean | 10:43 |
| lesshaste | the problem is either the adblock plus or flashblock it seems | 10:59 |
| === mzz_ is now known as mzz | ||
| loic-m | tjaalton: hi | 13:43 |
| loic-m | tjaalton: is linuxwacom 0.8.4.1 (stable) definitely off for Karmic? | 13:43 |
| tjaalton | loic-m: no, been on my todo-list for a while | 13:50 |
| loic-m | tjaalton: ok, thanks. I can't get my tablt configured in Karmic ;) | 13:51 |
| loic-m | I had another look at the Debian packaging no I've a bit more experience, and it looks messy | 13:51 |
| loic-m | Doesn't that causes troubles when upgrading? | 13:52 |
| tjaalton | yes | 13:52 |
| tjaalton | upstream is going to fix their release model soonish | 13:53 |
| tjaalton | and put the driver in git.fd.o | 13:53 |
| tjaalton | that'll be a day to celebrate | 13:53 |
| loic-m | Indeed... Did they discuss that on the -devel list? | 13:53 |
| tjaalton | only briefly | 13:54 |
| tjaalton | but now there seems to be http://cgit.freedesktop.org/~whot/xf86-input-wacom/ | 13:54 |
| tjaalton | whot is cleaning up the driver | 13:54 |
| jcristau | whot is awesome :) | 13:55 |
| tjaalton | yeah, he's like all over the place :) | 13:55 |
| tseliot | superm1: I uploaded nv to my PPA (I had to sign the source though) | 13:55 |
| * tseliot would like to see wacom use xinput | 13:56 | |
| tjaalton | it's going to | 13:57 |
| tseliot | http://cgit.freedesktop.org/~whot/xf86-input-wacom/commit/?id=2e01d5b83ae710c4dccfb5d79c7154c38419b9f3 | 13:57 |
| tseliot | \o/ | 13:57 |
| loic-m | Didn't realise whot=Peter Hutterer | 13:57 |
| loic-m | yes, sounds awesome | 13:57 |
| loic-m | What was the problem with lw release tarballs? | 13:58 |
| tjaalton | the are just that, blobs, and no way to cherry pick newer changes | 13:59 |
| tjaalton | at least I couldn't make git-svn to work | 14:00 |
| loic-m | My difficulty is more that the current packaging isn't transparent - i.e. no doc about what was done for the repack, and inline patches even though there's a patch system | 14:02 |
| tjaalton | because the build system is a mess | 14:05 |
| tjaalton | ie. the packaging | 14:05 |
| loic-m | Makes the netry barrier level a tad high | 14:10 |
| tjaalton | that'll get fixed when the upstream packaging is like the rest of the drivers | 14:11 |
| loic-m | Is there a good way to learn about drivers packaging? | 14:11 |
| tjaalton | existing packages I guess | 14:12 |
| jcristau | it's pretty basic autotools, plus some magic to make sure we get the right abi provides and depends | 14:12 |
| loic-m | is there differences with applications packaging? | 14:13 |
| JontheEchidna | I have a bug I need to report, and was wondering if it should be filed against libdrm or xserver-xorg-video-intel. Basically, DRM fails to load and X is forced to resort to the software rasterizer: http://paste.ubuntu.com/272111/ | 14:28 |
| JontheEchidna | This happens on an alpha 5 livecd, too | 14:28 |
| JontheEchidna | xserver-xorg-video-intel makes performance a bit better, but it still is using the software rasterizer :( | 14:29 |
| JontheEchidna | *xserver-xorg-video-intel from xorg-edges | 14:29 |
| tjaalton | loic-m: got a driver for you to test.. | 15:01 |
| loic-m | tjaalton: thanks | 15:01 |
| tjaalton | 32 or 64bit? | 15:02 |
| loic-m | 32 please | 15:02 |
| tjaalton | loic-m: http://users.tkk.fi/~tjaalton/foo/xserver-xorg-input-wacom_0.8.4.1-0ubuntu1_i386.deb | 15:03 |
| loic-m | tjaalton: no need to test wacom-tools too? | 15:06 |
| tjaalton | http://users.tkk.fi/~tjaalton/foo/wacom-tools_0.8.4.1-0ubuntu1_i386.deb | 15:06 |
| loic-m | tjaalton: thanks | 15:07 |
| loic-m | bbl | 15:23 |
| loic-m | tjaalton: your 0.8.4.1 wacom packages work well with my Intuos3 6x8. Input-hotplug, pressure in Gimp, and setting the properties with xsetwacom for the pad | 16:25 |
| loic-m | Inkscape draws completely off base, but that's AFAIK a known bug, also in Jaunty | 16:26 |
| loic-m | The provided .fdi still doesn't work with wacomcpl, but that was the same in Jaunty too | 16:27 |
| loic-m | The Cintiq is another story, will probably take longer to set up till I can really say I tested it, because of the dualscreen configuration | 16:28 |
| tjaalton | loic-m: ok, nice to hear | 18:27 |
| loic-m | indeed ;) | 18:28 |
| tjaalton | could you reply to bug 405800, it would help getting it ack'ed | 18:31 |
| ubottu | Launchpad bug 405800 in wacom-tools "Please update wacom to 0.8.4-1 version" [Wishlist,Confirmed] https://launchpad.net/bugs/405800 | 18:31 |
| loic-m | Sorry, was away. I'll do that right now | 18:40 |
| tjaalton | thanks | 18:43 |
| loic-m | Done, tell me if you need anything else. | 18:46 |
| Ng | so with gnome screensaver not quite working on suspend atm, I'm reminded just how beautifully fast X gets video back up after resume :) | 20:53 |
| Ng | the wrinkle being that input devices | 20:53 |
| Ng | take several seconds. I seem to remember someone saying that fedora had some kind of patch for that | 20:53 |
| Ng | (also from a simple usability/polish point of view I wonder if the fadeout of gnome-screensaver should happen *way* faster so suspend happens almost as fast as it's happening atm | 20:56 |
| Ng | afaict the fade is about 1s long atm, which subjectively seems like the longest part of the suspend process ;) | 20:56 |
| jcristau | heh, the suspend process starts when i close the lid, and finishes right about when the laptop is in its bag :) | 21:03 |
| cdE|Woozy | does the suspend process really wait for gnome-screensaver to finish fading out? | 21:03 |
| Ng | cdE|Woozy: I was poking at the gnome-session source earlier and it seems that when it wants to blan kthe screen it shells out to gnome-screensaver-command, which afaict doesn't return until the activate/lock has finished fading | 21:10 |
| Ng | (see "time gnome-screensaver-command --activate") | 21:10 |
| Ng | I kinda assumed it would be dbus magic, and I can well understand that you wouldn't want the actual suspend to happen mid-fade | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!