[01:31] <RAOF> Is anyone else having compiz problems with nvidia-180?  Mine seems to corrupt all the GL transformed textures.
[01:31] <RAOF> Woah!  Wobbly is *trippy*.
[01:32] <andersk> RAOF: I'm not (but now I almost wish I did :-P). 
[01:33] <RAOF> I wonder if istanbul will capture it.  It's truly nifty.
[01:35] <RAOF> o/` Istanbul is Constantinople / now it's Istanbul not Constantinople / been a long time gone / Constantinople o/`
[01:37] <RAOF> Well, that's disappointing.  Istanbul captures nothing but noise.
[01:39] <RAOF> Mmm, temporary craziness.  Gotta love it.
[01:39] <RAOF> Oh, even better.  Combined with that 'large windows sometimes don't update' XDamage bug.  Sweet.
[10:37] <bryce_> tjaalton: what's your thoughts on UXA for jaunty?
[10:37] <bryce_> I'm leery of it being still too unstable
[10:39] <tjaalton> yeah, and there's the alpha-channel corruption thing
[10:39] <tjaalton> and it crashes my X on resume
[10:46] <bryce_> tjaalton: I'm wondering if we should revert -intel back to 2.4.x given how many people complain about the performance
[10:46] <bryce_> tjaalton: what are your thoughts?
[14:38] <bryce_> tjaalton: I'm wondering if we should revert -intel back to 2.4.x given how many people complain about the performance... your thoughts?
[14:39] <tjaalton> bryce_: the ddx driver doens't have much to do about it
[14:44] <bryce_> tjaalton: mesa?
[14:44] <tjaalton> bryce_: xserver 1.6 depends on 7.3
[14:44] <tjaalton> I think it would be silly to go back :)
[14:45] <bryce_> tjaalton: then how to fix the performance issues?
[14:45] <tjaalton> re-enable patch 107..
[14:45] <tjaalton> and give KDE users the finger ;)
[14:45] <bryce_> we were seeing performance issues before that was dropped
[14:46] <bryce_> ^weren't
[14:47] <jcristau> gem is probably responsible for at least some of the performance problems
[14:53] <desrt> Alexia_Death: you wrote a program that reads the serial port and injects events into the kernel input layer, or...?
[14:53] <Alexia_Death> desrt: No. I made a dbus daemon that adds and removes wacom devices.
[14:54] <Alexia_Death> Why the question?
[14:54] <desrt> just wondering why my tablet isn't working and what needs to be done to make it happen out of the box
[14:55] <Alexia_Death> desrt: Jaunty with all the latest updates?
[14:55] <desrt> downloaded alpha2
[14:55] <Alexia_Death> And what tablet?
[14:55] <desrt> it's an x200 tablet
[14:55] <desrt> (lenovo)
[14:56] <desrt> the tablet shows in hal.  complete with the 'input' and 'input.tablet' capabilities and "Wacom" appearing in the product string
[14:56] <Alexia_Death> Its a serial TabletPC device?
[14:56] <desrt> and the wacom fdi file is installed...
[14:56] <Alexia_Death> you have stylus then.
[14:56] <desrt> ya.  the serial.device points at /dev/ttyS0
[14:56] <desrt> i suppose so
[14:57] <desrt> when i hacked up xorg.conf to manually handle this i added stylus and eraser sections
[14:57] <Alexia_Death> For taplet pc X xonf is OK.
[14:57] <desrt> did you just try to tab-complete irc?
[14:57] <Alexia_Death> Your serial device is not going anywhere.
[14:58] <Alexia_Death> desrt: ?
[14:58] <desrt> 'xonf'
[14:58] <Alexia_Death> conf
[14:58] <desrt> ah.  right.
[14:59] <desrt> i was sort of thinking that it would be nice, though, to have it working for jaunty out of the box
[14:59] <desrt> like, if i go edit my xorg.conf, then it works for me
[14:59] <Alexia_Death> desrt: as to making it work out of the box, HAL should take care of enabling the stylus
[14:59] <desrt> but anyone else who installs on a thinkpad ends up thinking 'ubuntu sucks'
[14:59] <Alexia_Death> So it works there.
[14:59] <Alexia_Death> My daemon can be used for per user conf
[15:00] <desrt> so perhaps i need to know a little more about how X deals with hal
[15:00] <Alexia_Death> desrt: if you are aup for making a configuration utility for it then thats good enough
[15:00] <Alexia_Death> desrt: its really simple.
[15:00] <tjaalton> desrt: didn't you say it works OOTB as a stylus?
[15:00] <desrt> no
[15:00] <desrt> nothing happens at all out of the box
[15:00] <desrt> i mean.. i can make some nice drumming noises, i guess...
[15:01] <tjaalton> then why does lshal show it? pastebin pleas
[15:01] <tjaalton> +e
[15:01] <desrt> but the cursor isn't moving :)
[15:01] <desrt> erm
[15:01] <desrt> that's going to take a little while.  hold on :)
[15:01] <Alexia_Death> desrt: HAL should be able to make the stylus move if it recognizes it.
[15:01] <desrt> right.
[15:01] <desrt> so that's what i found odd :)
[15:01] <Alexia_Death> that is a bug
[15:01] <desrt> good!
[15:02] <desrt> now we're getting somewhere :)
[15:02] <Alexia_Death> the limitation of HAL is that it can add just one device
[15:02] <Alexia_Death> So no eraser.
[15:02] <desrt> it seems sort of like X should work around that
[15:02] <Alexia_Death> you need the daemon for that.
[15:02] <jcristau> Alexia_Death: that's the part i don't understand
[15:02] <Alexia_Death> X does. with allowing DBUS conf.
[15:02] <desrt> like.. this "one physical device = one XInput device" is an incorrect assumption in X, clearly
[15:03] <desrt> hmm
[15:03] <Alexia_Death> desrt: Its an incorrect assumotion in HAL not X
[15:03] <jcristau> Alexia_Death: if the driver gets loaded, then it can add the other devices as it pleases
[15:03] <Alexia_Death> And hall people have said they wont fix it.
[15:03] <desrt> Alexia_Death: how is HAL to know?
[15:03] <jcristau> so no need for a daemon or dbus or anything?
[15:03] <Alexia_Death> jcristau: Im not a driver developer
[15:04] <Alexia_Death> I knw how I can do it now.
[15:04] <desrt> i could buy a brand new pen
[15:04] <jcristau> meh. nobody is.
[15:04] <desrt> and bring it near my laptop
[15:04] <Alexia_Death> Besides, I think its smart to keep that out of the drver
[15:04] <desrt> are you saying HAL should create a new device node for it when that happens?
[15:04] <Alexia_Death> desrt: pen is not the device
[15:04] <Alexia_Death> device is the surface
[15:04] <desrt> absolutely agree
[15:04] <Alexia_Death> that supports pens and erasers
[15:04] <desrt> there is only one surface
[15:05] <Alexia_Death> HAL can only give you support for pen
[15:05] <desrt> supposedly i can use airbrushes and all sorts of other fancy stuff with this...
[15:05] <desrt> any wacom device
[15:05] <Alexia_Death> And like I said, Ive talked to HAL people about it.
[15:05] <Alexia_Death> airbrush is a kind of pen
[15:05] <Alexia_Death> IIRc.
[15:05] <desrt> but i would expect it to show as a separate xinput device
[15:06] <Alexia_Death> serials are used for that I think
[15:06] <Alexia_Death> That support is iffi.
[15:06] <Alexia_Death> I have to go for now.
[15:06] <desrt> k.
[15:06] <Alexia_Death> Ill be back in a little later.
[15:06] <tjaalton> the product mapping could live inside the driver, and initialize the devices it supports
[15:06] <desrt> i'll boot up the live cd again and get lshal
[15:06] <tjaalton> so yes, no daemon needed
[15:07] <desrt> tjaalton: that's sort of what i was thinking
[15:07] <Alexia_Death> tjaalton: DAemon is still needed fpr per user configuration
[15:07] <desrt> seems like it should be sufficient for hal to say "there's a wacom serial device here"
[15:07] <jcristau> Alexia_Death: why?
[15:07] <Alexia_Death> You dont expect all users to live with default conf do you.
[15:07] <desrt> and for X to create as many Xinput devices as are required from it
[15:07] <tjaalton> Alexia_Death: wacom should just support input properties, then the settings could live in .xsession or gconf or ..
[15:08] <Alexia_Death> desrt: thats in the domain of wacom development. Talk to ping about it.
[15:08] <desrt> tjaalton: you'd need something to bridge the settings over, in that case
[15:08] <Alexia_Death> tjaalton: tablet properties need a UI and easy way to change.
[15:08] <jcristau> desrt: that's called a desktop environment
[15:08] <desrt> like gnome-settings-daemon or whatever
[15:08] <Alexia_Death> its not a set once thing.
[15:08] <desrt> jcristau: ya.  exactly.
[15:09] <tjaalton> Alexia_Death: yes, but the gui should be provided by the DE (in the long run, we discussed this already :)
[15:10] <Alexia_Death> Nice dreams guys
[15:10] <tjaalton> hehe
[15:10] <Alexia_Death> But its not happening dor jaunty 
[15:10] <tjaalton> no
[15:10] <Alexia_Death> what i do works now
[15:10] <jcristau> the ui is completely unrelated to how you pass those properties to the driver..
[15:11] <desrt> this seems to be sort of similar to how gnome configures the keyboard layout and stuff
[15:11] <desrt> someone just needs to teach it about tablets :)
[15:12] <desrt> Alexia_Death: do you have a link to the stuff you wrote?
[15:12] <desrt> lshal -> http://pastebin.com/m49dbb4ad
[15:12] <tjaalton> desrt: ok, then Xorg.0.log
[15:13] <desrt> tjaalton: no mention of the word "wacom" anywhere in there
[15:13] <tjaalton> sure is
[15:13] <desrt> sure isn't
[15:13] <tjaalton> lines 318-333
[15:13] <desrt> in the Xorg.log i mean
[15:13] <tjaalton> ah
[15:13] <tjaalton> was this on jaunty?
[15:13] <desrt> jaunty alpha 2 livecd
[15:14] <tjaalton> ancient! :)
[15:14] <desrt> :)
[15:14] <tjaalton> still, I'd like to see it
[15:14] <desrt> ok
[15:14] <desrt> gimme a sec
[15:14] <tjaalton> I'm surprised that hal picked that up
[15:15] <desrt> http://pastebin.com/mf39b2d0
[15:15] <tjaalton> (WW) config/hal: no driver or path specified for /org/freedesktop/Hal/devices/pnp_WACf004
[15:15] <desrt> ahah
[15:15] <desrt> good catch :)
[15:16] <desrt> thing about that is that i have this /usr/share/hal/fdi/policy/20thirdparty/10-wacom.fdi
[15:16] <tjaalton> from the wacom driver
[15:17] <desrt> it says that if input.caps contains "input" and product contains "Wacom" then input.x11_driver is set to "wacom"
[15:17] <desrt> and indeed, in the lshal output:
[15:17] <desrt>   input.x11_driver = 'wacom'  (string)
[15:17] <desrt>   input.x11_options.Type = 'stylus'  (string)
[15:17] <desrt> for udi = '/org/freedesktop/Hal/devices/pnp_WACf004'
[15:18] <tjaalton> yes, but I think they should be for /org/freedesktop/Hal/devices/pnp_WACf004_serial_platform_0
[15:18] <tjaalton> also the capabilities
[15:18] <tjaalton> that way the driver would be assigned for it
[15:19] <desrt> the one that has the linux.device_file
[15:19] <tjaalton> either kernel or hal boog
[15:19] <tjaalton> depends where info.capabilities is coming from..
[15:20] <desrt> could also argue that it's an X bug for not querying subdevices to find ports
[15:20] <desrt> and, as these things go, i guess probably there -will- be an argument about that :)
[15:20] <tjaalton> well, if it would list the capabilities for the subdevice, it'd just work
[15:21] <tjaalton> you can do test that by not matching info.cap..
[15:21] <tjaalton> -do
[15:21] <desrt> ya.  i believe that it would work.
[15:21] <desrt> it's also not quite right, though
[15:21] <tjaalton> at least it should be confirmed, so that it's not something else
[15:21] <desrt> because then it will assign the x11 driver to both nodes
[15:21] <tjaalton> that's not a problem
[15:22] <tjaalton> it'll fail to use it for the first one
[15:22] <desrt> i know it's not a problem... X will just say "dur... dunno what to do, so i ignore"
[15:22] <desrt> but that's not right
[15:22] <desrt> seb128: this is why i switched to fedora!
[15:22] <seb128> desrt: good for you!
[15:22] <desrt> damn X hackers breaking my tablet :p
[15:22] <desrt> (or hal hackers...)
[15:23] <tjaalton> whot has done the same already, so you lose :)
[15:23] <desrt> ya.  i noticed.
[15:23] <LLStarks> yo.
[15:23] <LLStarks> http://ubuntuforums.org/showthread.php?t=1058915
[15:23] <LLStarks> hopefully i can get a nice tester pool for you guys
[15:24] <desrt> X guys need to have a talk with HAL guys, i think
[15:24] <desrt> and figure out what the correct thing to be doing here is
[15:24] <desrt> any workaround done at the vendor level in the meantime will be more or less at the "quick hack" level...
[15:24] <tjaalton> hal is just the messenger I guess
[15:24] <desrt> which is like, half of making a distribution anyway :)
[15:25] <jcristau> desrt: you know, you could send a mail to hal@ today, and get that fixed :)
[15:25] <tjaalton> right, hal is full of quirks
[15:25] <tjaalton> hal-info
[15:26] <tjaalton> desrt: but you should try removing the other match rule to see if it would work then
[15:27] <desrt> i'll just bug david on irc :p
[15:27] <desrt> it's actually really hard for me to check if adding that match rule would make it work
[15:28] <desrt> so i'm gonna hal-set-property instead
[15:29] <desrt> did you guys add nozap?
[15:31] <desrt> didn't fix it
[15:31] <desrt> i think X doesn't even look at the subdevice at all
[15:31] <desrt> i'm gonna try adding the linux device path to the parent node instead
[15:31] <tjaalton> you need to restart hal
[15:31] <desrt> i used hal-set-property
[15:31] <tjaalton> oh
[15:32] <desrt> i can't really make changes and restart... i'm running off of a livecd :)
[15:32] <tjaalton> sure you can
[15:32] <tjaalton> the console is right there
[15:32] <tjaalton> if it works
[15:33] <desrt> still no love
[15:33]  * desrt wonders what xorg log will have to say now
[15:34] <tjaalton> don't bother, just pastebin it ;)
[15:34] <desrt> still "no driver or path" even when i specify the serial path
[15:34] <tjaalton> there should be two entries for them
[15:34] <tjaalton> ?
[15:35] <desrt> i think X doesn't bother visiting the second one
[15:35] <desrt> possibly because it doesn't have the input capability on it
[15:35] <desrt> lemme try adding that
[15:35] <jcristau> X just looks for input.x11_driver
[15:35] <jcristau> afaik
[15:35] <desrt> well, it has that
[15:35] <desrt> i'll try adding the cap
[15:36] <jcristau> then it's missing input.device
[15:36] <tjaalton> oooh, right
[15:37] <tjaalton> it's looking more and more like a hal bug :)
[15:37] <tjaalton> it doesn't seem to handle serial devices too well
[15:38] <desrt> ahh
[15:38] <desrt> X looks for input.device key?
[15:38] <jcristau> yes
[15:38] <desrt> can that be a serial device instead of an evdev?
[15:39] <jcristau> maybe not
[15:39] <tjaalton> try :)
[15:39] <desrt> i got X to notice the second device node by adding the input capability, btw
[15:39] <desrt> but it still fails due to no input.device :)
[15:40] <desrt> wtf
[15:40] <desrt> well
[15:40] <desrt> something happened?
[15:40] <desrt> after so many X server restarts X decided that i was bored of looking at brown
[15:40] <desrt> and put a nice purple pattern on my screen
[15:41] <desrt> lovely as it is, i can't read anything anymore and my system appears to have crashed
[15:41] <desrt> i guess this can't be blamed on HAL bug :)
[15:41] <tjaalton> so no console anymore?
[15:41] <desrt> nah.  completely dead
[15:42] <desrt> my caps lock was flashing.  that's usually a bad sign.
[15:42] <tjaalton> ok
[15:42] <desrt> probably some weird race in the video driver or something
[15:42] <desrt> and after so many restarts i finally hit it
[15:42] <tjaalton> a feature in the drm driver
[15:42] <tjaalton> or so
[15:42] <desrt> yes.  feature.
[15:42] <desrt> "you've seen too much brown.  how about some lovely purple?"
[15:43] <tjaalton> how did you kill the server?
[15:43] <desrt> either the ubuntu livecd boot has gotten one hell of a lot faster or my new laptop is cooler than i thought
[15:43] <desrt> i logged out
[15:43] <tjaalton> ok
[15:43] <desrt> i think you guys enabled nozap
[15:43] <tjaalton> no, upstream
[15:43] <desrt> ah
[15:43] <desrt> that is my preferred way of restarting X :)
[15:44] <desrt> s/is/was/ i guess
[15:44] <tjaalton> still there to be enabled if you wish
[15:44] <tjaalton> just not on by default
[15:45] <desrt> erm
[15:45] <desrt> ok.  this is odd.
[15:45] <desrt> it's doing it again
[15:45] <desrt> this is the second time, now, that it has happened immediately after me adding input.device
[15:45] <desrt> i'm starting to suspect causation
[15:46] <desrt> i have no idea how that would work, though
[15:46] <desrt> but no capslock flash this time
[15:48] <desrt> maybe X has changed the video mode, but not put anything on the screen
[15:48] <desrt> then it goes to open the device and crashes
[15:48] <desrt> so i see the uninitialised screen -- purple
[15:48] <desrt> whereas had it gotten past opening the device, it would have gotten to the part where it puts non-purple stuff on the screen
[15:51] <tjaalton> dunno
[15:51] <desrt> i'm gonna try starting X under gdb over ssh
[15:53] <desrt> fecking network manager.  nm-applet appears to tear down the wifi when you take down X
[15:53] <desrt> grrr
[15:54]  * desrt stops caring for now and tries to get some real work done instead
[15:54] <desrt> maybe later :)
[15:54] <tjaalton> sure :)
[16:03] <Alexia_Death> desrt: http://a.death.pri.ee/watahod-0.4.1.tar.gz bonuspointd for figuring out without handholding how to use it.
[16:03] <LLStarks|Bored> hi. quick question. is there a reason why restarting x has been made impossible for laptops without a dedicated sysrq key?
[16:05] <bryce_> LLStarks, because people accidentally hit the key combo and it kills their x.  sysrq has little to do with it
[16:06] <tjaalton> LLStarks|Bored: try printscreen
[16:06] <jcristau> 'impossible'. heh.
[16:06] <jcristau> sudo killall Xorg still works :)
[16:11] <Alexia_Death> bryce_: its intentional that I cant kill my X with ctrl alt backspace? Awww... its such a usefull combo
[16:12] <tjaalton> Alexia_Death: sure you can, it's just not enabled by default
[16:13] <Alexia_Death> no clue how to enable it:P
[16:13] <jcristau> reading docs is hard
[16:14] <bryce_> Alexia_Death: read http://wiki.ubuntu.com/X/Config/
[16:15] <Alexia_Death> jcristau: figuring out if its a bioug ora feature that it does not work is hard:P
[16:16] <jcristau> Alexia_Death: fair enough
[16:18] <Alexia_Death> :)
[16:19] <jcristau> maybe i should add that in NEWS.Debian so i at least can beat people with that stick :)
[16:20] <tjaalton> heh
[16:45] <_MMA_> In Jaunty, what nvidia driver should one use for a GeForce 6 series card?
[16:58] <superm1> _MMA_, jockey isn't ready in jaunty yet, but you will probably need nvidia-glx-180 or nvidia-glx-177
[17:00] <_MMA_> superm1: Ok. I think I got -180 installed and I *still* (since Edgy) cant get my proper res back on the HTPC. So I'm thinking I need to use a legacy driver or something.
[17:00] <superm1> _MMA_, i would recommend holding off until jockey is ready.  it will be able to tell you what driver you are supposed to be using
[17:01] <superm1> resolutions are detected via the EDID of your television set generally
[17:01] <tjaalton> hmm so -180 supports the 6-series.. which means -177 should probably be dropped
[17:02] <_MMA_> superm1: And that's when my problems started. ;) My modline no longer worked. :)
[17:03] <superm1> _MMA_, if you have a bad TV EDID there are methods to add modelines.  You'll have to read the NV readme on their website for the exact options to let you do it though
[17:05] <_MMA_> superm1: Hell with it. I'll just stick with windows on the box 'till I build a new one. I've really put out tons posts and read alot to try to solve this. Gonna be easier to just buy new stuff.
[17:05] <superm1> _MMA_, the problem is most likely your TV set if the EDID is bad.  I'd check for TV firmware updates before you scrap all this
[17:05] <tjaalton> and not get nvidia this time?-)
[17:06] <superm1> tjaalton, TV's with bad EDID's don't handle so well with any of the drivers from what i've seen....
[17:07] <_MMA_> tjaalton: Well they still work better than ATI. :)
[17:07] <_MMA_> And I'm unsure if Intel can do 1080p. Still gotta look at that.
[17:08] <superm1> at least for the moment the hardware acceleration you get out of NVIDIA drivers for XvMC and libvdpau and what not makes them more attractive generally for HTPC's.
[17:08] <superm1> until Intel supports VA-API that will probably be the case
[17:08] <tjaalton> oh well, I'm happy to not need the craphics card (pun intended) on my htpc at all
[17:14] <_MMA_> superm1: Any of the jaunty players using XvMC and libvdpau now?
[17:20] <superm1> _MMA_, mythtv trunk does.  we may or may not be uploading it to jaunty though.  it's living in a PPA until upstream blesses it
[17:21] <superm1> _MMA_, I dont think ffmpeg is getting uploaded with the support until jaunty+1, so the rest of the apps will follow that
[17:22] <_MMA_> superm1: Ok. Maybe one day, I'll get this all sorted out. I can't even find a soundcard that works with SPDIF right. I have one, but have only had it work correctly once.
[17:22]  * _MMA_ shrugs.
[18:48] <LLStarks> note to self. holding down printscreen for 1 second yields 100 prompts.
[18:49] <LLStarks> alt+printscreen as well.
[18:49] <LLStarks> i can't access sysreq from this inspiron.
[18:49] <LLStarks> and if i can't  restart x on a whim, i'll be sad
[18:52] <LLStarks> also, i want to punch the google earth devs for having atmosphere on by default.
[18:52] <LLStarks> i know it sounds hypocritical with regard to my stance on uxa, but jeez.
[19:03] <tjaalton> does alt+prtscr+h work from the console?
[19:03] <tjaalton> should print out the hotkeys that work