[00:14] <bryce> xerosis, even if it has been reported, it's usually better that you file another report
[00:14] <bryce> xerosis, anyway it doesn't strike a bell with me; so it probably hasn't been reported
[00:15] <bryce> xerosis, 'ubuntu-bug xorg' and attach a photo of the screen
[00:15] <bryce> actually it's probably a linux bug, not xorg.
[00:15] <xerosis> bryce: thanks, I'll do that
[05:35] <pwnguin> should i be surprised that uinput can be used to crash X?
[05:38] <pwnguin> a friend is reporting wminput can crash X reliably
[05:40] <pwnguin> not sure whether to blame wminput for acting funny, or X for crashing because of it
[05:50] <pwnguin> crazy thing is, i cant duplicate i
[05:50] <pwnguin> t
=== ripps_ is now known as ripps
[08:53] <bryce> pwnguin, collect a full backtrace, file a bug.  X should not be crashable by any client app
[09:37] <Ng> [09:30] < hughsie> if anyone was wondering about how to fix gnome-power-manager blanking the screen when  the session is not idle, then I've posted a fix here:  http://blogs.gnome.org/hughsie/2009/08/14/blanking-in-gnome-power-manager-fixed/
[09:38] <Ng> I believe karmic people are seeing this. I certainly am ;)
[09:44] <diverse_izzue> Ng, awesome, many people on Karmic see this!
[09:45] <tseliot> it's definitely worth backporting
[09:45] <bryce> yeah on my todo list
[09:46] <bryce> would have done it yesterday but we were frozen; didn't do it today just because I got distracted by other matters.
[09:49] <seb128> so it was an xorg bug ;-)
[09:50] <Ng> \o/
[09:57] <tjaalton> the random blanking didn't matter too much, but if it allows the display to sleep when it should, then I'm happy :)
[09:57] <seb128> right, it's rather disturbing that a real issue
[09:57] <seb128> at least it doesn't break anything
[09:58] <tjaalton> sounds like it's not the same issu
[09:58] <tjaalton> +e
[09:58] <tjaalton> in karmic my display(s) never blank or go to sleep when they should
[09:58] <bryce> seb128, shut it
[09:59] <tjaalton> :)
[09:59] <seb128> what?
[10:00] <bryce> actually, the patch Ng points to is different from the one I was looking at that someone else pointed to
[10:00] <seb128> was that I request for me to stop writing there?
[10:01] <bryce> seb128, ah, yeah that'd do ;-) ;-)
[10:01] <Ng> tjaalton: random blanking seems to also include random suspending, which is really quite annoying :)
[10:01]  * seb128 confused
[10:01] <bryce> actually I never was sure whether this was an xorg bug or not; I'd upstreamed it to -ati but they claimed it was a ubuntu problem, so they were wrong
[10:02] <bryce> Ng, wonder how many bugs this'll close
[10:02] <Ng> yeah, could be interesting
[10:03] <hyperair> random suspending?
[10:03] <tjaalton> seb left :P
[10:03] <hyperair> i haven't noticed that one. though random blanking does happen
[10:09] <Ng> hyperair: I would assume that if idle timeouts are confused all kinds of random idle-related power events could happen
[11:30] <hyperair> Ng: i suppose. that would suck, though
[11:43] <Ng> hyperair: I get quite angry when it happens ;)
[11:43] <Ng> then I remind myself that I'm running a development release, and look at something shiny that I didn't have in jaunty, and smile again ;)
=== ScottK2 is now known as ScottK
[13:29] <hyperair> Ng: haha. i don't get angry if errors are easily recoverable.
[13:30] <hyperair> Ng: like i don't get annoyed over compiz refusing to redraw when i return from hibernation/suspension
[13:30] <Ng> hyperair: I'm usually working when it happens, and all my work is over ssh ;)
[13:30] <hyperair> Ng: what i do get annoyed about is stuff like the GEM memory leak. but that's in the past
[13:30] <Ng> hyperair: (but I know I can't blame anyone for a development distro breaking my work, and I have no desire to)
[13:30] <hyperair> hahah
[13:31]  * hyperair began running karmic because jaunty was very annoying with the whole intel mess
[13:32]  * hyperair brb new kernel
[13:33] <tjaalton> I don't understand why icons were removed from gtk menus
[13:34] <tjaalton> quite useful for the firefox bookmark-menu for instance..
[13:34] <tjaalton> _that_ makes me upset, not some random crash :)
[13:35] <seb128> tjaalton, the bookmarks not having icons is a firefox bug
[13:35] <tjaalton> seb128: ok, good to hear :)
[13:35] <seb128> they is a property to set to always have an icon
[13:35] <seb128> objects should set this one
[13:35] <seb128> ie drives, bookmarks, files, directories, etc
[13:36] <tjaalton> hmm, I see icons on my laptop again
[13:36] <seb128> you can also turn icons back using a gconf key
[13:36] <tjaalton> maybe it's ff 3.5
[13:36] <seb128> the rational was that icons were overused
[13:36] <tjaalton> sure
[13:37] <tjaalton> there are places where I got so used to them that they help me navigate to the correct entry
[13:37] <tjaalton> it's faster to recognize the icon than to read the text :)
[13:37] <seb128> right same here
[13:37] <seb128> bug #407621
[13:37] <tjaalton> but I'll wait and see what comes next
[13:37] <ubottu> Launchpad bug 407621 in libgnome "(design decision) Icons missing from context menu , dialogue buttons , firefox bookmark favicons" [Wishlist,New] https://launchpad.net/bugs/407621
[13:37] <seb128> comment there
[13:37] <tjaalton> thanks, I'll subscribe for now
[13:42] <Ng> I hope the always_show icon property will lead to smarter use of icons, and not just flood them back by people setting it everywhere ;)
[13:42] <Ng> I always thought the stock icons were a good idea though
[13:43] <Ng> it strongly hints that something is going to do what you expect
[13:45] <seb128> right, it reboot in fusa is clear
[13:45] <seb128> the no icon force you to read text
=== ripps_ is now known as ripps