[00:02] <MarcoPau> nobody?
[01:47] <verbalshadow> Sarvatt: thanks, i'll file a bug soon on the ati drivers
[02:12] <bjsnider> libv, i read the phoronix story about this "greater modularization" but i don't see how the current system differs
[02:12] <bjsnider> isn't it already modularized?
[02:18] <libv> bjsnider: it isn't
[02:18] <libv> xserver is
[02:18] <libv> everything else isn't
[02:18] <bjsnider> i like how you're going directly around the developers to the users
[02:18] <libv> libdrm is not just libdrm, it is also libdrm_intel, libdrm_radeon, libdrm_nouveau
[02:18] <libv> all tracked with a single version number
[02:18] <bjsnider> i don't know if you're right or they are, but your tactic is populist in nature
[02:18] <libv> populist?
[02:18] <libv> what?
[02:19] <libv> i am the least populist X.org developer.
[02:19] <bjsnider> well, you're encouraging users to use your git tree instead of main right?
[02:19] <libv> and with that, the least popular.
[02:20] <libv> i am doing this to prove my point
[02:20] <libv> people claim that what i am doing is utterly impossible
[02:21] <libv> and therefor try to shut me and my ideas up, and keep things in a broken state for everyone
[02:21] <bjsnider> what point are you trying to prove?
[02:21] <libv> that it is not impossible, and that it actually makes quite a lot of sense.
[02:22] <libv> people can no longer use this clearly false argument
[02:22] <bjsnider> what are you trying to prove is possible?
[02:22] <libv> to modularize out the dri drivers from mesa.
[02:22] <bjsnider> why would that be desirable?
[02:22] <libv> *sigh*
[02:24] <libv> http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1
[03:54] <Sarvatt> RAOF: I believe you actually need to use the noaccel nouveau module option instead of xorg.conf now, think thats a relic of UMS
[03:55] <RAOF> Sarvatt: I was wondering that myself, so I tested it :)
[03:55] <Sarvatt> oh spiffy, sorry then :)
[03:55] <RAOF> I got a *wonderfully* slow X server, using ShadowFB.
[03:55] <Sarvatt> i'm going to suggest they just disable Xv instead of completely disabling accel
[03:56] <RAOF> But the Xv issue is not the only one - there's the corruption of the desktop wallpaper, too.
[03:57] <Sarvatt> ohh missed that, I need to stay away from bugs when I'm half asleep :)
[04:36] <Sarvatt> RAOF: didn't karmic have clutter 0.8.x that netbook-launcher used? i'm positive 0.8.x needed opengl 1.4 support and that person using savage in that bug had 1.2
[04:36] <Sarvatt> they didnt lower it to opengl 1.2 until after clutter 1.0
[04:37] <RAOF> I'm not sure.  Regardless, savage shouldn't be SIGSEGVing on glGetString (GL_EXTENSIONS); as far as I can tell there's a GL context bound.
[04:37] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/netbook-launcher/+bug/467474 (sorry had to dig it up)
[04:38] <RAOF> Clutter certainly wasn't checking for 1.4 and erroring out if it didn't find it.
[06:02] <superm1> bjsnider, i'm here on and off, please ping with specific questions though
[16:26] <pgraner> bryceh: you about?
[17:30] <Sarvatt> anyone know a way to force firmware into the initrd if the module doesn't claim it needs it? want to figure it out for nouveau blob ctxprogs usage
[17:41] <Sarvatt> hmm what to do about the nvidia-settings issue.. -96 and -173 can't load the X display configuration page in nvidia-settings because some of the extensions from newer drivers (NoScanout) aren't available in the older drivers and it fails to load
[17:41] <Sarvatt> upstream ones work of course because they bundle the right nvidia-settings with the blobs
[17:47] <bryceh> Sarvatt, file a bug report and assign to tseliot
[17:59] <Sarvatt> want me to latch onto an existing or file a new one and dupe the others to it?
[18:00] <Sarvatt> theres a *lot* of others, would be faster to do a new one and dupe as i come across them if thats ok
[18:01] <bryceh> yep that's fine
[18:08] <Sarvatt> alrighty https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-settings/+bug/539196
[18:25] <rye> Hello. Having found about nVidia GPU overhearing with their proprietary drivers and experiencing substantial redraw slowdown with their latest version I decided to give nouveau a second try.
[18:25] <rye> Is there anything particular required to set up to make it work with current lucid on GeForce 8400M ?
[18:26]  * rye was here not so long ago running in circles, screaming and shouting about nvidia, blacklist and /usr partition
[18:28] <rye> So far - no nvidia modules installed, blacklist rules are removed. Plymouth is not starting up. With no other options, kernel modesetting is enabled and after X starts, it gives a static green-bars image
[18:28] <rye> with kernel modesetting disabled (i believe that's nouveau.modeset=0) I can get to X, but the resolution is 800x600 on 1280x800 screen.
[18:29] <rye> no xorg.conf is present, defaults are applied
[18:36] <tjaalton> rye: nouveau only supports kms, so with nomodeset you probably get -nv or vesa?
[18:37] <rye> tjaalton, hm, vesa. Right
[18:39] <rye> tjaalton, ok, by default kms is enabled, so if I don't get it working then that's a bug
[18:39] <rye> ?
[18:41] <tjaalton> sure
[18:42] <tjaalton> try booting without splash
[18:42] <rye> I mean is there anything I can do to get some useful debug info, I remember having nouveau working in the past... a week ago?
[18:57] <bryceh> tjaalton, heya
[18:58] <vish> bryceh: hi , Bug #515548 , was due to a bug in the radeon drivers , afaik , nothing to do with the kernel , shall i revert the status that the automatic script set?
[19:00] <bryceh> vish, have you tested it against the latest drm?
[19:01] <vish> bryceh: i havent tried the ppa , but i'm running the latest lucid kernel , with the xedgers ppa , which fixed the problem
[19:01] <vish> havent yet tried drm ppa*
[19:02] <bryceh> vish, don't need to test the drm ppa anymore, it's now in lucid
[19:02] <bryceh> vish, mention that the -radeon from the xorg-edgers fixed the problem, and indicate the exact package name and date, since stuff in xorg-edgers changes day by day
[19:03] <bryceh> vish, if you can identify the exact patch / changeset which solved the issue, attach the patch to the bug report.  That will up the priority on the bug report
[19:03] <vish> bryceh: ah , ok. so the status can be reverted? Sarvatt added the fix for the bug in xedgers ppa. now sure if it landed in karmic , i have mentioned the changes required in the comments 
[19:03] <vish> s/karmic/lucid
[19:04] <vish> bryceh: comment 4 and 3 those are the patches we need to fix the bug
[19:04] <bryceh> yes if you do those things set the status to Confirmed
[19:05] <rye> tjaalton, hm, the neighbor notebook with ATI Radeon - M52 [Mobility Radeon X1300] can't get to GDM as well, disabling with radeon.modeset helps.
[19:07] <rye> is there any known regression that may make two substantially different kms-enabled devices to stop working suddenly (i.e. my Nvidia GF 8400m w/ nouveau and ATI Mobility Radeon X1300) ? Checking whether Intel netbook follows those two
[19:10] <rye> tjaalton, by 'can't get to GDM' i mean that for ATI the plymouth screen stays when X is supposed to be there. checking now with splash disabled.
[19:14] <rye> starting w/o splash works for ATI, hm, plymouth is at 0.8.0~-14
[19:21] <tjaalton> bryceh: howdy
[19:21] <tjaalton> rye: probably something plymouth related then
[19:26] <tjaalton> afk ->
[19:49] <Sarvatt> woohoo, super major r600+ improvement in -ati just landed, 10x performance increase in DFS which was the biggest complaint about those chipsets i've seen
[19:49] <rye> hello again, is "(EE) [drm] failed to open device" supposed to be in Xorg with nouveau?
[19:49] <Sarvatt> flash uses DFS a ton and it was really slowing things down with KMS on r600+
[19:50] <Sarvatt> vish: both the ddx and libdrm fixes for your bug have been in lucid proper for awhile, no need to use edgers
[19:51] <johanbr> rye, I've seen that when the kernel/libdrm/X versions are not in sync
[19:51] <Sarvatt> rye: need more full logs to troubleshoot, could be a ton of things
[19:52] <Sarvatt> regarding the drm failed to open device problem at least
[19:52] <rye> Sarvatt, ok, will make sure that I am running latest as of now
[19:54] <Sarvatt> you're using stock lucid not a PPA right?
[19:56] <rye> Sarvatt, hm... let me find out. I should not be using PPA, but that rang a bell
[19:57] <rye> PPA
[19:57] <rye> awesome
[20:09] <rye> Sarvatt, I have to apologise for the noise, again. Will file a bug against myself to check the origin of the packages installed. OTOH i verified that the packages in PPA do not work :)
[20:09] <vish> Sarvatt: thats good to know  , thanks :)
[20:09] <rye> Sarvatt, with stock lucid packages I get usable GDM + Plymouth shiney
[20:10]  * rye tries to set up multihead now. Silences himself for at least 30 minutes
[20:10] <Sarvatt> what PPA were you using?
[20:10] <rye> Sarvatt, xorg-edgers-nouveau-lucid
[20:12] <Sarvatt> oh, didnt realize that had my packages in it, guessing my hooks to blacklist nouveau and vga16fb arent working
[20:12] <Sarvatt> i haven't tested it on nouveau at all so I have no idea if anything is screwed up
[20:13] <Sarvatt> wife has had my nouveau laptop for the past few days :(
[20:21] <bjsnider> yeah, it's aaalll the wife's fault
[21:04] <Sarvatt> so I think we need to change /lib/udev/rules.d/69-xserver-xorg-input-synaptics.rules to ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ATTRS{idVendor}=="056a", ENV{x11_driver}="wacom"  or something for starters
[21:04] <Sarvatt> to stop wacom from claiming all tablet devices
[21:05] <Sarvatt> serial tablets of other brands should be covered by the pnp subsystem checks at the top
[21:06] <bryceh> Sarvatt, that'll make it fall through to -evdev?
[21:07] <Sarvatt> hmm wait, need to look at some logs to see whats happening. TOUCHSCREEN and TABLET are seperate matches already
[21:08] <Sarvatt> really need to find a darn cheap touchscreen somewhere to mess with this
[21:11] <Sarvatt> INPUT_TOUCHSCREEN stuff is getting shoved over to wacom for some reason
[21:12]  * Sarvatt tries to find superm1's bug report again..
[21:13] <bryceh> Sarvatt, tjaalton:  I brainstormed some todo's that need done between now and lucid release, to help coordinate efforts...  https://wiki.ubuntu.com/X/Projects
[21:14] <bryceh> Sarvatt, tjaalton: if you can think of things not on that list, let me know and I'll add them
[21:14] <bryceh> and if there's any tasks you want to have ownership on, let me know that too (or just mark yourself the owner in that list)
[21:20] <KiBi> :W 7
[21:20] <KiBi> oops, sorry.
[21:32] <Sarvatt> superm1: Dell actually has drivers for your devices touchscreen under ubuntu that just need updating to the latest ones with xserver 1.7 support, do you have access to the source package to update it?
[21:32] <Sarvatt>  http://support.dell.com/support/downloads/driverslist.aspx?os=UD94&catid=-1&dateid=-1&impid=-1&osl=EN&typeid=-1&formatid=-1&servicetag=&SystemID=LAT_2100&hidos=LNUX&hidlang=en&TabIndex=&scanSupported=False&scanConsent=False
[21:33] <Sarvatt> Latitude 2100
[21:34] <Sarvatt> thats a deb package of the blob drivers I linked for you the other day, cant seem to download it completely to check it out though
[21:37] <Sarvatt> bryceh: Investigate/develop way to override video settings when KMS is used (work with kernel team) -- I have been toying with that in my free time, I managed to get xforcevesa working partially by adding a check in initramfs-tools for it, blacklisting drm i915 nouveau and radeon modules if its there, and having the gdm init script exit1 so failsafeX is used when its on the command line
[21:38] <Sarvatt> the only hinderance I've had is actually making the blacklisting stick, late in the boot process drm/i915 is loaded even if its blacklisted
[21:38] <Sarvatt> so failsafeX is working but its fbdev on top of KMS
[21:40] <bryceh> mm
[21:40] <Sarvatt> couldn't figure out why it was happening, i think I might have to extend the /proc/cmdline checks in plymouth that check for single to not load if xforcevesa exists as well which would be easy
[21:40] <bryceh> Sarvatt, sounds like good progress though
[21:41] <bryceh> Sarvatt, do you want to take ownership of this task, or just be listed as a resource/contact?
[21:43] <Sarvatt> sure, I think I can get it working soon but I dont have commit rights to the relevant packages so it might not be appropriate
[21:46] <Sarvatt> i'm not sure if I'm going about it the right way, theres a whole lot of options to do it
[21:46] <bryceh> ok, I'll jot you down.  I'll be happy to take care of sponsoring where you need committing
[21:49] <Sarvatt> wasn't sure about what arg to use either, just went with xforcevesa for now since that was around before
[21:50] <tjaalton> bryceh: ok, mesa 7.7.1 and xserver 1.7.6 probably should be on the list. also wacom 0.10.5 which is hopefully released soonish
[21:53] <bryceh> tjaalton, ok thanks
[21:56] <Sarvatt> yeah wacom seems important, a lot of serial tablet fixes in it
[21:56] <tjaalton> Sarvatt: probably wiser to change the wacom udev rule not claim all tablets
[21:57] <Sarvatt> I would add xserver-xorg-video-ati to the list as well since it fixes the 100% cpu usage if any kind of flash is happening also on r600+
[21:57] <tjaalton> but like the old fdi file did, match the vendor id's (like for the serial devices now)
[21:57] <tjaalton> yeah ati 6.13 too
[21:57] <Sarvatt> just the one vendor id match I pasted should be enough I would think, the other brands are serial ones matched earlier?
[21:58] <tjaalton> but that was for synaptics?
[21:58] <sebner> bryceh: I guess there is no calender feature (visualisation of the tasks) planned?!
[21:58] <sebner> bryceh: + for gtg
[21:58] <Sarvatt> ACTION=="add|change", SUBSYSTEM=="input", ENV{ID_INPUT_TABLET}=="?*", ATTRS{idVendor}=="056a", ENV{x11_driver}="wacom
[21:58] <tjaalton> well you mentioned synaptics.rules, so got confused there :)
[21:59] <Sarvatt> oh sheesh sorry!
[21:59] <tjaalton> in that case yes, you're right
[21:59] <Sarvatt> was looking at synaptics kernel source and had it on the brain at the time
[22:00] <jcristau> tjaalton: and xinput 1.5.1! it's critical! (ok, not really, just manpage updates) :)
[22:00] <tjaalton> jcristau: good catch!
[22:01] <tjaalton> :)
[22:01] <tjaalton> bryceh: pinged whot about the wacom releas
[22:01] <tjaalton> e
[22:01] <tjaalton> so I'll choose that from the list
[22:02] <tjaalton> Sarvatt: file a bug about that so I won't forget
[22:02] <bryceh> tjaalton, ok
[22:02] <bryceh> got -ati too
[22:02] <tjaalton> and assign it to me
[22:02] <Sarvatt> this ideacom touchscreen device I'm looking at registers as generic usbhid mouse/keyboard devices not a usbtouchscreen one, no wonder its bugging me out
[22:02]  * bryceh waits for wiki to finish saving *whistle* *whistle*
[22:03] <tjaalton> oh yeah there's that touchscreen task too, hope it's not multitouch :)
[22:03] <bryceh> oh sorry, yes multitouch
[22:03] <tjaalton> whot posted an rfc about it today
[22:03] <bryceh> will fix once wiki is done saving
[22:03] <bryceh> tjaalton, ah cool I'll check it out
[22:05] <Sarvatt> http://launchpadlibrarian.net/40842504/XorgLog.txt
[22:05] <Sarvatt> xorg log booting with a touchscreen thats loading wacom
[22:07]  * sebner feels slighty ingored by bryceh :p
[22:07] <tjaalton> bryceh: it's far from being ready though, so maybe a bit volatile for lucid :)
[22:08] <Sarvatt> oh ok the device has ID_INPUT_TABLET=1 in the udev log
[22:09] <bryceh> sebner, sorry a bit busy at the moment
[22:10] <bryceh> sebner, did you mean to ask on #gtg?
[22:10] <bryceh> sebner, not sure what you're referring to, tbh
[22:11] <sebner> bryceh: nah, I know that you are somehow heavily involved and did see you active here so I thought about shooting a quick question. Something like lightning,.. 
[22:11] <bryceh> tjaalton, at a minimum we want to get it in a PPA.  But there is strong motivation to get it into lucid even if it introduces risk for us
[22:12] <bryceh> (in fact, this is one reason I'm getting the X stabilization work tasked out, so we can bring in some additional people to work on X so we can make more resources available for MT work)
[22:12] <tjaalton> bryceh: oh well.. :)
[22:14] <bryceh> tjaalton, yeah the concerns about X stabilization risks is known to pitti and rickspencer3 and hopefully this msg will flag them that you have some concerns here too
[22:14] <rickspencer3> what huh?
[22:15] <rickspencer3> bryceh, should you invite tjaalton to your pow-wow tomorrow?
[22:15]  * sebner waves at rickspencer3 :)
[22:15] <rickspencer3> ironically, I am talking to RAOF about this atm
[22:15] <rickspencer3> hi sebner
[22:15] <bryceh> rickspencer3, yep, sounds like Sarvatt would be good to invite too
[22:16] <tjaalton> pow-wow?-) sounds like some commercial
[22:16] <tjaalton> oh, indians
[22:16] <bryceh> tjaalton, US colloquialism for "big meeting"
[22:17] <tjaalton> bryceh: what time was that?
[22:18] <bryceh> haven't decided... tough finding a time where me, tseliot, and raof all are awake at the same time
[22:18] <bryceh> rickspencer3, suggestions on a time?
[22:19] <rickspencer3> bryceh, hmmm
[22:19] <rickspencer3> with dst I'm all confused now
[22:19] <tjaalton> this is about more than just MT?
[22:19] <RAOF> 7AM my time (2000UTC) seemed to work for last week's Do meeting.
[22:19] <rickspencer3> I think 1pm tomorrow will be 9am in Sydney and 10pm in England
[22:20] <rickspencer3> bryceh, maybe you can convince RAOF to do 8am and Jan to do 9pm?
[22:20] <bryceh> tjaalton, yeah the meeting is for general X work, who wants to take which tasks, make sure we have everything covered
[22:20] <bryceh> rickspencer3, ok works for me
[22:21] <bryceh> mm, ok 1pm seems to be 2000UTC, 
[22:21] <bryceh> am I calculating right?
[22:21] <RAOF> I'm happy to do 7am or 8am.
[22:23] <Sarvatt> any time is good for me as long as I know beforehand, my hours are pretty flexible and I don't imagine it'd take too long so I could squeeze it in between jobs
[22:23] <tjaalton> either of those is fine by me, 2200UTC is getting a bit late
[22:23] <RAOF> Does http://timeanddate.com/worldclock/meetingtime.html?day=16&month=3&year=2010&p1=240&p2=136&p3=137&p4=179 cover everyone?
[22:24] <tjaalton> should be in bed already :)
[22:24] <bryceh> ok 2000UTC it is.  google calendar meeting invite thingee coming right up
[22:25] <bryceh> rickspencer3, got an email addy for Jan?
[22:26] <rickspencer3> bryceh, PM'd
[22:27] <bryceh> ta
[22:43] <tjaalton> bryceh: btw, push your xserver changes to git ;)
[22:43] <tjaalton> unless they are there already, haven't checked recently
[22:44] <bryceh> invite sent
[22:44] <bryceh> tjaalton, pushed
[22:44] <bryceh> I wish I understood why I continually fail to git push
[22:45] <tjaalton> debuild -S -sa -i".git"; dput ../foo; git push origin ubunt, simple as that ;)
[22:45] <tjaalton> +u somewher
[22:45] <tjaalton> e
[22:45] <tjaalton> damnit
[22:45] <bryceh> lol
[22:46] <tjaalton> new shiny lenovo keyboard still making me mistype
[22:52] <KiBi> tjaalton: -i alone works fine in most cases
[22:53] <tjaalton> KiBi: hasn't for me, and never bothered to find out why :)
[22:53] <Sarvatt> hmm http://www.dealextreme.com/details.dx/sku.15611
[22:53] <KiBi> tjaalton: I think native packages need some -I in addition or something.
[22:53] <KiBi> Always did for me; but nevermind :)
[22:54] <Sarvatt> I put DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.git" in ~/.devscripts (someone here told me that trick)
[22:54] <tjaalton> KiBi: yes, when packaging xorg. I need to check my settings some time
[22:54] <tjaalton> Sarvatt: they should have a 24" version too
[22:55] <KiBi> /usr/share/perl5/Dpkg/Source/Package.pm:(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg(?:tags)?|_darcs|\.git|
[22:55] <KiBi> It knows about much more than you need to type ;)
[22:55] <tjaalton> yeah I know that but it still never worked. maybe some setting overrode it or something
[22:55] <tjaalton> I'll try tomorrow :)
[22:59] <Sarvatt> should add .bzr to that :)
[22:59] <tjaalton> it is, just not on that same line :)
[23:57] <Sarvatt> hmm ok so superm1's specific touchscreen is resistive and reporting as a tablet instead of a touchscreen, that makes sense
[23:57] <bjsnider> -i".git" ignores all subfolders with that name or just in the top level?
[23:58] <Sarvatt> so the issue looks like, udev's idinput checks for BTN_TOOL_PEN or BTN_STYLUS and assigns it ID_INPUT_TABLET=1 if so, and doesn't check further down the list where it looks for BTN_TOUCH to assign ID_INPUT_TOUCHSCREEN=1
[23:59] <Sarvatt> 65-xorg-evdev.rules doesn't assign evdev to ID_INPUT_TABLET at all