[03:05] <ubotu> New bug: #206937 in xserver-xorg-video-ati (main) "Extended desktop not working on x1400" [Undecided,New] https://launchpad.net/bugs/206937
[03:35] <ubotu> New bug: #206945 in xserver-xorg-video-ati (main) "No Xvideo on x1400" [Undecided,New] https://launchpad.net/bugs/206945
[05:35] <ubotu> New bug: #205599 in xorg-server (main) "Firefox crashes on Xbox.com's Friends List" [Undecided,Confirmed] https://launchpad.net/bugs/205599
[05:35] <ubotu> New bug: #206963 in xserver-xorg-input-evdev (main) "[hardy] MX1000 mouse horizontal tilt is inverted" [Undecided,New] https://launchpad.net/bugs/206963
[05:45] <ubotu> New bug: #206968 in xserver-xorg-input-evdev (main) "Logitech "Cruise Control" buttons exhibit extra button events" [Undecided,New] https://launchpad.net/bugs/206968
[06:00] <ubotu> New bug: #206974 in xserver-xorg-input-mouse (main) "mouse scroll delay in first person shooters" [Undecided,New] https://launchpad.net/bugs/206974
[06:29] <tjaalton> bryce: I'll update the fglrx part of the driverstatus wiki
[06:29] <tjaalton> and nvidia
[06:33] <tjaalton> regarding fglrx modules; that's what lrm is for, building/linking the modules against current kernel interfaces
[06:37] <tjaalton> I'm downloading F9beta just for the heck of it :)
[06:41] <bryyce> ok cool
[06:56] <ubotu> New bug: #206984 in xorg (main) "Wrong dpi in hardy when second monitor is disabled" [Undecided,New] https://launchpad.net/bugs/206984
[08:30] <ubotu> New bug: #206998 in xserver-xorg-video-intel (main) "Screen splited when changing monitor resolution settings " [Undecided,New] https://launchpad.net/bugs/206998
[08:35] <ubotu> New bug: #206999 in xserver-xorg-video-intel (main) "[Hardy beta] External screen goes suddenly blue with Intel 945GM" [Undecided,New] https://launchpad.net/bugs/206999
[09:06] <seb128> hey bryce
[09:07] <seb128> bryce: was the meeting yesterday? I totally forgot about it yesterday evening, I was around but didn't join the chan
[09:08] <tjaalton> seb128: it was probably cancelled
[09:08] <seb128> tjaalton: not enough board members there? 
[09:08] <bryyce> seb128: no worries; none of the tech board members showed up
[09:09] <seb128> ok
[09:09] <tjaalton> them meeting was not on the fridge calendar though
[09:09] <tjaalton> er, "either"
=== jcristau_ is now known as jcristau
[14:36] <ubotu> New bug: #104191 in linux-restricted-modules-2.6.22 "[needs-packaging] AVM Fritz! WLAN USB Driver" [Wishlist,Confirmed] https://launchpad.net/bugs/104191
[16:21] <ubotu> New bug: #207184 in xserver-xorg-video-intel (main) "compiz: artifacts when transforming videos" [Undecided,New] https://launchpad.net/bugs/207184
[17:06] <ubotu> New bug: #207215 in linux-restricted-modules-2.6.20 "geforce 7800 defaults to vesa but works with nv driver" [Undecided,New] https://launchpad.net/bugs/207215
[17:23] <ubotu> New bug: #207209 in xorg (main) "{Hardy} Xorg not loading "nv" driver" [Undecided,New] https://launchpad.net/bugs/207209
[17:24] <ubotu> New bug: #207227 in linux-restricted-modules-2.6.24 (restricted) "Garbage displayed after login and before desktop appears" [Undecided,New] https://launchpad.net/bugs/207227
[17:51] <ubotu> New bug: #207245 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx-new 100.14.19+2.6.22.4-14.10 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/207245
[17:56] <ubotu> New bug: #207246 in xorg (main) "Integrate Fedora's One Second X fixes" [Undecided,New] https://launchpad.net/bugs/207246
[19:31] <ubotu> New bug: #207294 in linux-restricted-modules-2.6.24 (restricted) "compiz.real crashed with signal 7 in event Loop() and fglrx driver doesn't work in 64 bit version of Ubuntu 8.04 beta (dup-of: 191365)" [Undecided,New] https://launchpad.net/bugs/207294
[19:36] <ubotu> New bug: #206049 in xserver-xorg-video-intel (main) "X.org and all tty killed randomly, computer nearly unusable" [Undecided,New] https://launchpad.net/bugs/206049
[20:48] <bryce> tjaalton: btw, komputes wants to have us bring back the xorg video dpkg-reconfigure stuff
[20:49] <tjaalton> bryce: yep, I asked him to join this channel
[20:50] <bryce> tjaalton: what are your thoughts?  I'd sort of prefer to stay in sync with debian, but I could go either way
[20:50] <tjaalton> no need to go back
[20:51] <tjaalton> imho
[20:51] <bryce> for users having trouble configuring things, what would you configure they do?
[20:53] <bryce> heya komputes
[20:53] <komputes> hiya bryce I was just talking to tjaalton about bringing back a very supportable feature in X
[20:53] <komputes> http://ubuntuforums.org/showthread.php?p=4592476
[20:54] <komputes> https://bugs.launchpad.net/ubuntu/+bug/203940
[20:54] <ubotu> Launchpad bug 203940 in ubuntu "Intel Santa Rosa - No Video, could not configure X, cannot start GDM" [Undecided,New] 
[20:54] <komputes> klet me give you the use case
[20:54] <komputes> 1) I install ubuntu Hardy 8.04 when it come out in 29 days
[20:54] <komputes> 2) Get a black screen
[20:54] <tjaalton> =bug
[20:55] <komputes> 3) dpkg-reconfigure -phigh xserver-xorg
[20:55] <komputes> skips over video configuration
[20:55] <komputes> I don't have more than one computer, can't report a bug
[20:56] <komputes> the driver is included just not prooperly selected, I can change it but now the user-interactive (bluescreen method) is gone so I'm at a loss, I have to re-write xorg.conf
[20:57] <komputes> Can we have two command, one that will configure automatically, and one which reverts back to the old method of configuring (if the installer is erroneous in detecting video card driver, monitor refresh rate etc)
[20:58] <tjaalton> it's not practical to bring back the old debconfage
[20:58] <komputes> If you read the forums you will see that many people agree that this is something which has broken a supportable model. You cannot expect people to report a bug for all hardware that is not auto detected.
[20:58] <tjaalton> your hardware was detected alright
[20:58] <komputes> what do you mean by "not practical" - it is not practical for the canonical support team to be spelling out every letter of an xorg.conf file
[20:58] <tjaalton> it's just that it drives the wrong output
[20:59] <tjaalton> it was a lot of code that was dropped
[20:59] <bryce> largely buggy code
[20:59] <komputes> tjaalton: as long as the automatic xorg configuration tool is erroneous it should stay in testing stage
[21:00] <komputes> seriously this is going to be such a headache to support an LTS which this kind of xorg configuration. And we are only going to be able to fix on 8.10
[21:00] <komputes> community agrees, canonical support dept agrees
[21:00] <tjaalton> komputes: how do you feel it is erroneous? the bug you mentioned surely is using the right driver, so which driver would you choose by running dpkg-reconfigure?
[21:01] <komputes> not to mention xorg training which will have to be re-writen
[21:01] <komputes> tjaalton: I had to rewrite xorg.conf like many users just because I was using hardy, that's no right.
[21:02] <tjaalton> so what did you change?
[21:02] <komputes> i copied an xorg.conf file from another computer and rewrote the entire Device section for the video card
[21:02] <komputes> tjaalton: look at the forum URL I posted, many people are experiencing the same issue
[21:04] <komputes> and if we can do anything it is in the next 29 days, so i'm just trying to apply some pressure.... bring back "dpkg-reconfigure -phigh xserver-xorg" and have an "automated choice" such as dpkg-reconfigure -phigh --auto-detect xserver-xorg
[21:05] <tjaalton> you still haven't shown how writing 'Driver "foo"' in the conf is any better than letting the server pick foo
[21:05] <komputes> tjaalton: you have experience with code, I have experience with support. I tell you that the way it is now is not a supportable model. I totally agree that the detection should be automated but if it it not automatically detected there should be a fallback method of reconfiguring xorg.conf
[21:05] <komputes> tjaalton: let me give you another use case then
[21:06] <komputes> 1) I just installed a new video card
[21:06] <komputes> 2) wow, xorg works and detects the card, great, ubuntu rocks
[21:06] <komputes> 3) the possible resolutions are not all there
[21:06] <komputes> dpkg-reconfigure
[21:07] <komputes> oh noes, the resolutions are skipped over. game over
[21:07] <tjaalton> if you had intel, ati or recent nv it wouldn't work anyway
[21:07] <tjaalton> since they use randr-1.2 which skips "Modes" altogether
[21:08] <komputes> or let's say it's the refresh rate that was badly detected (of my monitor) I can't see X/GDM - i have 2 choices xorg.conf manual configuration or dpkg-reconfigure
[21:08] <komputes> on Hardy I have one choice -> xorg.conf manual configuration
[21:08] <komputes> how would you solve this issue tjaalton 
[21:09] <tjaalton> fix the bugs in the drivers?
[21:09] <komputes> I can't, no GUI
[21:09] <komputes> I can't even submit a bug report, no GUI
[21:10] <komputes> I fear this will be an Ubuntu "turn-off" for new users, although it is an attempt to do the opposite 
[21:11] <tjaalton> I don't see new users running dpkg-reconfigure
[21:11] <komputes> call up Canonical tech support and ask them what to do
[21:11] <komputes> it's the FIRST thing they learn
[21:12] <tjaalton> we've come this far without any public outcry, so I don't think it's _that_ common
[21:13] <komputes> by the way "fix the bugs" is not in a user's hands as a SOLUTION
[21:13] <tjaalton> I didn't mean it like that
[21:13] <tjaalton> but generally
[21:14] <komputes> tjaalton: you don't realize but this, ME, here telling you this as well as the people of this thread http://ubuntuforums.org/showthread.php?t=735118
[21:14] <komputes> 467 VIEWS in 24 HRS - that shows there is an issue
[21:15] <seb128_> views are not a good indicator
[21:15] <komputes> seb128_: read the posts, thats a good indicator
[21:15] <seb128_> not really sure
[21:16] <komputes> seb128_: did you read the thread?
[21:16] <seb128_> forum tend to be verbose and have users who complains between them
[21:16] <tjaalton> apparently metacity compositing is nearly as critical
[21:16] <komputes> seb128_: go on now read it, it's important
[21:16] <seb128_> komputes: you will not get a topic where people will not complain
[21:16] <seb128_> you can try with any change from this cycle
[21:16] <seb128_> or any other cycle
[21:17] <komputes> seb128_: I have many times
[21:17] <seb128_> you will always have some users ranting
[21:17] <komputes> seb128_: when users talk developers should listen - i agree the rant about nvidia crap is BS, but it's a good use case, everyone on there is saying bring back the capabilities found in gutsy when running dpkg-reconfigure
[21:18] <bryce> most of the complaints I've seen have been about problems that are long since fixed
[21:18] <seb128_> komputes: users complains about everything, you can't listen to so much noise
[21:18] <komputes> ok, let me ask you guys a question, what is the benefit of doing it your way?
[21:19] <bryce> komputes: seriously, we were dealing with many more bugs where the old system mis-configured things, than now
[21:20] <bryce> komputes: and dpkg-reconfigure was always hated when we recommended it.  People always would moan, "This should be autoconfigured, you can't expect a new user to know to run a command line tool to make their xorg work, this isn't a good solution."
[21:20] <seb128_> komputes: the thing is that your threads will get the complains for the nnn people who have issues due to the changes but will not get good comments for the several*nnn users for who things are working better
[21:20] <bryce> so, we listen and focus our efforts into fixing the actual bugs.
[21:21] <komputes> totally agree, it should be autoconfigured, but the manual config should not be sacrificed for it
[21:21] <seb128_> komputes: so you can always say "look those users are ranting", but you just didn't notice the magnitude change or looked at who was complaining before
[21:21] <tjaalton> komputes: btw, try Fedora9, it doesn't even list the device section on the xorg.conf anymore :)
[21:21] <bryce> in a way it's better to have the complaints NOW, and work through the bugs and get the autoconfiguration solidified, than to rely on workarounds that just hide the issues so users don't bother reporting them
[21:22] <komputes> bryce: I fear the autoconfiguration will not (for a long time) be solid, but let's talk in a year
[21:24] <komputes> bryce: but you do realize that a user who does not see the login screen/live cd will most likely give up and not manually reconfigure xorg.conf to be able to log a bug about fixing his video driver autodetection
[21:24] <seb128_> komputes: you realise that those users will not like go on a command line run dpkg-reconfigure either, right?
[21:24] <seb128_> s/like/likely
[21:24] <komputes> seb128_: they will
[21:24] <seb128_> some power users will
[21:24] <komputes> many many will
[21:24] <seb128_> but most of the what we call users won't
[21:25] <komputes> where xorg.conf make reference to another document where the xorg configuration is kept
[21:25] <seb128_> your many many is small magnitude of power users
[21:25] <seb128_> no win user I know will use a command line if I give an ubuntu cd to try
[21:25] <seb128_> either it works or ubuntu lose anyay
[21:25] <seb128_> anyway
[21:26] <seb128_> no normal non technical user is wanting to go on a command line to fix things
[21:26] <seb128_> and technical users will adapt to new ways to get things working
[21:26] <tjaalton> like, man xorg.conf
=== seb128_ is now known as seb128
[21:29] <komputes> I have been reading xorg.conf documentation for a while now, I was not able to determine where xorg.conf stores the configuration for a "Configured Device"
[21:30] <jcristau> what does "configured device" mean?
[21:31] <komputes> cat /etc/X11/xorg.conf
[21:31] <komputes> it says: "Configured Video Device" instead of the refular intel, pci 1:00. resolutions etc
[21:32] <komputes> jcristau: I agree with you, what does that mean? and what document does it make reference to for the configuration?
[21:32] <jcristau> my xorg.conf doesn't say anything like that :)
[21:33] <komputes> jcristau: using hardy?
[21:33] <jcristau> no
[21:33] <jcristau> sid :)
[21:33] <komputes> well the change hasn't taken place
[21:33] <bryce> komputes: jcristau is a debian X developer ;-)
[21:33] <komputes> upgrade and suffer the consequence of being hidden all that yummy information
[21:34] <bryce> komputes: jcristau already is using this new approach.  It's been standard in debian for some time now.
[21:34] <tjaalton> komputes: have you actually filed a bug about your issue?
[21:34] <komputes> bryce: well jcristau xorg.conf hides the details of a device from the user and only shows "configured video device"
[21:35] <komputes> tjaalton: hasn't been touched, it's like polio
[21:36] <tjaalton> komputes: oh it's that one.. well, it's not surprising when you don't specify the package
[21:36] <komputes> anhow, I'm going home, it was nice talking to you boys. If you find out where xorg.conf keeps the data for the "Configured Video Device" (and no I did not see that in the manual) please respond to me on the forums/IRC
[21:36] <jcristau> i don't understand the question...
[21:36] <jcristau> what "data" you're talking about, in particular
[21:37] <tjaalton> komputes: I'll reply to the bug, hope you do the same
[21:37] <komputes> driver, resolution and the such
[21:38] <komputes> tjaalton: no need a new general bug is being created, will update you when it's done
[21:38] <tjaalton> the server detects your intel just fine
[21:38] <komputes> tjaalton: yes, it detects, where does it STORE it
[21:38] <tjaalton> komputes: so I'll mark this one as invalid? (203940)
[21:38] <komputes> used to be xorg.conf
[21:38] <tjaalton> why do you insist on having it on the conf?
[21:38] <komputes> NOW it is _______________fill the blank____________
[21:39] <komputes> i don't, just tell me where it store that info?
[21:39] <seb128> why does it need to store it?
[21:39] <jcristau> komputes: it doesn't store it anywhere
[21:39] <seb128> you have too look at the configuration every time anyway since it can change
[21:40] <tjaalton> only drivers that need it are the proprietary blobs, since the xserver can't (yet) decide which driver to load, open or blob
[21:40] <jcristau> komputes: when it starts up, it scans your pci bus for graphics cards, and loads the appropriate driver
[21:41] <komputes> so there is no config file any longer?
[21:41] <jcristau> and then there's communication between the driver and the monitor to find out which modes are supported
[21:41] <bryce> komputes: Xorg usually runs fine with no xorg.conf at all
[21:41] <jcristau> so you can force stuff in the config file if you want, but you don't have to
[21:43] <komputes> jcristau: i understand, since i've done that.
[21:44] <komputes> jcristau: but you are telling me that there is NO config file by default, it auto detects the video card every reboot?
[21:44] <jcristau> everytime the X server starts, yes
[21:44] <jcristau> which is the only sane thing to do
[21:44] <komputes> that is why it says "Configured Video Device" ok, that makes sense
[21:45] <jcristau> there's no reason that knowledge should be stored on disk, since you can swap video cards, monitors, ...
[21:45] <komputes> what would it take to make the code from the previous version of dpkg-reconfigure and make it a stand-alone xorg.conf configuration tool
[21:45] <komputes> jcristau: yes i see
[21:46] <jcristau> the script behind dpkg-reconfigure xserver-xorg is a horrible mess, you don't want to look at that
[21:46] <tjaalton> cat /var/lib/dpkg/info/xserver-xorg.postinst, there
[21:46] <tjaalton> and this is the cut down version
[21:46] <tjaalton> (on hardy)
[21:46] <bryce> the infamous 3000 line bash script ;-)
[21:47] <bryce> "...of death"
[21:47] <tjaalton> now it's only 1911 lines
[21:48] <jcristau> to be fair 900 of those is xsfbs.sh, which is a library of shell functions
[21:48] <tjaalton> yeah
[21:48] <komputes> thats about how many users will be PO'd, anyhoo, talk to you all later, tjaalton i'll contact you when the full bug report is finalized.
[21:49] <tjaalton> komputes: but what about 203940?
[21:49] <komputes> tjaalton: ignore
[21:49] <tjaalton> k, closing it
[21:49] <komputes> tjaalton: not yet. still working on it, just ignore
[21:50] <tjaalton> komputes: just use that bug id
[21:51] <komputes> tjaalton: patience, I will contact you with details tomorrow 203940 is for hardware certification to close
[21:52] <tjaalton> there were no subscribers other than you
[21:55] <komputes> tjaalton: look at the tag hwct, that's harware certification's bug - use 207209 created by a member on the thread, we will all be posting to that
[21:56] <komputes> please do not touch 203940
[21:57] <tjaalton> uh
[21:57] <tjaalton> as you wish
[21:58] <tjaalton> hopefully only nvidia-owners will be posting to 207209
[21:59] <komputes> tjaalton: many thanks, it will be my mission to convince you over the next 29 days that the reconfiguration tool is essential to an ubuntero
[21:59] <tjaalton> the nv driver doesn't list all the devices
[21:59] <komputes> tjaalton: ok i'm make another one tomorow to make you happy
[21:59] <tjaalton> komputes: well, I'm not going to spend any effort on that
[21:59] <tjaalton> but you may
[22:00] <komputes> tjaalton: i know, i know
[22:03] <tjaalton> I happen to have a machine with GF7050 PV built in, and it uses vesa since -nv doesn't list it as supported. there are others too
[22:25] <bryce> tjaalton: btw UME sent me a small mesa patch from tungsten.  I'm going to take a deeper look at it, but on my first glance it looked innocuous enough that maybe we could include it in Hardy's mesa.
[22:31] <ubotu> New bug: #207409 in xorg (main) "[HARDY] xserver-xorg does not auto-configure correctly" [Undecided,New] https://launchpad.net/bugs/207409
[22:34] <tjaalton> bryce: sure
[22:35] <tjaalton> whee, -nv segfaults when added the pci-id of the GF7050PV to the driver
[22:37] <tjaalton> ah, filed upstream
[22:38] <komputes> tjaalton: ok, finally, the general bug is 207409
[22:38] <komputes> night
[22:39] <bryce> http://sfbay.craigslist.org/sfc/res/613938518.html
[22:46] <tjaalton> hehe
[23:05] <tjaalton> found out the reason why bug 207209 is a regression from previous releases
[23:05] <ubotu> Launchpad bug 207209 in xserver-xorg-video-nv "{Hardy} Xorg not loading "nv" driver" [Undecided,Incomplete] https://launchpad.net/bugs/207209
[23:05] <bryce> hmm, is it just me or are there more nv bug reports than usual lately?
[23:06] <tjaalton> 22 pci-id's are listed in a different table where the nv.ids is parsed from
[23:06] <ubotu> New bug: #207428 in xserver-xorg-video-nv "GF 7050 not supported" [Low,Confirmed] https://launchpad.net/bugs/207428
[23:06] <tjaalton> heh, this could be the reason
[23:06] <bryce> whoops, ouch
[23:07] <tjaalton> there is NVKnownChipsets where the most are, and NVIsSupported
[23:07] <tjaalton> what a mess..
[23:08] <bryce> there we go, I've fixed komputes' bug :-)
[23:09] <bryce> tjaalton: ouch, what do you think happened?  Did upstream drop support for those, or is it just a goof?
[23:10] <tjaalton> bryce: no, david just forgot to add the other table to the list
[23:11] <bryce> ahh
[23:11] <tjaalton> or something like that
[23:18] <tjaalton> I've milestoned that bug
[23:19] <bryce> tjaalton: need me to look at that one?  Take it that it just needs a bit of C hacking to paste things together?
[23:20] <tjaalton> bryce: it's actually just awk & sed
[23:20] <tjaalton> and I get different results when ran the command by hand
[23:21] <tjaalton> uh, bog