[00:08] <bryce> mnemo: I sketched out https://wiki.ubuntu.com/X/KernelModeSetting - please flesh it out further based on your testing
[00:09] <wgrant> bryce: For me, UXA with KMS is completely stable, unlike without KMS.
[00:10] <mnemo> wgrant: i have the opposite experience on G45
[00:11] <wgrant> mnemo: I'm an old i915.
[00:11] <wgrant> The cursor flickers a lot more, but otherwise it's good.
[00:13] <bryce> wgrant, mnemo: thanks; I've added a section for reporting results to  https://wiki.ubuntu.com/X/KernelModeSetting - mind adding your info?
[00:13] <mnemo> one cool thing i915 is that windows vista never shipped WDDM 1.1 drivers for it so it cannot run Aero afaik... which means that with UXA ubuntu is basically delivering a better and more capable driver than windows.. that rocks... see for example: http://www.tinyscreenfuls.com/2007/04/video-why-intel-915-graphics-dont-have-a-wddm-driver-for-vista/
[00:13] <mnemo> bryce: its ok you can add it
[00:14] <mnemo> bryce: exact card is:
[00:14] <mnemo> 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e22] (rev 03)
[00:14] <bryce> mnemo: can you add to it please?
[00:14] <mnemo> bryce: i've only tried KMS on jaunty with a kind of messy config actually
[00:14] <mnemo> maybe I should upgrade my intel box to karmic as well
[00:17] <mnemo> bryce: are you sure you can load the i915 module through /etc/modules like that? i mean doesnt modesetting have to load like really early for it to be useful? I thought thats why the debian kms wiki page said it needs to go into initramfs etc?
[00:18] <wgrant> bryce: What do you want for 'version'? Driver version?
[00:18] <Sarvatt> yeah the way he posted works fine for me but on 2.6.30-2
[00:18] <mnemo> mmkay
[00:19] <bryce> wgrant: yep
[00:19] <Sarvatt> i think you have to manually load some stuff prior to i915 if you dont enable KMS by default in the kernel like in 2.6.30-1 like the debian wiki says
[00:19] <bryce> mnemo: no I'm not sure, so please correct it to what you find in practice.  i'm just copying what others have told me
[00:20] <Sarvatt> but all you need is the modprobe option on 2.6.30-2
[00:20] <bryce> (maybe I should have just left the page blank)
[00:21] <mnemo> maybe we can ask some intel guy to do some vetting on that page later on
[00:22] <bryce> anyway, don't take anything written there as gospel; rewrite the whole thing if it makes more sense
[00:22] <wgrant> I just pass the option on the kernel line in GRUB.
[00:22] <Sarvatt> only reason you need the modprobe.d option is because of this http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=24ea0d5ee9c0bac3b9aab43e2761394dd3dcf413
[00:22] <bryce> eventually I plan to work on kms stuff myself, but I need to focus on getting more UXA bugs upstreamed first
[06:08] <persia> Hi.  I'm trying to track down how wacom's don't report some information to Xinput.
[06:08] <pwnguin> heh
[06:08] <persia> I'm wondering if part of the issue is using xf86Xinput.h rather than Xinput.h
[06:12] <persia> Am I looking down the wrong path?  The documentation on xinput seems light, but I(m confused about the relationship between libxi and xserver-xorg-input-foo.  Is libxi the client library only, receiving events from the server?
[06:22] <persia> At least I found out why there were four devices: pad, touch, tool nib, tool eraser.
[06:34] <persia> Hrm.  Seems it's running in some sort of compatibility mode, and was never ported to XInput.  I'm still not sure I understand the architecure properly, but the complete lack of any XIfoo calls seems suspicious.
[06:35]  * persia defers to someone who actually has hardware, as at this level of surgery, random hacking has a low probability of success
[10:51] <jcristau> persia: yes, libXi is the client side stuff. the driver shouldn't touch that.
[10:52] <jcristau> persia: the driver calls server functions, which are declared in /usr/include/xorg/*.h
[12:46] <persia> jcristau, OK, and things that manipulate properties should be including inputstr.h ?
[12:48] <jcristau> persia: what "things"?
[12:49] <persia> Well, I'm trying to reinstate the propagation of tool and pad serial numbers to X in the wacom driver (or at least interested in documenting what needs done, as I don't have a wacom to test).
[12:50] <persia> The sane way to do it seems to be to set properties inside DeviceIntRec, from my limited understanding of how things work.
[12:51] <persia> I'm suspecting these will be represented to clients and can be collected with XGetDeviceProperty() in a client.
[12:53] <persia> But I'm not sufficiently confident of my understand of how things work to know if this is correct.
[12:53] <persia> s/understand/understanding/
[13:02] <jcristau> right the driver keeps some stuff in its private data, and tells the server about it with XIChangeDeviceProperty
[13:07] <persia> Ah, from /usr/include/xorg/exevents.h.  I've been mistakenly looking in /usr/include/X11.  Thanks!
[13:08] <jcristau> and then clients use XListDeviceProperties/XGetDeviceProperty from libXi
[16:36] <alex_mayorga> any tips to get usable video on VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 03)
[16:37] <alex_mayorga> characters get blurrier as time goes on
[16:37] <alex_mayorga> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/213171
[18:47] <alex_mayorga> bryce: you there?
[18:48] <bryce> yes
[18:49] <alex_mayorga> any help on all the characters on my screen turning in ugly blurred blocks over time
[18:49] <alex_mayorga> say in 3-5 minutes after login
[18:49] <alex_mayorga> 00:02.0 0300: 8086:3577 (rev 03)
[18:50] <alex_mayorga> I can't even really see what I'm typing, really nasty stuff
[18:51] <bryce> alex_mayorga: sorry no idea, sounds weird
[18:52] <alex_mayorga> yeap, really weird, never seen this before
[18:53] <alex_mayorga> actually I had to paste your reply on a terminal to see what it said
[18:53] <alex_mayorga> oddly the characters on the terminal look fine
[18:53] <alex_mayorga> what might it be?
[18:55] <alex_mayorga> is there a way to query my LCD for its native resolution?
[18:56] <mnemo> xrandr
[18:57] <JanC> alex_mayorga: install orca (screenreader)  :-P
[18:58] <alex_mayorga> JanC: definitely an option hehe
[18:58] <mnemo> xrandr marks the current res with * and the preferred one with +
[18:59] <alex_mayorga> so 1400x1050      60.0*+ it is then
[18:59] <mnemo> alex_mayorga: yup
[18:59] <mnemo> alex_mayorga: which driver version do you have?
[18:59] <alex_mayorga> mnemo I had to resort to 2.4 I believe https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/213171
[19:00] <alex_mayorga> that bug has my details
[19:00] <alex_mayorga> well the comments with my name on it that's it
[19:00] <alex_mayorga> mnemo: anything I can do to get this one resolved I will
[19:01] <mnemo> alex_mayorga: step up as the maintainer for those older chipsets :)
[19:01] <alex_mayorga> If I use 2.7 is like the four quarters of the screen were overlaid in the top left quarter
[19:01] <mnemo> alex_mayorga: but no corruption with 2.7 ?
[19:01] <alex_mayorga> mnemo: that's the plan, but I'm pretty much a n00b here
[19:02] <alex_mayorga> mnemo: yes it's way more unusable
[19:02] <alex_mayorga> bryce mentioned something on the modaliases
[19:03] <mnemo> alex_mayorga: how old is this machine btw?
[19:04] <alex_mayorga> mnemo: you don't want to know :)
[19:04] <alex_mayorga> but is all that I've got, probably 7-9
[19:04] <alex_mayorga> :(
[19:10] <alex_mayorga> blockiness is coming back :(
[19:12] <alex_mayorga> seems like I can get back to usable if I change the resolution
[19:18] <alex_mayorga> but from there it starts to degrade to blocky stuff
[19:19] <alex_mayorga> I guess downgrading to 8.10 is my only way to ubuntu on this machine
[19:19] <alex_mayorga> mnemo: any other leads?
[19:27] <alex_mayorga> what's in theory the best driver for i830M cards?
[19:40] <alex_mayorga> bryce: do you know what was the last driver to support i830M?
[19:41] <bryce> alex_mayorga: dunno, maybe i810
[19:42] <jbarnes> current code supports i830
[19:42] <jbarnes> thought not all configurations
[19:42] <jbarnes> some dvo chips aren't handled
[19:46] <alex_mayorga> might this be it? https://bugs.freedesktop.org/show_bug.cgi?id=16928
[19:49] <alex_mayorga> "disappears with "Option" "AccelMethod" "XAA"." where do I put this?
[19:52] <alex_mayorga> should I give up and just start saving for a new laptop :(
[19:54] <jbarnes> alex_mayorga: well you could jump onto that bug and say you're willing to test fixes
[19:54] <jbarnes> you could also try disabling render accel
[19:55] <alex_mayorga> jbarnes, the freedesktop one?
[19:55] <jbarnes> yes
[19:55] <jcristau> if a bug's not filed at fd.o it doesn't exist ;)
[19:55] <alex_mayorga> yeah, that's my saying, bug or it didn't happen
[19:56] <alex_mayorga> how do I go about "disabling render accel"?
[19:56] <jcristau> with exa it's Option "exanocomposite"
[19:57] <mnemo> you can also completely disable acceleration with:
[19:57] <mnemo> Option "NoAccel" "true"
[19:58] <alex_mayorga> bear with me here, I guess all that you mention goes under xorg.conf somewhere right?
[19:58] <jcristau> yeah
[19:58] <mnemo> yes, inside the "Device" section
[19:58] <alex_mayorga> OK, now that's a start :)
[19:59] <alex_mayorga> please forgive me, this are my first dabblings at xorg bugs
[19:59] <alex_mayorga> what should I try first?
[20:00] <mnemo> pick one
[20:00] <mnemo> exnocomposite is probably a bit faster I think
[20:00] <alex_mayorga> should I first go to 2.7 driver
[20:01] <alex_mayorga> I'm on 2.4 and it kind of works, except for the blocky/blurry characters over time
[20:02] <alex_mayorga> jbarnes: are you on #intel-gfx as well?
[20:03] <jbarnes> alex_mayorga: yes
[20:05] <alex_mayorga> mnemo is exanocomposite or exnocomposite
[20:05] <mnemo> exa
[20:06] <alex_mayorga> OK, I'll try these 3 options
[20:06] <alex_mayorga> there's no X restart in jaunty anymore, right
[20:06] <jcristau> 'sudo killall X'
[20:06] <alex_mayorga> is there a way other than reboot?
[20:06] <tjaalton> logout should do
[20:07] <alex_mayorga> OK, let see how it goes
[20:07] <jcristau> or maybe it's 'sudo killall Xorg' instead
[20:07] <tjaalton> since it restarts the server
[20:08] <alex_mayorga> killing xorg shouldn't kill my pidgin and such, right?
[20:09] <tjaalton> umm yes it does
[20:09] <tjaalton> kills your session...
[20:09] <alex_mayorga> I'll wait a bit then, rather not close my VPN at this time
[20:19] <alex_mayorga> one question remains, should I stay on 2.4 or try the options suggested on 2.7?
[20:20] <mnemo> try both
[20:20] <mnemo> you need to systematically document your issue to zero in on the bug
[20:24] <alex_mayorga> mnemo
[20:24] <alex_mayorga> thanks I'll try that out
[22:42] <bryce> http://people.ubuntu.com/~bryce/totals.svg
[22:47] <seb128> bryce: would it be easy to do other similar graphs for other set of components?
[22:48] <bryce> possible, but not easy; I have a lot of hacks that are kind of xorg package specific there
[22:50] <bryce> seb128: as a starting point, I use packages xorg-swat is subbed to - https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs
[22:50] <seb128> we have a similar list of desktop-bugs
[22:50] <seb128> if the code you use for the graphs somewhere online?
[22:50] <bryce> yes it is in my arsenal tree
[22:52] <bryce> seb128: I'll put on my todo list to clean it up and post it for you when I get some time
[22:52] <seb128> thanks
[22:52] <seb128> no hurry, I was rather curious about it but we don't have a real need for stats
[22:52] <bryce> oh ok
[22:53] <seb128> if that was just a "it works for any team just change the url or packages list" I would have given it a try
[22:54] <seb128> but it seems that's not the case which is ok too
[22:55] <bryce> yeah I know not everyone is as obsessed with stats as me, so haven't really bothered to generalize the tools that much ;-)
[22:55] <bryce> but maybe someday
[23:33] <jbarnes> bryce: more evidence of vbetool fail
[23:33] <jbarnes> bryce: running it will cause interrupts to break on some machines, leading to rendering hangs
[23:33] <bryce> jbarnes: ok
[23:34] <bryce> jbarnes: details?
[23:34] <jbarnes> so on intel it should never be run... sounds like some of the thinkpad tools do it in X startup scripts
[23:34] <jbarnes> bryce: fdo bug 20896
[23:34] <bryce> I think we've mostly excised use of it in ubuntu setup scripts
[23:34] <jbarnes> ubottu: freedesktop bug 20896
[23:35] <jbarnes> bryce: great
[23:35] <jbarnes> bryce: just a heads up
[23:35] <bryce> cool, thanks I'll keep an eye out
[23:35] <bryce> do you know of any plans to modify vbetool to not trigger the error?
[23:36] <jbarnes> I don't think vbetool is the problem per-se
[23:37] <jbarnes> all it does is call into the VBIOS afaik
[23:37] <jbarnes> and on some machines apparently the VBIOS goes off and clears regs it shouldn't
[23:37] <jbarnes> bryce: apparently it's the acpi-support package from debian that caused this particular problem (or maybe vbetool itself)
[23:37] <jbarnes> not sure which X session scripts either of those patch at install time
[23:38] <bryce> oh interesting, ok I'll check that out
[23:38] <bryce> we used to have a package xresprobe which wrappered vbetool
[23:38] <bryce> but we knew about the problems it could cause on -intel, I recall gutting the tool to prevent it calling it
[23:39] <bryce> for some reason I recall it affecting laptops more than desktops, but I could be misremembering
[23:39] <bryce> anyway, we've moved away from using xresprobe for anything now
[23:39] <jbarnes> cool
[23:40] <bryce> ah yes, acpi-support calls vbetool
[23:40] <bryce> ./resume.d/55-screen.sh:  vbetool dpms on
[23:40] <bryce> ./resume.d/15-video-post.sh:  vbetool post
[23:40] <bryce> ./suspend.d/90-framebuffer-stop.sh:  vbetool dpms off
[23:42] <Sarvatt> theres no /etc/init.d/vbesave in ubuntu's acpi-support like that guy in #intel-gfx has on debian though
[23:42] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/acpi-support/+bug/31425
[23:43] <bryce> jbarnes: ^that sound like a match?
[23:43] <jbarnes> yeah could be
[23:44] <bryce> hmm, I would expect to see a larger number of bug reports
[23:48] <jbarnes> I don't think all vbioses do it
[23:48] <jbarnes> also it mainly affects kms apparently
[23:48] <jbarnes> due to the ordering of irq enable
[23:49] <bryce> also from the fdo bug report the symptoms are kind of generic so could be matches without any indication vbetool was involved
[23:50] <bryce> jbarnes: do you know which specific symptoms were the result of the vbetool call?  Or are all the symptoms caused by it?
[23:50] <jbarnes> symptoms would have been "all rendering stops"
[23:50] <jbarnes> mouse movement or some other interrupt source may have allowed it to continue
[23:50] <jbarnes> but that's config dependent I think
[23:51] <bryce> ok, it doesn't sound super familiar but I'll troll through our bugs and see
[23:51] <bryce> actually
[23:51] <bryce> I just finished going through ALL of the UXA bugs and didn't see that issue
[23:51] <jbarnes> ok so far I've only seen it with KMS
[23:51] <jbarnes> so maybe you don't have a report
[23:51] <bryce> if it mainly affects just kms... yeah
[23:52] <bryce> oh btw
[23:52] <bryce> https://wiki.ubuntu.com/X/KernelModeSetting
[23:52] <bryce> jbarnes: that's a start of a howto page for KMS, with a place for gathering test results
[23:53] <bryce> we've not started pimping it yet since there's still some infrastructural bits to square away but I'm planning on promoting that for more extensive KMS testing
[23:53] <jbarnes> bryce: cool
[23:53] <bryce> hopefully we can get enough of the UXA bugs resolved to switch over to UXA/DRI2/KMS by default
[23:54] <bryce> I just forwarded you a list of upstreamed uxa bugs I sent to yingying btw
[23:54] <jbarnes> ok
[23:55] <bryce> btw, are you guys no longer accepting EXA-specific bugs in the bug tracker now?
[23:57] <jbarnes> bryce: if they're high prio and affect 2.7 we could look at them
[23:58] <jbarnes> since we're doing 2.7.x releases
[23:58] <jbarnes> I hope yingying's team could help with those too