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