[00:29] <bryce> yay xserver 1.5 is out
[00:43] <pwnguin> relevant to intrepid?
[01:03] <bryce> the changes are fairly modest, I think once the alpha-5 freeze is over it'd worth including, just for officialness
[01:03] <pwnguin> heh
[01:03] <pwnguin> well, im all for new
[01:03] <bryce> I suspect it's mostly bugfixes but only skimmed the changelog
[01:04] <pwnguin> but mdz did get a bit loud when the kernel team decided .27 was the future
[01:22] <bryce> ah, but the decision to do xserver 1.5 was made way back at UDS Prague well before Intrepid began
[01:22] <bryce> we've just been waiting for it to officially release
[01:22] <bryce> plus, the change from 1.4.99.906 to 1.5.0.0 is quite minor
[01:23] <bryce> we've been running with the xserver beta for quite some time.  Whereas with the kernel they were running with the stable .26 version and the jump to .27 is pretty significant (but still a good idea imho)
[01:23] <pwnguin> alrighty then. remember this when the mdz arrives ;)
[01:24] <pwnguin> i wonder why the kernel wasn't .27 from the start
[01:57] <Awsoonn> to take advantage to the restriced drivers / duelhead will I still need an Xorg.conf? I see in teh log that it detected and loaded the nv module, but appears to not be using it....
[01:59] <pwnguin> nv or nvidia?
[02:00] <Awsoonn> xorg isreporting loading nv
[02:01] <jcristau> it's not the blob, then
[02:05] <Awsoonn> so will I need the 'ol xorg.conf afterall then?
[02:06] <pwnguin> theres' been consideration of a patch that will load nvidia over nv (when nvidia is installed)
[02:08] <jcristau> that's only sensible if the fallback is fixed
[02:08] <jcristau> right now, it isn't, so nv is the safe bet
[05:12] <Awsoonn> should jockey detect my nvidia card and install the nvidia driver for me in intrepid after an upgrade? or is it not working just yet?
[06:04] <tjaalton> of course we'll get 1.5.0 in intrepid.. it's nice for a change to have an actual release in the distro >:P
[06:05] <tjaalton> that reminds me.. it should be fine to merge with lenny to get a proper release in hardy too
[06:06] <bryce> evenin' tjaalton
[06:07] <tjaalton> hey bryce

