[01:15] <ubotu> New bug: #188642 in compiz (main) "default live CD boot shows rendering artifacts/defects along window edges (dup-of: 175774)" [Undecided,New] https://launchpad.net/bugs/188642
[03:12] <bryce> http://bryceharrington.org/files/screenrez_8.png
[08:09] <tjaalton> bryce: looks good. should there be a "clone" bullet too?
[08:09] <bryce> http://bryceharrington.org/files/screenrez_9.png
[08:09] <tjaalton> ah :)
[08:10] <bryce> it was getting clunky to have a bullet for that and making the code crufty
[08:10] <bryce> xrandr internally treats "clone" as a kind of relation
[08:10] <bryce> so the code ends up cleaner this way.  I hope users don't get confused by it..
[08:10] <tjaalton> btw, did you have something for xorg-server that's not committed yet?
[08:11] <bryce> hmm, maybe
[08:11]  * bryce thinks
[08:11] <tjaalton> the dix-patch
[08:11] <bryce> there's a poulsbo patch, but I don't think it's going into hardy proper
[08:12] <bryce> dix-patch?
[08:12] <tjaalton> I mean the one that's already uploaded ;)
[08:12] <tjaalton> * Add a patch from Matthew Garrett to fix touchscreen issues with DIX.
[08:13] <bryce> is that not already checked in?
[08:13] <tjaalton> I can't see it
[08:15] <bryce> ah, I committed but didn't push
[08:15] <bryce> check if you see it now
[08:15] <tjaalton> yep, it's there no
[08:15] <tjaalton> +w
[08:15] <bryce> sorry about that
[08:15] <bryce> tjaalton: btw, we had our platform team meeting just now (on #ubuntu-meeting)
[08:16] <tjaalton> no problem, that happens
[08:16] <tjaalton> ok, what did you discuss?
[08:16] <bryce> here I'll pastebin for you
[08:17] <tjaalton> I can also check the irclogs
[08:17] <bryce> http://paste.ubuntu-nl.org/55828/
[08:18] <tjaalton> yeah, I'll contact cjwatson
[08:19] <bryce> the xrandr gui now correctly detects my dual screen setup :-) :-)
[08:22] <bryce> (I'm still too chicken to click Apply on anything... have to click that tomorrow though...)
[08:25] <tjaalton> heh
[08:29] <tjaalton> bryce: what's the "hardy-console" stuff?
[08:29] <bryce> was adding i18n support to hardy-console
[08:29] <tjaalton> ah, ok
[08:30] <bryce> https://blueprints.launchpad.net/ubuntu/+spec/hardy-console
[08:32] <tjaalton> yes, I see the problems all the time :)
[08:32] <tjaalton> anyway, I'll ask colin about input-hotplug now
[08:32] <bryce> cool
[08:33] <bryce> maybe wait until after the meeting in #ubuntu-meeting is done; he'll have more attention then
[08:33] <tjaalton> ah ok
[08:40] <bryce> ok, over now
[08:40] <bryce> heya seb128
[08:41] <bryce> seb128: btw, I've got a patch for gnome-control-center coming in a few days (potentially after FF)
[08:41] <bryce> seb128: http://bryceharrington.org/files/screenrez_9.png
[08:45] <seb128> hey bryce
[08:54] <seb128> bryce: do you work with upstream or at least discuss the feature and UI with them?
[08:54] <seb128> bryce: is that an user only config or does it change xorg.conf etc?
[08:54] <tjaalton> user only
[08:54] <bryce> it does not change xorg.conf
[08:55] <bryce> seb128: I spoke briefly with keithp about the changes to libxrandr but haven't spoken with gnome yet - getting the libxrandr changes accepted upstream will be a prerequisite for gnome to accept the changes
[08:55] <seb128> ok
[08:56] <bryce> seb128: however I did see in a discussion on gnome-control-center several months ago by glatzor about displayconfig-gtk that upstream basically said it had to be redone the way I'm doing it
[08:56] <seb128> right
[08:56] <seb128> but please discuss the UI, etc before doing the code
[08:56] <seb128> because I don't want another non trivial patch than we will have to keep for ages because we didn't discuss it with upstream before and they disagree on how to do the changes
[09:00] <bryce> hmm, well if you suspect they're going to reject it, perhaps I should just package it as a standalone tool
[09:00] <seb128> oh, no, I don't say they will
[09:00] <seb128> I say to better discuss the feature and UI now based on your mockup to make sure that's something we agree on
[09:01] <seb128> they might have good comments
[09:01] <seb128> and so we make sure we don't waste energy to do something which will not be accepted
[09:05] <seb128> that's one of the complain we get from upstream sometimes, that distro do things on the side and then send everything upstream which rather than discuss it first with them to do it in a way which will work for everybody
[09:07] <mvo> where is the new code currently? in some bzr branch?
[09:08] <bryce> seb128: well they also complain we don't contribute things in the first place.  they ought to be happy that we're redoing it in a fashion that can be incorporated
[09:08] <bryce> mvo, yeah
[09:11] <seb128> bryce: ok, let's say we disagree on that then, that's alright
[09:11] <seb128> they are happy we contribute
[09:11] <seb128> though sometime that leads to thing they will not accept because they disagree on the implementation and it's really lot of work for us to maintain the changes in a distro specific way
[09:12] <seb128> and they receive bugs which are distro specific, etc
[09:12] <seb128> and that creates tensions where we could discuss thing first to make sure that's done in a way they will accept the change
[09:14] <bryce> hrm.
[09:15] <bryce> well, I worry they would just ask for a whole bunch of changes which would require a lot more time to have to be put into it
[09:15] <bryce> design by committee, etc.
[09:15] <seb128> I didn't say they have to accept the changes now
[09:16] <seb128> but just make sure we go in a way which will make the patch acceptable for upstream at some point
[09:16] <seb128> maybe not this cycle but the next one, that's fine
[09:17] <bryce> yeah, like I said the libxrandr changes have to be done first anyway
[09:17] <seb128> alright
[09:18] <mvo> bryce: its cool that you extend the display capplet for this, that is the right approach
[09:19] <seb128> still if anybody wants to send a mail to the control-center list with the mockup and saying we plan to work on something like that once those libxrandr changes are done they that would be welcome
[09:19] <seb128> we could get UI comments from them already, etc
[09:19] <seb128> sorry if it seems I'm not happy about the changes, that's not the case, I think that's great too ;-)
[09:20] <seb128> I just know I'm the one who will have to update the patch every 2 weeks when GNOME roll new tarballs
[09:20] <seb128> and merging glade changes is not fun, I already do it for the desktop effects thing ;-)
[09:21] <bryce> hmm, yeah I understand
[09:21] <bryce> fwiw, there's no glade changes in this, just plain gtk code
[09:22] <seb128> ah good, I didn't look at the capplet recently and I though they were all using glade nowadays
[09:22] <seb128> should make the work easier ;-)
[09:22] <bryce> this one appears to not have been touched in years
[09:25] <bryce> well, ok I'll send an email
[09:28] <seb128> bryce: thanks
[09:52] <bryce> emailed.  sent them this link - http://bryceharrington.org/files/screenrez_a.png
[09:53] <bryce> bleah, I got an AMD meeting in 6 hrs.  time for bed.  night.
[09:53] <tjaalton> night :)
[10:03] <seb128> bryce: thanks and good night
[16:46] <bryce> seb128: seen the responses on gnomecc?
[16:48] <seb128> yes
[16:48] <seb128> see why you should mail upstream first?
[16:48] <seb128> ;-)
[16:48] <bryce> eh
[16:49] <bryce> hmm, I swore I checked that site before I started, and there wasn't much there besides the mockups
[16:49] <bryce> in any case, that code doesn't appear to be in a shippable state
[16:49] <seb128> maybe they have just updated it before replying
[16:50] <bryce> seb128: but otoh it shows that gnome intends to adopt redhat's work instead of anything we do
[16:50] <seb128> not really
[16:50] <seb128> mclasen is a redhat guys
[16:50] <seb128> but he's not a gnome-control-center maintainer
[16:51] <seb128> there is no g-c-c maintainers from redhat actually
[16:51] <seb128> so we might to decide to pick whatever is better
[16:51] <seb128> but that keeps happening between novell and redhat
[16:51] <seb128> they do their thing and after that there is always the same discussion on which one to use
[16:51] <seb128> happened with netapplet and network-manager
[16:52] <seb128> with xgl and aiglx
[16:52] <seb128> with the new clock applet thing
[16:52] <bryce> huh
[16:59] <bryce> hmm, in any case, looking through the code it appears they also started from the screen resolution tool but seem to have been focused less on hooking up to xrandr, and more towards some sort of dynamic monitor detection/refresh functionality
[16:59] <bryce> they seem to be missing all the xrandr 1.2 stuff
[16:59] <seb128> that's why their solution might not be the best one
[16:59] <seb128> and that's not sure upstream will use it
[17:00] <bryce> it's using glade, btw
[17:01] <bryce> ok, well I'm going to press on with what I've done - it's closer to the xrandr 1.2 goals and I'm more familiar with the code
[17:02] <seb128> good
[17:02] <bryce> I'll try drawing in some of their design ideas.  maybe a merge would be feasible at some point, if the monitor auto-refresh stuff looks good
[17:02] <seb128> as said there is no redhat bias in the gnome-control-center team I think
[17:03] <seb128> so there is no reason we would not decide on the best solution
[17:03] <bryce> ok, I wasn't sure of that... some of the comments made it sort of seem that way
[17:03] <seb128> no g-c-c maintainers commented yet
[17:03] <seb128> vuntz is an upstream guy, mclasen from redhat and fcrozat from mandriva
[17:03] <bryce> ahh, ok
[17:03] <bryce> wasn't familiar with any of the names
[18:54] <tedg> Okay guys, I have a weird problem that I have no idea how to write a bug report about.
[18:54] <tedg> It seems that on my intel card, the output every so often dies.
[18:54] <tedg> Like seriously, just the output.
[18:54] <tedg> The screen will go all white and if I restart X it'll stay all black.
[18:55] <tedg> X seems to be running all happy as GDM starts and even playes the login sound.
[18:55] <tedg> I don't see anything in my logs that is different when this happens.
[18:55] <tedg> It probably only happens ever few days, maybe even a week though.
[18:55] <tedg> Is there some information I can grab at that time that'd be useful?
[19:14] <tjaalton> tedg: when did you first see this? are you running the latest driver?
[19:15] <tedg> tjaalton: Yes, I've only really run Hardy on this box.  So for the last few months.
[19:15] <tedg> tjaalton: I got the box in Dec.
[19:28] <tjaalton> tedg: does bug 139094 look similar?
[19:28] <ubotu> Launchpad bug 139094 in xserver-xorg-video-intel "white screen on intel GMA 900 graphics card " [Undecided,Confirmed] https://launchpad.net/bugs/139094
[19:37] <tedg> tjaalton: A little, but not quite as it runs normally for days, and then breaks.  But, it might be related.
[19:37] <tedg> Theirs looks easier to reproduce ;)
[19:37] <tjaalton> heh
[19:38] <tjaalton> what chip is it? (lspci -vv |grep VGA)
[19:39] <tedg> Intel 945GM/GMS, 943/940GM
[19:39] <tedg> I'm not sure why both of those are in the lspci.
[19:39] <tedg> But it's one string.
[19:39] <tedg> HAL reports the same.
[19:41] <tjaalton> ok..
[19:43] <tjaalton> I'm not sure where to start debugging
[19:44] <tedg> Me neither :)
[19:44] <tjaalton> I'll check bugs.fd.o
[19:44] <tedg> Is there someplace that I can query more information from the driver when it happens?
[19:45] <tedg> It really feels (from a user perspective) like the output driver isn't getting set right.
[19:45] <tedg> I wonder if I log in as GDM if I can query xrandr....
[19:45] <tedg> Perhaps it's a really weird resolution/refresh rate that's confusing my LCD.
[19:46] <tedg> Does that make sense, or is it crazy?
[19:46] <tjaalton> hard to tell :)
[19:47] <tjaalton> does it gradually turn white or all of a sudden?
[19:49] <tedg> All of a sudden.  It's only happened once or twice when I'm at the computer.
[19:49] <bryce> tedg, if you put xhost + in your .xinitrc or something before starting up, you should be able to call something like DISPLAY=":0.0" xrandr
[19:49] <tedg> Just by law of averages, it seems to be mostly when I'm not at the computer :(
[19:49] <bryce> then could it be a screensaver thing?
[19:50] <tedg> bryce: Is there a way that I can do "xhost +" after X has started, like remotely?  I'm a little nervous putting xhost in xinit.
[19:50] <tedg> bryce: I don't think so, it has happened while I've been sitting there.
[19:51] <tjaalton> hmm, right.. it could be a screensaver that triggers it
[19:51] <tedg> It just happens very rarely.
[19:51] <tjaalton> oh right, so if it happens while the session is active..
[19:51] <bryce> afaik, you have to run xhost from a client inside the xserver you're adjusting
[19:52] <tedg> Hmm, okay.  I'll try to get some more info the next time it happens.
[19:53] <tjaalton> do you use compiz?
[19:53] <tedg> It doesn't happen enough that it's a real blocker, but it would make people think "Ubuntu is unstable" if it happened to normal users.
[19:53] <tedg> tjaalton: When it doesn't crash, yes. ;)
[19:53] <tedg> It's not on right now because it crashed this morning.
[19:53] <tjaalton> so it could be a bug in the mesa/dri-land
[19:54] <bryce> ew
[19:54] <tedg> tjaalton: Yeah, but the weird part is that it doesn't come back when I restart and GDM is running.
[19:54] <tedg> I dont' have a GDM theme that uses OpenGL.  (Hardy+1)
[19:54] <tjaalton> ok so gdm is running in the background and you can hear the drums?-)
[19:55] <tedg> Yeah, I hear the drums.
[19:55] <tedg> I didn't try to login... that might be an interesting test.
[19:55] <tjaalton> right, it's not a gpu hang then
[19:55] <tedg> I could probably login, Alt+F2 and do the xhost.
[19:55] <tedg> It really feels like just the output module of the GPU is not there.
[19:56] <tjaalton> I guess it's a worthy bug for upstream ;)
[19:56] <ubotu> New bug: #191646 in linux-restricted-modules-2.6.24 (restricted) "[hardy] Xorg freeze at multi user logon, when both uses compiz" [Undecided,New] https://launchpad.net/bugs/191646
[19:56] <tedg> Does X11 use HDCP over DVI?  Could it be misnegotiating with the monitor?
[20:05] <tjaalton> hmm, hdcp is a DRM technique ;)
[20:06] <tjaalton> anyway, AFAIK the negotiation is done once, when the server starts or the device is plugged
[20:07] <tedg> Should be, but I was curious if witching to things like VTs and back would cause a renegotiation.
[20:07] <tedg> DRM is always a problem, I was curious if it might be here also ;)
[20:12] <tjaalton> if restarting the server doesn't help, then it's probably not the monitor
[22:26] <ubotu> New bug: #28604 in linux-restricted-modules-2.6.15 (restricted) "Cannot prelink against non-PIC shared library /usr/lib/libGL.so.1.0.8178" [Medium,Won't fix] https://launchpad.net/bugs/28604
[22:26] <ubotu> New bug: #39107 in linux-restricted-modules-2.6.15 (restricted) "1.0.8756+2.6.15.8-1 renders very badly in some games" [Low,Fix released] https://launchpad.net/bugs/39107
=== seb128_ is now known as seb128
[23:10] <ubotu> New bug: #191697 in xserver-xorg-video-intel (main) "displayconfig-gtk don't work (dup-of: 151647)" [Undecided,New] https://launchpad.net/bugs/191697
[23:11] <ubotu> New bug: #127905 in linux-restricted-modules-2.6.22 "Xorg crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/127905
[23:11] <ubotu> New bug: #133268 in linux-restricted-modules-2.6.22 "Xorg crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/133268
[23:31] <ubotu> New bug: #141267 in linux-restricted-modules-2.6.22 "package linux-restricted-modules-2.6.22-11-generic 2.6.22.3-11.4 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,Fix released] https://launchpad.net/bugs/141267