User1: New bug: #196823 in mesa (main) "libgl1-mesa-glx" [Undecided,New] https://launchpad.net/bugs/196823
User1: New bug: #196711 in xserver-xorg-input-mouse (main) "single click is considered as double click" [Undecided,Confirmed] https://launchpad.net/bugs/196711
User2: hmm, should we just drop -unichrome..
User3: have we converted over to openchrome as the default?  or are we still using via?
User3: I think -unichrome could be dropped to universe for Intrepid
User2: it is already in universe, and openchrome is the default
User2: it's just that there are no unichrome releases, the current one is a git checkout from a year ago
User3: hmm
User3: well I would leave it for hardy and drop it starting with intrepid
User2: why wait?
User2: it's just collecting bugs, albeit not that many users apparently, given that it's not even installable currently :)
User3: oh, if it's not even installable, I guess there'd be limited value in keeping it
User2: it's simple to fix though, just change the Provides
User3: I'm just thinking that if people have been using it in the past, dropping it entirely for hardy might be a bit too drastic since hardy is supposed to be an lts
User3: however if it's not installable, and hasn't that many users, it probably won't matter
User2: the driver uses "via" name anyway, so on upgrade the users will end up using openchrome
User2: umm
User2: or maybe not
User2: openchrome sucks in modesetting though
User2: poor via users, nobody cares :)
User3: hehe
User2: bdmurray: nvidia-xconfig is still there, but maybe it should be dropped
User2: but not before jockey has a cmdline option
User1: New bug: #196900 in linux-restricted-modules-2.6.24 (restricted) "Ati x1600Pro White screen on active desktop fx" [Undecided,New] https://launchpad.net/bugs/196900
User3: night
User2: night
User4: is bryce's xrandr stuff going to replace the Screens and Graphics tool?
User2: I think so
User2: although they server different purpose
User2: -r
User4: I was playing with the latter last night at home and it does some strange stuff. I tell it my monitor is an LCD Panel that can do 1920x1080 and the highest resolution it offers is 1680x1050
User4: User2 yeah, that's what I wondered
User4: the strange and wonderful thing is that X actually figures everything out itself if I remove the xorg.conf. pops straight into 1920 :)
User2: guidance trying to be clever or something
User5: man, that tool really kicked my ass when i set up our mythbox
User1: New bug: #196789 in xorg (main) "while playing different games the screen field either shrinks to 1/8  screen size or is sucked into the desktop and vanishes" [Undecided,New] https://launchpad.net/bugs/196789
User1: New bug: #117480 in openoffice.org (main) "OpenOffice 2.2 crashes the machine with File->Open (dup-of: 113679)" [Undecided,Confirmed] https://launchpad.net/bugs/117480
User1: New bug: #189380 in sun-java5 (multiverse) "[Hardy] Can't make any java package work (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/189380
User1: New bug: #196979 in xorg (main) "laptop crashes when closing the lid" [Undecided,New] https://launchpad.net/bugs/196979
User1: New bug: #98594 in xubuntu-meta (universe) "Xubuntu - Bad fonts size: Firefox, OpenOffice, interfaz user, etc (dup-of: 112514)" [Undecided,Invalid] https://launchpad.net/bugs/98594
User6: User3 I officially don't like those gnome-desktop changes
User6: Q-FUNK: the xrand changes
User2: ff3 rocks
User2: hmm? fast as hell and my notification tray is empty :)
User2: uses less memory too
User2: try a new profile
User2: eh
User3: User6 what do you not like?
User6: User3 it add a lot of functions to the public api
User6: User3 I think I would like better to ship copy of the code in gnome-settings-daemon and gnome-control-center if possible
User6: User3 another issue is that those functions don't use a gnome_ namespace and they should
User6: those symbols could conflict with other libs, etc
User6: soren said he would accept a patch to use a correct namespace
User3: by 'ship copy of the code' what do you mean?
User6: the functions which are added to gnome-desktop
User6: have this code in gnome-control-center
User6: and gnome-settings-daemon
User6: so they would not be in any public library
User6: just code in the binaries
User3: ah, ok anything else?
User6: no
User6: sorry about that, but I think it's a better solution
User6: this way we don't provide a non stable api
User6: and we will not break the lib compatibility when upstream does something similar
User6: I mean some function names might change etc when that's upstreamed next cycle
User3: ok, shall I make these changes or are you planning to?
User6: which means the ubuntu libgnome-desktop abi would break compatibility
User6: I'll not do those today most likely
User6: you are welcome to look at those
User6: I'm sorry I had a very busy week
User6: what we can do if you want to get the things some testing is to upload the changes now as you did them
User6: and switch to the copies later
User3: yes, that would be great
User6: ok, I'll do that then
User3: I'll work on the changes today
User6: thanks
User7: User6 I said that I'd accept a patch to use a correct namespace for what?
User6: User7 not you, the soren from redhat who is writting the code we are speaking about
User7: User6 Oh, sorry. :)
User6: User7 sorry about the confusing with your nickname ;-)
User7: User6 No worries :)
User6: User3 gnome-desktop changes uploaded
User3: User6 thanks
User3: User6 you'll be uploading g-c-c and g-s-d as well?
User6: User3 looking at the gnome-settings-daemon changes
User6: there is no setting migration, right?
User6: which means user will be back to whatever xorg uses rather than what he had configured, right?
User3: no, it detects and starts from the current settings
User3: so if they achieved that via xorg.conf, it uses that; if they did it through the current screen resolution tool, it uses that.
User1: New bug: #197049 in xorg (main) "[hardy] shift and caps lock keys not working" [Undecided,New] https://launchpad.net/bugs/197049
User6: User3 how does that work? the user settings are written to gconf and applied on startup right now, the code applying those gconf key is replaced to use the libgnomedesktop one apparently
User1: New bug: #197053 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx None failed to install/upgrade: el subproceso post-removal script devolviÃ³ el cÃ³digo de salida de error 2" [Undecided,New] https://launchpad.net/bugs/197053
User6: User3 gsd uploaded now
User3: what gnomedesktop does is store the configuration layout in an xml file in the user's home dir
User3: so (if I understand correctly) the first time it's run, it will store whatever the user has set up
User3: I tested on a system with dual monitors set up via a .xprofile setting, and it picked up and handled that.  If it handles that ok, it should handle most anything
User3: I also tested with laptops in a few different configurations and it picked up the existing settings correctly
User6: User3 well, the question was whether it'll pick the setting written by the old capplet on gutsy and stored in gconf when you first log in hardy
User6: User3 because I've seen no code reading those gconf keys and written a new .xprofile with the values
User6: User3 which is not really an issue but could be nice to fix
User3: right, it does not read those gconf keys directly, just indirectly by taking them from what has been booted up (which in some ways is better)
User6: I fail to see how that can work
User6: let me take an example
User6: xorg default is 1024x768, user is on gutsy, he picks 800x600, the value is written to gconf
User6: he logs in on gutsy, gnome-settings-daemon read the gconf key, apply it and he gets 800x600
User6: he update the hardy, reboot
User6: he logs in, nothing read the key, nothing apply those, he gets 1024x768 which is the xorg config
User6: no?
User6: since gnome-settings-daemon in hardy doesn't read those keys
User3: hmm
User3: yeah I guess that's true
User6: ok, not a big issue but might be worth considering migration code before hardy
User6: should be easy to have something reading the gconf keys and writting those to xprofile on first hardy login
User6: User3 looking to the capplet changes now, the patches are mostly redhat work, right?
User6: User3 just wanting to give some credit where it's due in the changelog if that's the case ;-)
User3: the first (main) patch is from redhat, the auto* changes I did, and there's a patch I did to clean up the ui a little
User6: ok
User3: the hard part was getting the changes into the gnomedesktop lib such that everything linked to it properly
User6: User3 your new capplet seems to be working but I just broke my session using it :-p
User6: I did rotate the screen
User3: I've found it certainly offers a good way to test for xrandr bugs ;-)
User6: but now it doesn't take any click or keyboard event
User3: sounds like a known xrandr bug
User3: fwiw, rotation worked 100% on all of the systems I tested on.
User6: lucky you :-p
User3: one system has problems when scaling up or down
User3: maybe we should include a note on the dialog, "Um, maybe save your work first?"
User6: rather "backup your disk"
User6: because restarting xorg doesn't fix the issue
User6: I've no a broken session and no way out of the command line to fix it
User3: the issue I ran into required a reboot
User6: that's not good
User6: well, it's applying the rotation on login
User6: which seems to be an issue
User3: hrm yeah
User6: where is the config file?
User3: ~/.gnome2/monitors.xml
User6: thanks
User6: fixed
User3: there should be a confirmation dialog like displayconfig-gtk has
User6: I've to go for diner but I've g-c-c ready for upload
User6: will upload later
User3: ok
User6: having what the previous capplet had would be nice
User3: I'll look into that next week
User6: a counter which reverts if you don't ack
User6: cool
User3: yeah displayconfig-gtk had that as well
User6: otherwise good work, it looks cool ;-)
User3: great
User3: did it get your monitor name correct?
User1: New bug: #197069 in xserver-xorg-video-amd (main) "xserver-xorg-video-amd: wide resolutions don't work" [Undecided,New] https://launchpad.net/bugs/197069
User8: re
User8: User3 still around?
User3: yup
User8: I uploaded gnome-control-center
User3: yay!
User8: xrand is really buggy on my dell laptop though
User8: rotation breaks xorg in a way I've to switch to a vt and edit the xml by hand to get xorg working again
User3: aside from the rotation, are you seeing other issues?
User8: and changing resolution corrupts part of the screen
User3: seb128I will put a note in the dialog on how to restore
User8: yes, changing to 800x600 worked correctly, switching back to 1440x900 doesn't
User8: I get what looks like a working 800x600 area
User3: right, that is one of the bugs I ran into on one of my systems that I mentioned
User8: and a corrupted border on right and bottom which is not usuable
User8: I expect intel to be not too buggy ;-)
User3: and you can move the mouse into those areas, and interact with buttons located there
User8: expect intel not too by too buggy rather
User8: yes
User8: but I can't move things there
User3: yup, that's the same bug I found - jdub also reported it earlier, but identified it as a metacity bug
User3: he tried running a different window manager and it worked correctly
User8: compiz consider the corruption border as the viewport limit and will switch to next one
User8: I'm using compiz
User3: yeah mine was with compiz as well.
User8: ok
User8: I think I've done my part for this week now that those packages are uploaded
User8: I'll let you figure the xrandr issues ;-)
User3: so maybe check if the same thing happens with metacity - if not, then it may be a compiz bug
User3: yup
User8: let me know if you need debug informations
User8: well, you said jdub had the issue using it
User3: sure, thanks, yep I'm working on the xrandr issues
User8: cool, thanks
User8: and again, nice work ;-)
User8: out of the xrandr bugs the capplet looks great
User3: the rotation one is well known; this other one I've not seen reported but I can reproduce it easily, so...
User3: good to hear
User3: still needs a few more features, but good enough for hardy.  Much better than what we've had
User8: right
User3: User2 btw I have a new patch to extend the "greedy" fix to all intel chipsets here - http://people.ubuntu.com/~bryce/Uploads/
User8: User3 btw you come you don't use a ppa for your uploads?
User3: User2 but I'm not certain yet if it's appropriate to do that, or if it would cause more issues
User3: User8 I should start using that, I just have my workflow set up for doing local builds mostly
User8: well,; you copy those on rookery apparently though
User8: so you could as easily dput them on launchpad ;-)
User3: yep
User3: can you delete things from a ppa?
User9: User2 hm, what happend to the nvidia-settings that used to be part of nvidia-glx (-new) ? is that now all folded into the nvidia-settings package?
User10: User3 yeah, it's on the left side, 2nd action down, IIRC.
User2: User9 yep
User11: tjaalton, why did that happen?
User2: User3 ok, maybe after the weekend?
User2: User11 because it has source
User11: oh fair enough :)
User3: User2 sure
User3: User2 I may have more user reports on it by then
User2: User11 but now that the default xorg.conf has a ServerLayout section again, it's not a problem anymore.. without that it would just crash
User3: heya keescook
User2: man, I'd love to see fglrx banished from the archive when r5/6xx has 3D support
User11: tjaalton, there are similar problems with aticonfig not liking the default xorg.conf (when trying aticonfig --initial)
User11: i've reported them to the beta team
User2: User11 yep
User2: well, jockey should have a cmdline interface, then every doc should mention that aticonfig/nvidia-xconfig are Evil
User9: User2 hm, I use it in compiz to detect the available video ram, any chance to get it back ?
User11: well there features of the AMD driver that are not exposed via any other public interface
User2: User9 maybe by depending on it
User9: User2 its universe currently, but that shouldn't be too much of an issue - but let me dig a bit into it, maybe there is a different way to get the video ram
User10: heya bryce :) I just happened to catch your question :)
User2: User9 btw, jockey still disables composite for fglrx, but apparently composite still has some issues..
User9: User2 I can give it a try early next week - I can't wait to see fglrx go
User3: User2 do you seriously think we may be able to drop fglrx?  that'd be rather stunning.  I hadn't realized things had progressed that far already
User2: mvo, User3 no, we are not there yet :)
User2: unfortunately
User9: User2 the "ati" driver works quite well with the r500 now in 2d, randr, suspsend all of this is good for me
User9: (well, radeon)
User2: 3D support is still very much a work in progress..
User2: maybe intrepid+1..
User2: r5xx docs are out, so maybe intrepid will have a mesa which supports it
User2: User3 the archive has 2.2.1-1ubuntu2 ;)
User3: ah, hmm
User3: User2 I'll rework the patches then.  I also have another quirk to add
User2: User3 yep, saw that one
User3: http://bryceharrington.org/drupal/display-config-1
User2: looks nice
ubuntu-x
Ubuntu IRC