[06:07] <bryce> not feeling well?  sorry to hear
[06:08] <tjaalton> yeah, well my chair at work is pretty comfortable.. but smells bad
[06:08] <tjaalton> should only get there first ;)
[06:09] <tjaalton> hum, so videoabiver has been bumped again, rebuild madness it is then :)
[06:09] <bryce> erf
[06:09] <bryce> tjaalton: btw I wrote up a page to document quirks (only one detailed so far):  https://wiki.ubuntu.com/X/Quirks
[06:10] <tjaalton> ah thats good.. I've looked at intel a couple of times and there seemed to be some obvious quirk-cabable bugs
[06:10] <tjaalton> but didn't know how to write one
[06:25] <tjaalton> Awsoonn: depends on your chip. if it's old enough jockey won't offer the blob because the old versions don't work with the new xserver
[06:26] <tjaalton> so no point in breaking your system
[07:06] <bryce> tjaalton: yeah I've got it on my todo list to document each of the intel quirks.  There's only 2-3 I actually understand currently
[07:07] <bryce> well, "totally understand".  Most of them I can guess what they do, but just not what situations they apply to exactly.
[07:08] <bryce> tjaalton: don't remember if I mentioned already that I did up a patch to add quirking logic to -ati  for AGP incompatibilities, so we can set AGPMode to specific values on a hw-specific basis
[07:09] <bryce> looking through our bug tracker I think a huge proportion of our -ati bugs might be fixable with this quirk
[07:12] <tjaalton> yeah that could be
[10:19] <tjaalton> is $2 fed to $foo.postinst the version being replaced?
[10:20] <jcristau> if $1 is configure, yes
[10:21] <tjaalton> ok thanks
[10:21] <tjaalton> need to clean up /etc/X11/Xsession.d/*xorg-common* in x11-common.postinst..
[10:22] <tjaalton> used to be in xinit on dapper
[10:24] <tjaalton> maybe comparing versions is overkill.. just check if the files are there and remove
[10:24] <jcristau> ideally you'd check whether they're modified
[10:27] <tjaalton> how to do that?
[10:28] <jcristau> remove_conffile_* in xsfbs.sh
[10:28] <tjaalton> ah
[10:28] <jcristau> or http://wiki.debian.org/DpkgConffileHandling
[10:30] <jcristau> that said, these files are so old it might be ok to just remove them..
[10:30] <jcristau> not sure
[10:31] <tjaalton> the md5sums aren't available, so I guess remove_conffile doesn't work then? just removing should be fine, yes
[10:31] <jcristau> weird. dpkg is supposed to keep the md5sums in its status db until the package is purged/
[10:31] <jcristau> s,/,.
[10:32] <tjaalton> in $pkg.md5sums?
[10:32] <jcristau> in /var/lib/dpkg/status
[10:32] <tjaalton> oh, status db
[10:32] <tjaalton> yeah, there they are
[10:33] <tjaalton> ok so I'll use that
[10:33] <tjaalton> maybe
[10:35] <tjaalton> yes, because it's simple
[10:39] <jcristau> xutils uses that if you want an example. remove_conffile_lookup in preinst install|upgrade, _rollback in postrm abort-*, _commit in postinst configure
[10:45] <tjaalton> ok so in this case r_c_l xinit "foo", since it was in xinit
[10:45] <jcristau> right
[10:46] <tjaalton> oh you have to run all three.. ok
[10:48] <tjaalton> hmm, I don't think in this case the rollback is needed
[10:51] <tjaalton> unless it's backported to the hardy package
[11:01] <tjaalton> ok I think it's ready
[11:33] <tjaalton> fixed the package versions and pushed it for testing on my PPA
[12:33] <Awsoonn> tjaalton: I guess old is relitive, my card is a 6800GT, is this goign to be broken in the new X server by chance?
[12:36] <tjaalton> Awsoonn: no, the latest driver should support that
[12:37] <Awsoonn> tjaalton, so would you happen to know hwo I can debug jockey to see why it thinks I don't want the blob?
[12:38] <tjaalton> Awsoonn: I think tseliot is your man for the job :)
[12:39] <Awsoonn> will ping~ Thanksl
[15:28] <soren> Remind me again: Why is it that the default Display "Virtual" setting isn't 10000x10000 so that side-by-side monitor things are just an xrandr call away?
[15:28] <pwnguin> if i were to hazard a guess
[15:28] <tjaalton> because otherwise you'd have a large desktop to scroll around?
[15:28] <pwnguin> it'd be related to the amount of video ram such insanity would allocate?
[15:28] <soren> tjaalton: Erm.. no?
[15:29] <tjaalton> ok :)
[15:29] <soren> tjaalton: That's the viewport setting, surely?
[15:29] <jcristau> soren: because otherwise you wouldn't have 3d
[15:29] <jcristau> software gl is slow
[15:29] <jcristau> plus, that would use a massive amount of memory
[15:29] <tjaalton> soren: right..
[15:29] <soren> jcristau: Wouldn't that only become a problem when I actually start using the extra virtual space?
[15:29] <jcristau> soren: no
[15:29] <soren> jcristau: Ok.
[15:32] <soren> jcristau: Just curious: Is this considered a bug? I mean... I would seem better to me if adding an extra monitor and being able to just extend your desktop onto it with xrandr would be possible, but perhaps I'm missing something.
[15:32] <soren> s/I would/It would/
[15:32] <jcristau> yes, it's considered a bug
[15:32] <soren> Ok.
[15:32] <jcristau> it's also hard
[15:32] <soren> Oh, no doubt.
[15:32] <soren> I'm deeply impressed by what xrandr does already.
[15:32] <soren> Err..
[15:33] <soren> XRANDR, that is.
[15:33] <jcristau> http://lists.freedesktop.org/pipermail/xorg/2008-September/038180.html
[15:33] <soren> xrandr isn't so spectacular in itself :)
[15:33] <jcristau> if you're interested
[15:34] <soren> I wouldn't mind sacrificing 3D capabilites on the altar of dual-head setups.
[15:46] <tseliot> soren: thanks to the work which I'm doing with bryce on the gnome-control-center all you will have to do is apply your settings, let it set the virtual resolution for you (if you wish so), log out and log in.
[15:47] <tseliot> of course you will still lose direct rendering
[15:47] <tjaalton> but only if the size is bigger than the chip supports?
[15:48] <tseliot> tjaalton: yes, of course
[15:48] <soren> tseliot: Lovely.
[15:48] <tseliot> tjaalton: i.e. bigger than the current framebuffer
[18:30] <tjaalton> bryce: http://lists.freedesktop.org/archives/xorg/2008-April/034582.html
[18:31] <bdmurray> bryce: I think I'm reading to validate a series of xorg.conf files.  Is there a package with a small number of bugs I could test with?
[18:34] <tjaalton> bryce: so if we drop xorg.conf it should work
[19:10] <tjaalton> or at least the driver section..
[19:13] <bdmurray> I got impatient and I'm checking all the xserver-xorg-video-mga bugs
[19:14] <tseliot1> bdmurray: you might find a lot of interesting stuff in the reports assigned to nvidia-glx
[19:14] <tseliot1> maybe too much stuff
[19:15] <bdmurray> I wanted to test a package with a small number of bugs first to make sure everything is working right
[19:15] <bdmurray> Then I'll get crazy!
[19:15] <tseliot1> ah ok
[19:17] <bryce> bdmurray: xserver-xorg-video-nv probably doesn't have an overwhelming number
[19:34] <bdmurray> bryce: would also checking "closed" bug be helpful?
[19:34] <bryce> bdmurray: nope, only open ones
[20:38] <bdmurray> bryce: so looking at bug 5801 - which as an invalid xorg.conf - I'm not certain the best way to establish a relationship between my comment and the problematic xorg.conf
[20:39] <bryce> looking
[20:40] <bdmurray> The problem deals with the fact that 2 attachments could have the same name and the attachments aren't easily distinguishable
[20:42] <bdmurray> There are some numbers in the librarian url and in the edit url for the attachment but those are easy to find etc....
[20:42] <bryce> maybe just list the URL to it?  Or refer to the comment# that it was associated with
[20:43] <bdmurray> Got it, I'll just add an additional link to the librarian url
[20:45] <bryce> cool
[20:49] <bdmurray> in the comment I add - sound good?
[21:41] <tjaalton> bryce: yay, driver fallbacks do indeed work
[21:43] <bryce> awesome
[21:43] <tjaalton> http://launchpadlibrarian.net/17291373/Xorg.0.log (from bug 261977
[21:45] <tjaalton> it's kinda built in the xserver already.. no new magic needed, if the conf had multiple driver sections it would try them one by one until it works
[21:46] <tjaalton> so.. this should make failsafe quite a bit more straightforward
[21:48] <bryce> awesome
[21:48] <bryce> wait I said that already
[21:48] <tjaalton> hehe
[21:48] <bryce> is there any additional work you see we need to do to polish it up?
[21:50] <tjaalton> well I'd like to make sure if it's enough to just not have any Device-sections in xorg.conf
[21:50] <tjaalton> if not, there should be another way to feed options
[21:51] <tjaalton> like NoLogo for nvidia, Virtual for dualhead etc
[21:52] <tjaalton> maybe if there would be xorg.conf.d/ with files that are sourced, so that they could replace or add stuff to the default, generated configuration
[21:52] <tjaalton> (that's not a new idea)
[21:53]  * bryce nods
[21:54] <bryce> hmm
[21:54] <bryce> however on the other hand, Virtual will be going away sooner or later
[21:54] <tjaalton> well yes
[21:54] <bryce> also alberto's x-kit will be handling flipping on/off options
[21:54] <tjaalton> but if there's xorg.conf this fallback-stuff won't work
[21:55] <tjaalton> at least that's what I fear
[21:55] <tjaalton> a really hacky way would be to modify dexconf to add all the device sections
[21:56] <tjaalton> but that's... ugly
[21:56] <tjaalton> going back to the 90's
[21:57] <bryce> hmm
[22:00] <tjaalton> heck, I'll try the deb myself
[22:01] <tjaalton> hrm, gotta love (un)reliable power management with .27
[22:02] <bryce> :-/
[22:03] <bryce> yeah my laptop has started hanging on suspend/resume again
[22:03] <bryce> for a while there it was working reasonably reliably
[22:04] <tjaalton> yeah for me too
[22:04] <bryce> honestly I've been having a LOT of problems since about alpha-3/4
[22:05] <bryce> jumpy mouse pointer, flickering on starting/stopping gnome apps, boots successfully only 50% of time, strange screen corruptions, suspend/resume issues...
[22:06] <bryce> it's a bit disheartening
[22:06] <bryce> but... gives me something to do for the next month ;-)
[22:06] <tjaalton> sounds familiar.. the flickering/mouse jumping are related, somehow 945/965 are on other sides of the fence; fix one and the other breaks
[22:08] <tjaalton> although I haven't seen the flickering on 965, but mouse jumping stopped after applying the latest patch. although that made the mouse jump on 945
[22:08] <bryce> mm, yeah I last updated it friday so maybe there's a fix
[22:08] <bryce> oh, also I'm seeing the screensaver failing to come on again
[22:09] <bryce> I also can't say I'm a fan of the new power switch, where you have to go back to the gdm screen in order to shut the system off
[22:09] <bryce> since suspend/resume doesn't work, it adds extra work to shutting down the machine
[22:10] <tjaalton> yeah that sucks big time
[22:10] <tjaalton> but the new user-switch applet has an option to shutdown directly
[22:10] <bryce> oh does it?  I played with that only briefly, I'll look closer
[22:12] <tseliot1> bryce: if you click on the User Switcher in the gnome panel you can select shutdown. This should save you some time
[22:15] <tjaalton> ok, verified that the server doesn't use built-in configuration if it can find the system xorg.conf
[22:38] <tjaalton> and I think there's a simple way to use the failsafe even if you had an xorg.conf that has issues for whatever the reason.. just move it aside like now, but don't generate a stub file but use the server defaults like normally