[00:07] i haven't had an execbuff while wedged on this machine for 2 days now using the ubuntu-x stuff, i'm saying this because that usually triggers it soon after :) i have been using 2.6.31-16 though because I need working suspend/resume during the week and the lucid kernel still has the flickering problems post resume [00:08] but you've been able to reproduce it with that kernel? [00:10] yeah I have had it with this kernel before in the past, but I was using intel 2.9.99x at the time as well, never tried just 2.4.17 + this kernel [00:11] sounds like they are good to go then [00:12] i need to build a kernel with the patches attached to that bug to try to get more info for them to figure it out [00:17] to me it sounds like a bad combination of components [00:17] and not a real bug [00:20] hope so, but its affecting people on gentoo and arch as well at least and only i915-i945 from what I can see [00:21] ok [01:36] hmm seem to have hit a snag with tseliot's new nvidia packages [01:36] http://pastebin.com/f12e6f5a4 [01:37] looks like i had a custom /etc/modprobe.d/nvidia.conf with some options I was using before (that were commented out now) that didnt get replaced and screwed things up around line 243 [01:39] getting both of these in jockey too, dont know if thats normal [01:39] kmod:nvidia_current - nvidia_current (Proprietary, Disabled, Not in use) [01:39] xorg:nvidia-current - NVIDIA accelerated graphics driver (Proprietary, Disabled, In use) [01:41] jockey is used to do the update-alternatives command [01:41] which is how you get "enabled" [01:41] yeah pasted the jockey log and those two were listed in jockey-text [01:42] 2010-01-05 20:40:35,378 WARNING: /sys/module/nvidia_current/drivers does not exist, cannot rebind nvidia_current driver 2010-01-05 20:40:45,377 WARNING: modinfo for module nvidia failed: ERROR: modinfo: could not find module nvidia 2010-01-05 20:40:45,378 ERROR: XorgDriverHandler.enable(): package or module not installed, aborting [01:42] i get that when i try to enable the xorg:nvidia-current [01:43] dkms status [01:43] should say what driver, if any, is installed [01:44] nvidia-current, 190.53, 2.6.32-9-generic, x86_64: installed [01:44] the kmod activates fine its the xorg one that wont, theres 2 seperate entries in jockey [01:45] i think jockey's nvidia handler might need a patch actually to not list that twice [01:46] Sarvatt, make sure to let tseliot know about that issue if nvidia.conf exists before starting so that he knows it needs to get cleaned up in the jockey handler [01:46] or maybe even the packages themselves [01:46] it's telling you whatt he problem is: /sys/module/nvidia_current/drivers does not exist [01:48] test [01:48] oh ok message wasnt going through [01:48] /sys/module/nvidia/ exists but no nvidia_current, nvidia is listed in lsmod but modinfo doesnt know about nvidia just nvidia-current [01:48] because it started with a / :) [01:49] Sarvatt, i want to say that special /etc/modprobe.d/nvidia.conf resolves nvidia to be nvidia-current or something like that [01:49] which allows you to have multiple nvidia.conf's on your system [01:49] *nvidia.ko's [01:49] ahh [01:50] so if jockey failed to set that config because you had something there, it's gonna cause more pain later [01:50] * Sarvatt tries to figure out how to fix this [01:50] remove the driver packages and your nvidia.conf and reinstall them i think [01:50] def something that tseliot will need to account for [01:52] i'm just not near the box anymore and have to figure out how to use jockey-text to reinstall it because I thought I read manually installing nvidia-current wont set up alternatives right :D [01:57] ah yeah alias nvidia nvidia-current [01:57] i purged it and removed the .conf, rebooted, installed through jockey and it failed [01:59] i think it modprobed before linking the nvidia.conf or something that time [02:00] so it failed in failsafe mode and gave the error message but its working fine after rebooting [02:01] nope, using swrast [02:02] ERROR: XorgDriverHandler.enable(): package or module not installed, aborting [02:02] * Sarvatt wonders if theres some other required package not getting pulled in here [02:03] ick [02:07] Sarvatt, sudo update-alternatives --set gl_conf $(ld_so_conf_path) [02:07] sudo ldconfig [02:09] heya bjsnider, don't know if we've met. welcome to ubuntu-x :-) [02:09] whats the ld_so_conf_path supposed to be? [02:09] bryyce, bjsnider is the one maintaining the vdpau PPA with all sorts of newer drivers and stuffs [02:10] sweet [02:10] Sarvatt, hold, let me wade through these variables and reconstruct it [02:10] ah yes I remember running across that ppa [02:10] yes you did [02:11] i packaged that beta driver that got released because somebody broke an nda with nvidia and you asked me to remove it [02:12] oh yeah [02:13] Sarvatt, /usr/lib/nvidia-current/ld.so.conf [02:13] thanks again; that was looking like it could have turned into a big political mess but it all worked out well [02:14] no prob [02:14] i didn't leak it though. it appeared on a russian site and people were already installing it. the cat was out of the bag. nvidia should have just let it go [02:15] not the /etc/ld.so.conf.d/GL.conf that got installed with the xserver update? [02:16] they both are the same anyway [02:16] that's the command alberto says you need to run to manually enable the driver [02:17] does anybody know anything about opencl? [02:18] i'm trying to figure out of this huge shared library has to do with it [02:18] nvidia has helpfully not documented its existence or purpose at all [02:19] thats weird, the libglx.so / libdri.so alternatives didnt get set up in the xserver-xorg-core.postinst like they should have [02:20] Can't call method "slave" on an undefined value at /usr/sbin/update-alternatives line 1017. [02:20] ah hah [02:20] what is on that line? [02:21] http://pastebin.com/d73f439a3 [02:22] those slave alternatives arent getting set up here, ldconfig -p | grep libglx returns nothing [02:23] what is the undefined value? [02:23] supposed to be generic ones set up i thought and then alternatived out when you switch [02:24] can you cat the script and look at line 1017? [02:32] lrwxrwxrwx 1 root root 27 2010-01-05 20:55 /usr/lib/xorg/modules/extensions/libglx.so -> /etc/alternatives/libglx.so lrwxrwxrwx 1 root root 38 2010-01-05 20:55 /etc/alternatives/libglx.so -> /usr/lib/nvidia-current/xorg/libglx.so [02:32] that looks right but [02:32] [ 0.172246] (II) Loading /usr/lib/xorg/modules/extensions/standard/libglx.so [02:32] in Xorg.0.log [02:35] standard? [02:38] that path doesn't exist in the postinst script [02:48] Sarvatt, try removing /usr/lib/xorg/modules/extensions/standard/libglx.so === ripps|sleep is now known as ripps [03:50] hmm I think its here [03:50] --slave #LIBDIR#/xorg/modules/extensions/libdri.so libdri.so #LIBDIR#/xorg/modules/extensions/standard/libdri.so \ [03:50] --slave #LIBDIR#/xorg/modules/extensions/libglx.so libglx.so #NVIDIAEXTENSION#/libglx.so [03:52] need to look at the full postinst for nvidia-current, i'm just looking at the diff and its missing a bunch of it but libdri.so is getting set up right and libglx.so isnt [03:54] --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/xorg/modules/extensions/standard/libglx.so \ [03:55] --slave #LIBDIR#/xorg/modules/extensions/libglx.so libglx.so #NVIDIAEXTENSION#/xorg/libglx.so is what it should be I think [03:55] /usr/lib/nvidia-current/xorg/libglx.so [03:55] thats where it is here [03:56] that file exists? [03:56] yep [03:56] its in xorg/ not just nvidia-current/ [03:56] dont know how it worked for anyone if thats the case though [03:57] i mean the drivers work i just dont get any gl outside of swrast [03:57] it's been working for people as far as i know [03:57] ok, maybe that's it [03:57] maybe nobody but you has tested glx [04:00] thats just in the nvidia-current.postinst.in, in nvidia-current.postinst it has --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/nvidia-current/xorg/libglx.so [04:01] ok, well the .in is used to generate the other [04:01] so NVIDIAEXTENSION must be the correct path, ie. /usr/lib/nvidia-current/xorg [04:05] --slave /usr/lib/xorg/modules/extensions/libglx.so libglx.so /usr/lib/nvidia-current/xorg/libglx.so is what it is in /var/lib/dpkg/info/nvidia-current.postinst too, so much for that [04:06] sarvatt@sarvatt-hp:/var/lib/dpkg/info$ ll /usr/lib/xorg/modules/extensions/libglx.so [04:06] lrwxrwxrwx 1 root root 27 2010-01-05 20:55 /usr/lib/xorg/modules/extensions/libglx.so -> /etc/alternatives/libglx.so [04:06] sarvatt@sarvatt-hp:/var/lib/dpkg/info$ ll /etc/alternatives/libglx.so [04:06] lrwxrwxrwx 1 root root 38 2010-01-05 20:55 /etc/alternatives/libglx.so -> /usr/lib/nvidia-current/xorg/libglx.so [04:06] * Sarvatt is stumped. [04:07] do you still have /usr/lib/xorg/modules/extensions/standard/libglx.so? [04:10] yep, and the alternatives are switching away /usr/lib/xorg/modules/extensions/libglx.so/libdri.so instead of the ones in standard/ [04:11] if you dont have nvidia-current installed it sets up alternatives for /usr/lib/xorg/modules/extensions/libglx.so to /usr/lib/xorg/modules/extensions/standard/libglx.so [04:12] if the alternatives are switching away, why is your system trying to load the standard alternative? [04:14] the standard file should be a link. where does it point to? [04:19] sarvatt@sarvatt-hp:/var/lib/dpkg/info$ sudo update-alternatives --remove gl_conf /usr/lib/nvidia-current/ld.so.conf [04:19] update-alternatives: using /usr/lib/standard-x11/ld.so.conf to provide /etc/ld.so.conf.d/GL.conf (gl_conf) in auto mode. [04:19] sarvatt@sarvatt-hp:/var/lib/dpkg/info$ sudo update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf [04:19] update-alternatives: using /usr/lib/nvidia-current/ld.so.conf to provide /etc/ld.so.conf.d/GL.conf (gl_conf) in manual mode. [04:20] Can't call method "slave" on an undefined value at /usr/sbin/update-alternatives line 1017. [04:21] guess i should do some googling on Can't call method "slave" on an undefined value :) [04:22] i'd like to know what's on that line [04:29] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554136 [04:29] Debian bug 554136 in dpkg "u-a: --set fails with undefined value on non-registered paths" [Normal,Fixed] [04:37] i updated my update-alternatives with that commits changes and now i get [04:37] sarvatt@sarvatt-hp:/var/lib/dpkg/info$ sudo update-alternatives --set gl_conf /usr/lib/nvidia-current/ld.so.conf [04:37] update-alternatives: error: alternative /usr/lib/nvidia-current/ld.so.conf for gl_conf not registered, not setting. [04:39] http://pastebin.ubuntu.com/352132/ [04:39] thats my update-alternatives --display gl_conf output [04:40] There is only one alternative in link group gl_conf: /usr/lib/standard-x11/ld.so.conf [04:41] so the alternatives arent getting registered with the nvidia-current.postinst for some reason [04:45] yes, because of that error that points to "line 1017" [04:49] 2010-01-05 20:55:48 update-alternatives: run with --install /etc/ld.so.conf.d/GL.conf gl_conf /usr/lib/nvidia-current/ld.so.conf 9700 --slave $ [04:49] 2010-01-05 20:55:48 update-alternatives: link group gl_conf updated to point to /usr/lib/nvidia-current/ld.so.conf [04:51] installing from aptitude instead of through jockey, lets see if this works this time [04:51] Selection Path Priority Status [04:51] ------------------------------------------------------------ [04:51] * 0 /usr/lib/nvidia-current/ld.so.conf 9700 auto mode [04:51] 1 /usr/lib/nvidia-current/ld.so.conf 9700 manual mode [04:51] 2 /usr/lib/standard-x11/ld.so.conf 500 manual mode [04:52] thats more like it [04:55] nope still [ 0.106192] (II) Loading /usr/lib/xorg/modules/extensions/standard/libglx.so... ah well, enough messing around for tonight :D [05:04] wonder why it installs the nvidia libglx.so to /usr/lib/xorg/extra-modules as well [05:08] ah hah [05:09] i moved /usr/lib/xorg/extensions/modules/standard out of the way and it loads the libglx.so from /usr/lib/xorg/modules/extensions/ like it should which works with the alternatives [05:10] i guess xserver will look in subdirectories before following a link or something [05:10] [ 0.155733] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [05:10] [ 1.220630] (II) Module glx: vendor="NVIDIA Corporation" [05:11] so i guess standard/ needs to be moved somewhere else [05:13] hmm, need to leave libdri.so in standard/ the way it is now, just moving the libglx.so from in there works [05:13] otherwise i get [ 1.324256] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [05:13] dlopen: /usr/lib/xorg/modules/extensions/libdri.so: cannot open shared object file: No such file or directory [05:14] anyway, enough messing with it tonight for real, wifes bugging me :D thanks for the help [05:16] nvidia does not change libdri === cdE|Woozy_ is now known as cdE|Woozy [09:43] I reopened #494627 because my initial fix is no good, I attached a (trivial) new one - could someone please have a quick look if that makes sense and is upstreamable? it makes my nv system happy again [09:52] mvo: so that fix alone is enough to fix it? [09:54] tjaalton: yes, that makes it work for me - the fix itself is pretty obvious, but I don't know enough about the background to be 100% sure its the right fix. ie it might be a mandatory function (gamma_set). but I guess even then crashing is not the right approach ;) [09:55] tjaalton: that diff plus a revert of the stub function and my -nv system is back, the previous patch fixed the crash but colors were all messed up [09:55] mvo: ok, I guess the next step would be to post it upstream for a review then :) [09:55] (but only after cold restart, reboot was not enough this is why I did not catch it yesterday) [09:56] tjaalton: ok, cool. I will do that. [09:56] I mean if there is a chance of regressing other drivers [09:56] http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches [09:57] oh, nice. I did not know this page [09:57] it's quite fresh [09:57] and new [13:31] tjaalton: do you mind if I upload my changes to X from git? [13:36] tseliot: nope [13:37] tjaalton: also, it looks like libxvmc (in Ubuntu) is not maintained in git. Shall I simply upload my changes? [13:38] tseliot: there were no ubuntu changes before.. [13:39] well, occasionally yes, but [13:39] whatever you prefer [13:40] tjaalton: I think these changes are something we'll have to maintain as they are required by the new alternatives system [13:40] "we" meaning "I" ;) [13:41] tjaalton: (ignore the noise in the changelog which is from my ppa) this is the debdiff: http://pastebin.ubuntu.com/352317/ [13:42] ewww removing possibly modified. [13:42] +conffiles [13:42] yes, I know [13:43] if you can think of better solutions, I'm all for it [13:43] the problem is [13:43] that if the file already exists [13:43] i'd say alternatives in /etc are a bad idea [13:43] the alternative slave won't be installed [13:44] it's just a link there [13:44] which points to /usr/lib/whatever/realfile [13:44] it's still a bad idea. /etc is the admin's territory. [13:47] the use-case would be an admin which sets a different path to libXvMC.so.1 in /etc/X11/XvMCConfig [13:49] i guess so. i have no idea how xvmc works. [13:49] jcristau: would it be better to rebuild the package without that path and rely on ld.conf.d to find the library instead? [13:50] as i said, i don't know how xvmc works, or what uses this /etc/X11/XvMCConfig [13:50] ok [13:51] i'm just saying that from a packaging pov, having something in /etc which is managed by alternatives is asking for trouble [13:53] I see your point [13:53] libXvMCW_la_CFLAGS = \ [13:53] $(AM_CFLAGS) \ [13:53] -DXVMC_CONFIGDIR=$(sysconfdir)/X11 \ [13:53] sysconfdir is what it uses [13:53] hmm.. [13:56] superm1: thoughts on this ^^ [13:56] ? [14:01] jcristau: would it be better if I changed the place where libxvmc looks for settings to /usr/lib/whatever and used alternatives there? (I suspect that admins would be angry either way though) [14:01] yes, it's probably better [14:01] ok [14:15] tseliot, i found out why the 195 blob is so much bigger than previous blobs [14:16] bjsnider: why? [14:16] there is a massive shared library named libnvidia-compiler.so.xxx [14:17] they have also, without documenting it, decided to include the opencl headers/shared libraries [14:17] and i think the aforementioned file has to do with that [14:18] but without any documentation, i can't be sure [14:18] aah [14:18] i thought you might know [14:19] it's /usr/lib/libnvidia-compiler.so.xxx.xx [14:19] and there's also a lib32 version [14:19] I spent more time making sure that the stack markings on those libraries were disabled [14:20] stack markings? [14:20] without noticing what those libraries do ;) [14:20] yep [14:21] i don't know what that means [14:21] let me find the actual bug report [14:21] bug #409456 [14:21] Launchpad bug 409456 in nvidia-graphics-drivers-96 "upstream compiled binaries built without stack flags" [Medium,Fix released] https://launchpad.net/bugs/409456 [14:21] see the description [14:23] wel, whatever. is there any way i can look inside the first few lines of that file and see what it's doing at the start? [14:29] what file? The proprietary library? [14:30] yep [14:31] it's proprietary. It meant for you not to read it ;) [14:33] well, i guess i'll toss it in the legacy build scripts, since everything else in that directory is in there too [14:34] sarvatt had some trouble getting the glx side of the new driver to work last night [14:34] jockey didn't do the update-alternatives successfully [14:38] bjsnider: because I haven't uploaded jockey yet [14:38] or any other piece of the puzzle [14:39] oh, well that would explain it [15:38] tjaalton: I think I'll use a patch (with quilt) instead modifying the package (libxvmc) directly. Would this be better? [16:32] tseliot: I saw another problem when I was testing out your packages, if someone already has an /etc/modprobe.d/nvidia.conf the new one with the alias wont get linked [16:33] Sarvatt: true but how can we check that in advance? [16:34] users could even add some random diversion on the kernel module and break things [16:34] can you just call it something else that people wouldnt normally have? [16:34] (just an example) [16:35] in theory (unless they are advanced) users wouldn't have an nvidia.conf file in that directory [16:35] all the tweaking guides tell you to make /etc/modprobe.d/nvidia.conf, i had a custom powermizer setup in there [16:36] :-/ [16:37] shall I get rid of any conf files that mention nvidia in that directory? It seems a bit excessive to me [16:37] i'll try changing it to link it to /etc/modprobe.d/nvidia-current.conf and put my old nvidia.conf there and see if it works [16:38] Sarvatt: wait, what's the content of your .conf file? [16:38] or what used to be the content of that file? [16:39] i deleted it already :( it had some NVreg_RegistryDwords= options to change the default powermizer settings though [16:39] Sarvatt: ok and it referred to the nvidia module, not nvidia-current or some other name [16:40] so I guess it's just a matter of finding a different name for that link [16:40] yeah, imagine it would just either ignore those things because it cant find nvidia if the alias one gets loaded before, or load those options then alias it after if it loads the linked one later [16:42] we could use something like /etc/modprobe.d/nvidia-graphics-drivers.conf perhaps? [16:42] hoping that users won't bother writing names which are this long [16:42] ;) [16:43] yeah thats a pretty safe bet there :) [16:46] so we'd need an updated jockey for the libglx.so alternative to work? I had to move /usr/lib/xorg/modules/extensions/standard/libglx.so out of the way for things to work right, it was loading that even though the alternative was set up right for /usr/bin/xorg/modules/extensions/libglx.so [17:00] you'll need an updated X, jockey, etc. [17:00] I'll upload the different pieces soon [17:01] tseliot, setting up xvmc properly with nvidia is less important these days [17:01] all the cool kids just use vdpau when they use nvidia [17:01] so it might not be worth the troubles to configure it anymore and introduce a delta to libxvmc [17:02] superm1: something like this wouldn't be big: http://pastebin.ubuntu.com/352410/ [17:02] it's a quilt patch [17:03] only worry would be is if there is a lot of documentation that claims people go modify the old location [17:05] right, but that path won't be used any longer and we can document that [17:11] Ok [17:17] superm1: is that configuration file used for anything else or only for nvidia, etc.? [17:17] tseliot, i think it's only ever used when you do something with nvidia xvmc instead [17:18] ok, so no one should want to modify it [17:18] (in theory) [17:19] right [17:19] ok, good [18:10] Sarvatt: are you still running with powersave=0, or did that get fixed? [18:15] not fixed here without that, only fixed with powersave=0 with that one remove render reclock support commit here, i've just been using 2.6.31 if I need to suspend but other people in one of those bugs said reverting another commit worked without powersave=0 [18:15] trying to find that bug to find the commit now [18:17] http://bugzilla.kernel.org/show_bug.cgi?id=14781 [18:17] bugzilla.kernel.org bug 14781 in Video(DRI - Intel) "181a533 is causing severe screen flickering on 965GM" [High,Resolved: patch_already_available] [18:18] http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=patch;h=cf74ecbbff3e3b45bae61d28d2220f74d853e2f0 still needs powersave=0 here.. [18:20] Sarvatt: presumably with powersave=0, that patch doesn't change anything? [18:24] i'm assuming theres more to powersave than render reclock or else it wouldnt make sense that its fixed with powersave=0 and that patch === ripps is now known as ripps|sleep [18:28] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=181a5336d6cc836f05507410d66988c483ad0154 is the one people in the kernel bugzilla were saying could be reverted from 2.6.32 to fx it without needing powersave=0 [18:28] powersave AND the remove render reclock commit that doesnt apply to 2.6.32 I mean [18:30] i havent been able to test it at all, been trying to focus on one bug at a time and thats minor compared to the random crashing here but I imagine it's alot more important to you since you get it at first boot instead of just after resume [18:31] i'll try debian's .32 with powersave=0 when i get back to my 945 laptop.. [18:38] tjaalton: actually, I think it's more work to update a patch if the packaging changes [18:38] ij [18:38] damn [18:39] "uh" [18:39] oh tseliot went already [18:39] that's why I'm talking to myself [18:39] i dont understand why .32 with powersave=0 doesn't work unless that remove render reclock support commit is applied too but i'm 100% positive it doesn't here [19:04] more and more execbuf errors occuring... :( [19:26] hi [19:26] i was wondering how i could configure my wacom tablet since in lucid there is no Xorg.conf to edit [19:26] can somebody tell me? [19:27] the tablet works, but I would like to set the mouse to relative mode [20:57] tjaalton, any chance we'll get -wacom for a3? [20:57] tjaalton, er, I mean a2 === seb128_ is now known as seb128 [22:02] bryyce: sure, it only depends if it's based on the (non-available) debian version or a complete fork [22:03] no news from ron then? [22:03] given that a2 is coming up RSN, if we want it in for a2 does that imply we'd need to do a fork? What would that entail, just carrying a git snapshot or branch, or...? [22:04] jcristau: not since the latest email [22:04] hmm ok [22:04] he said he had some snapshots for a select few to test, and the results weren't too encouraging [22:04] and I asked for one to upload to a ppa first [22:07] bryyce: either 0.10.3 or a newer snapshot [22:08] I'm wondering if the results weren't encouraging, is it going to be any worse than the current situation? [22:09] well, apparently it would be worse to let people think there is a working driver available [22:09] that was his reasoning [22:09] hah [22:11] hrm [22:12] well, if it only takes pulling a git snapshot of xf86-input-wacom and there are no other dependencies, it sort of seems like it would at least be moving us in the right direction [22:14] it's just re-inventing the packaging that is pointless. I'd rather have whatever he has now, but the git hasn't been updated for a month (and doesn't have any packaging bits) [22:15] oh the packaging needs done too hmm [22:16] alright, well guess we can just put in a release note that wacom is totally broken and push it to a3 [22:16] tjaalton: do you know how a wacom tabled could be configured on ubuntu lucid? [22:16] wonder if the 0.10.1 i packaged up in edgers a few months ago even works, time to dig out a tablet [22:16] basically it's pretty similar to any other input driver, but there's xsetwacom and possibly other tools as well [22:17] wind-rider: you don't [22:17] tjaalton: one can't? [22:17] wind-rider: because there is no driver. evdev is used by default, and if it doesn't work.. well too bad. [22:17] wind-rider, see what we were just talking about ;-) [22:17] * hyperair wonders if anyone here uses the nvidia 9643 driver [22:17] it has been on the relnotes AIUI [22:18] tjaalton, bryyce: the tablet works, but i do not know how to configure it [22:18] there is pressure support, etc [22:18] still no libxcb sync? [22:19] jcristau: no, requested though [22:19] for a manual sync [22:19] wind-rider: so evdev doesn't support such features [22:20] tjaalton, I don't see mention of it at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview [22:20] I'll add it [22:20] tjaalton: evdev does support pressure support, but no relative / absolute setting? [22:20] wind-rider: I don't know [22:20] ummm [22:21] the xf86-input-wacom I packaged up on edgers a few months ago works fine in current lucid [22:21] just tested with a graphire 3 and an intuos 3 [22:21] http://pastebin.com/f798362b2 [22:21] all it took was some minor build rule adjustments [22:22] tjaalton, Sarvatt, bryyce: http://pastebin.ca/1740737 <--- here is an extract of Xorg.0.log [22:23] it sets the devices to absolute mode, but i'd like to use relative mode for the mouse [22:23] wind-rider: so try with xinput [22:23] ooh xf86-input-kbd got pulled from lucid? [22:24] jcristau: yep [22:24] wind-rider are you using xorg-edgers? [22:24] wanted to go to universe, so no reason to keep it there [22:24] Sarvatt: not yet [22:24] oh our logs look the same is why i asked [22:26] tjaalton, Sarvatt: i can call xinput set-mode "Wacom Graphire3" RELATIVE, but then I set this mode also for pen and eraser? [22:26] there are no separate pen, eraser and mouse devices [22:27] when calling xinput list [22:27] yes. for that you need a wacom driver. [22:27] surprise, you are not using the wacom driver [22:27] I've added a known-issue for this at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview [22:28] ok, now it's clear [22:28] thx for your help [22:30] * bryyce wordsmiths a bit [22:32] tjaalton: i'll try to talk to ron on irc, see where things stand.. [22:32] bryyce: nice, it's a bit incorrect though. wacom-tools -based driver doesn't work with xserver 1.7, it's not due to the hal removal [22:32] jcristau: thanks, I've seen him too every now and then [22:39] tjaalton, better? [22:39] bryyce: yeah, thanks [22:43] Sarvatt, I'd be interested in hearing more widespread testing of your wacom edgers package, although I'm hesistant to point people at that from the release notes [22:44] if the package is good enough for us to point people to, then we ought to just put it in lucid I suppose. [22:46] its not working, i am using evdev, sorry about that [22:46] hehe :) [22:47] looks like I cant rebuild the old wacom-tools thjaeger sent me that was working right on xserver 1.7 now either :( [22:47] ../../../src/xdrv/xf86Wacom.c:398: error: too few arguments to function ‘InitValuatorAxisStruct’ [22:47] that was back in july that it was working [22:48] I thought about mentioning that "some limited functionality may be available from use of evdev", but then I thought, if they're reading the release note about wacom, they probably already know this. ;-) [22:48] he's got a newer one in his PPA but its using hal only and not working either [22:53] tried making a little udev rule for it but no luck -- http://pastebin.ubuntu.com/352562/ [22:53] okie doke. If anyone finds out anything new/interesting about wacom in the next couple days let me know asap, otherwise we'll just check in again on it in a couple weeks [22:53] is the rule wrong maybe? [22:54] Sarvatt: no, it loaded fine [22:54] preinit failed [22:55] though I guess it should use some callout app like with hal, to init all the devices [22:57] try 0.10.3? also add some ErrorFs in preinit to see why it fails?