[05:03] <bryce_> tjaalton: mind reviewing the debdiffs on bug 260138 before I upload them?
[05:03] <ubottu> Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Wishlist,In progress] https://launchpad.net/bugs/260138
[05:37] <tjaalton> bryce_: heh, they both are the same :)
[05:43] <bryce_> erk
[05:44] <bryce_> I'm such a moron.  right one uploaded now
[05:47] <tjaalton> hmm, the git version already has xsfbs
[05:48] <tjaalton> actually I was looking at the package, not  git.. wonder why the diff shows it
[05:50] <tjaalton> the bits start from 0, so 8 would be enough?
[05:51] <tjaalton> rather confusing..
[05:55] <tjaalton> it should work as is, and allow to bump it to 1024 if needed AIUI
[05:55] <tjaalton> the limit
[05:57] <bryce_> ok
[06:05] <bryce_> alright, I'll upload this once we're unfrozen
[06:06] <bryce_> tjaalton: I can update you on some discussions/decisions at the sprint.
[06:06] <bryce_> pgraner and I talked about moving x to vt1
[06:07] <bryce_> for jaunty+1 most likely
[06:07] <bryce_> so vt 1 == x, 2 == login console, 3 == log messages
[06:08] <bryce_> for demoting fglrx for jaunty+1, a criteria that was raised was to be sure that 3d games like sauerbrauten work with -ati first.
[06:09] <bryce_> if we can show that 3d games work fine now with -ati it would greatly help justify refocusing to just -ati
[06:10] <bryce_> seb128 and I discussed removing the gnome 96 dpi, which is now done.  we've got some feedback from users who noticed it right away.  it doesn't seem to be wrong, just considerably different than they're used to.  So I put a note in release notes about this, and how to customize it.
[06:11] <bryce_> I've been helping people test out uxa a good bit.  seems like 50/50 whether it works vs. not
[06:12] <bryce_> I talked to timg about 320813.  he's got the patch for drm but wants to wait for the upstream discussion to be resolved first before incorporating it
[06:12] <bryce_> meanwhile a LOT of people have reported this problem to me so far
[06:36] <bryce_> xserver changes pushed to git.
[06:37] <tjaalton> bryce_: ok, cool
[06:37] <tjaalton> yeah the r6/7xx stuff needs to land in mesa first
[06:37] <tjaalton> but I believe that'll happen in time for j+1
[06:39] <tjaalton> about that bug.. maybe the cleanest solution would be to disable vblank again, since it doesn't seem like jbarnes/mrcooper will reach a consensus anytime soon. hope that I'm wrong :)
[06:41] <tjaalton> UXA/DRI2 already disables vblank for some reason
[06:41] <tjaalton> so that's why people aren't seeing the problem with it
[07:08] <Alexia_Death> Isnt just one login console a bit little?
[07:08] <tjaalton> you can have more if you need
[07:09] <tjaalton> or use screen
[07:09] <Alexia_Death> Well, couldnt it be 1-x 2-log 3-5 logins?
[07:10] <Alexia_Death> Configuring more is sort ofa pita. moving X to 1 makes sense tho.
[07:10] <tjaalton> every getty consumes memory, so one is enough
[07:10] <Alexia_Death> :/
=== maxb_ is now known as Guest77609
=== Guest77609 is now known as maxb
[17:28] <superm1> tjaalton, ping.  102-fedora-vesa-1.3.0-range-hack.patch fixes bug 315588 for me
[17:28] <ubottu> Launchpad bug 315588 in dell "[Unknown 14] Hardware w/ 1600x900 LCD does not boot up using vesa" [Medium,Confirmed] https://launchpad.net/bugs/315588
[17:28] <superm1> tjaalton, i just got ahold of that hardware again and tested it
[17:29] <superm1> why did you think it was able to be dropped back in intrepid?
[18:24] <superm1> bryce, do you know remember why timo had recommended dropping that 102-fedora-vesa range hack patch in the first place?
[18:31] <BUGabundo> I'm one of those afected by the HUGE DPI (https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts). against what package should I file it ?
[20:33] <tjaalton> superm1: probably because fedora dropped it
[20:34] <superm1> tjaalton, there is no explanation as to why fedora dropped it from what i can find in their changelogs
[20:34] <superm1> i'm wondering if it was just an oversight
[20:36] <tjaalton> superm1: well, maybe ajax knows the history. it's not the first time they'd drop patches without mentioning it :/
[20:36] <superm1> tjaalton, but if that's the only reason it was dropped, i'd prefer to put it back in so that this hardware will work again on live disks, at least until upstream has something better
[20:45] <tjaalton> superm1: try without xorg.conf if you can
[20:48] <superm1> tjaalton, same results, no X startup,  (VESA(0): No valid modes)
[20:49] <tjaalton> could you attach the log to the upstream bug, and check the mimetype this time :)
[20:49] <tjaalton> 22:49 < ajax> oh, blah.  yeah, the sync range stretch isn't there anymore.
[20:49] <superm1> tjaalton, sure
[20:53] <tjaalton> 22:49 < ajax> wonder what i was thinking.  if you get to that point in mode validation it's  probably the sane thing to do
[20:53] <tjaalton> so, you'll get a new patch in a minute
[20:53] <superm1> tjaalton, awesome
[21:18] <tjaalton> superm1: ok, check 817fb65fc3a95d6c34952f241c92ba2d3760968e from vesa git master
[21:18] <tjaalton> http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/commit/?id=817fb65fc3a95d6c34952f241c92ba2d3760968e
[21:18] <tjaalton> untested of course
[21:21] <superm1> right. doing a build right now
[21:22] <superm1> tjaalton, yup I get X  with said patch :)
[21:22] <tjaalton> marvellous :)
[21:23] <superm1> want me to upload?
[21:23] <tjaalton> sure
[21:29] <superm1> okay uploaded. tjaalton thanks for bugging ajax and  getting that turned around so quickly :)
[21:30] <tjaalton> superm1: np, thanks for raising this.. :)
[21:30] <tjaalton> I believe there are dupes to be closed..