[03:15] Sarvatt: this round of x-x-v-i pwned my uptime =O [03:19] hyperair, newest upload of intel? [03:19] LLStarks: in xorg-edgers. [03:20] can you boot to desktop? what chipset? [03:21] LLStarks: it boots. it just doesn't stay booted for long. [03:21] LLStarks: i965 [03:24] hard crash? [03:24] x crash? [03:35] so right when i disable the pageflip disablement patch you start getting crashes again? [03:41] reenabled it in 0ubuntu0sarvatt6 [06:03] Sarvatt: how timely, eh. [06:03] Sarvatt: by the way, what was that environment variable you were saying the other day? i'm now having issues with bad frame rates [06:04] i suspect this time it's due to mesa, not xxvi [07:29] good morning [07:42] oh hey my frame rates are back [07:58] sarvatt, ubuntu5 is working fine. are you sure pageflip is the issue? how could i test it? [07:58] *sarvatt5 === Bernardo is now known as Bernardo|away [10:59] intel video driver is quite unstable these days [11:09] Bernardo ping [11:29] Bernardo should fix psb-kernel-source with 2.6.34 - http://dl.dropbox.com/u/1338581/Gma500/deb_lucid/psb-kernel-source_4.42.0-0ubuntu2%7E1004um2_all.deb [11:30] https://patchwork.kernel.org/patch/90678/! [13:01] Bernardo not working === BUGabundo is now known as BUGabundo_lunch === Bernardo|away is now known as Bernardo [13:35] lucazade ping [13:49] Bernardo [13:52] lucazade: how didn't that patch work? It doesn't compile, or the module doesn't load? [13:53] psb-kernel-source compiles correctly but during psb-kernel-reconfigure there is an error (i've unfortunately removed old logs arg!) === BUGabundo_lunch is now known as BUGabundo [13:56] merging xorg-server... [13:57] Bernardo http://mjg59.livejournal.com/116720.html [13:57] lucazade: I think there is still something broken in our dkms configuration [13:57] yes [13:58] i'm thinking i've applied tha patch in the wrong way...mmm.. [13:59] should be my fault [14:00] about the acpi, implementing the whole spec is beyond my knowledge and my available time... [14:00] yes, just for reference [14:02] let's open a issue for it... :) [14:20] Bernardo are you going to try the patch for psb-kernel-source ? i'm afraid was my issue [14:21] I can try it, but I don't have 2.6.34 here [14:21] ive used kernel ppa [14:21] I was looking at tseliot attempt, to see if I can understand what he tried to do and why it isn't working [14:22] ah cool.. hope you can find the issue [15:02] bbl, time to enjoy the sun === Bernardo is now known as Bernardo|away [15:02] bye [15:45] tjaalton: from experimental or unstable? :D [15:45] Sarvatt: experimental [15:46] \o/ [15:46] patches fixed, changelog edit remaining [16:12] alright, xserver merge pushed to git [16:14] thanks so much for doing that tjaalton [16:15] Sarvatt: it probably won't even build yet ;) [16:15] yeah i'll look it over in a few, someones putting ppa-purge in the archives and was asking me to look over the changes [16:16] tjaalton: do you know if they decided on xserver 1.8.x or 1.9 at UDS? just wondering if i should start with 1.9 on xorg-edgers [16:17] Sarvatt: 1.9 if it's released on August as it seems [16:17] that's what phoronix said, so it must be true [16:17] hehe [16:17] (http://www.phoronix.com/scan.php?page=news_item&px=ODI0Nw) [16:17] yeah michael was present [16:17] via irc [16:17] thats kinda scary since 1.8.x still has major problems months after release :) [16:18] what kind? [16:18] the 1.8.0 release was weird. [16:18] dri2 stuff [16:18] yeah .0 was bad [16:18] and ironically master is in better shape than 1.8.x :D [16:18] fedora is backporting a crapload of dri2/glx stuff from master to 1.8.x [16:20] 1.8.0 was basically "i said i'd release on $date, so let's put a version number on a random master snapshot even though it has a bunch of known bad bugs but i didn't look at bugzilla so it's fine" [16:20] http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-server/xserver-1.8.0-swap-fixes.patch?view=markup http://cvs.fedoraproject.org/viewvc/F-13/xorg-x11-server/xserver-1.8.0-glxdri2-resource-conversion.patch?view=markup [16:20] it was like a mesa .0 :) [16:20] tjaalton: pretty much :) [16:20] yeah but mesa makes no claim that a .0 release is stable :D [16:20] indeed [16:21] I knew it that I was looking at the wrong fedora tree :) [16:21] devel is left behind [16:22] timed-based releases... you need to wait for .2 to get something usable, but as long as .0 is released on time you can claim that you're doing good. [16:22] mm, wonder how lucid fits in there :) [16:22] then you get phoronix telling people they are using old crap because they aren't using .0's :D [16:23] i read fedora-devel from time to time, and there people are upset because they get too _many_ updates post-release [16:24] doesnt look like 1.8.x is going to get as much love as 1.7.x, still no -nominations [16:24] it's on the other side of the spectrum, if ubuntu is somewhat hard to get updates to [16:24] huh, well whot should take care of it? [16:24] tjaalton: dunno. only machine with lucid i've seen was a guy i helped out. some saved gnome-session meant it was trying to run compiz.real as window manager, but lucid got rid of the wrapper script so compiz.real didn't exist, so you had no window manager. [16:25] jcristau: I'm happy to start from a clean slate at work, since we'll migrate $HOME to a bigger system, shared with Win7, so no reason to keep the old and possibly broken configs [16:26] took me 2 minutes to fix it, but for somebody unfamiliar with it... [16:26] the gnome configs tend to gather some cruft [16:26] and it's up to the user to migrate the dotfiles [16:27] i guess so anyway, maybe it hasn't been decided yet hmm.. [16:29] jcristau: btw, what do you think of the xvfb-changes in ubuntu xserver, could those be applied to experimental as well? [16:29] haven't looked [16:30] - local/xvfb-run*: Add correct docs about error codes (LP 328205) [16:30] - local/xvfb-run: Use "-extension Composite" to fix xvfb-run crashing. [16:30] Launchpad bug 328205 in xorg-server "xvfb-run incorrectly states that the return value is always that of the script run" [Wishlist,Fix released] https://launchpad.net/bugs/328205 [16:30] seems to run fine without disabling composite? [16:31] so that part might be obsolete [16:31] ok [16:31] the other one sounds fine, need to look at the patch. can you send me a mail so i try and do that? [16:32] sure [16:32] jcristau: so does debian delete saved gnome sessions on major upgrades? [16:32] Sarvatt: no idea [16:33] probably not, you can't delete user files from maintainer scripts.. [16:35] thats pretty nasty but the user had to manually enable saving the sessions like that to get to that point I guess [16:35] if he did, he didn't remember.. [16:37] sounds like a bug in the session saver [16:37] it should cover situations like that [16:38] but I guess it's not widely used [16:38] or even maintained :) [16:39] ++ - rules: Xvfb depends on xauth, x11-xkb-utils, recommends [16:39] ++ libgl1-mesa-dri. (LP 500102) [16:39] Launchpad bug 500102 in xorg-server "xvfb fails to start, missing dependencies on xauth and x11-xkb-utils " [Undecided,Fix released] https://launchpad.net/bugs/500102 [16:39] that's control, not rules ;) [16:39] hah [16:40] quite a pile of ubuntu patches still :/ [16:40] fixed.. [16:40] yep [16:40] 25 [16:40] used, three commented out [16:40] hmm i would think the session should be calling the generic window manager name instead of compiz directly like that? [16:41] then it would be sensible, and that can't be now can it ;) [16:42] yeah i guess its complicated by gtk-window-manager being seperate, i really dont know [16:42] i've been doing xorg-edgers with only 6 patches total to xorg-server [16:44] 109 is upstream now. not sure about the rest. [16:44] 001_fedora_extramodes.patch 106_nouveau_autodetect.patch 168_glibc_trace_to_stderr.patch 188_default_primary_to_first_busid.patch 189_xserver_1.5.0_bg_none_root.patch 191-Xorg-add-an-extra-module-path.patch [16:48] tracking down the authors for a ton of these patches to get them to do a git formatted patch with attribution is a PITA when the patch is 4 years old+ :) [16:49] heh, i was expecting nettle to be in universe, turns out it seems to be in main.. [16:50] yeah me too [16:50] need to as cjwatson when keyboard-configuration is in.. [16:50] *ask [16:51] it'll probably be a month until all the udeb packages are accepted :D [16:52] need to merge mesa too [16:53] is it ok to file sync requests for things in experimental? [16:53] sure [16:53] but we can sync as well [16:53] Sarvatt: is there any interest in ubuntu for the graphical d-i? [16:53] jcristau: i believe so [16:54] at least since cjwatson merged libx11 [16:54] ok [16:55] yeah he filed bugs.debian.org/581524 when merging it [16:55] i'm really not sure but I dont imagine so, he merged libx11 because at least 10 packages were in depwait for it :D [16:55] heh, ok [16:55] but at least I've been asking for it :) [16:56] to make preseeded installs prettier :) [16:56] :) [16:56] Sarvatt: dep-wait on new libx11? weird. [16:59] yeah everything that was in depwait for libx11 1.3.3-2 is now in depwait for libxext :D [16:59] the installer components maybe? [16:59] so if he didn't create a delta there then we should see an Xified d-i for maverick [17:01] ah right cairo and friends had bumped build-deps for the udebs [17:05] everything building udebs for the new d-i had the build deps bumped on the versions also building udebs it looked like, made building all of the libs on xorg-edgers tricky since theres no automatic rebuilds there for depwait :) [17:07] helped though since its a pain in the butt building all the libs in the right order and making sure they're published before uploading the next anyway [17:29] Can anybody tell me what has happened to org.x.config dbus interface? [17:29] gone [17:29] Why? [17:29] Wnd what replaces it? [17:30] It was the only way I could load a separate wacom device for each of my pens. [17:30] wacom hotplug has been working without it for some time [17:30] tjaalton: Hotplug yes, but it does not let me have more than 3 devices per tablet. [17:31] why not? [17:31] tjaalton: my 4 intos pens can provide 8 devices. [17:32] tjaalton: Can you provide me a link that tells me how to configure tools identified by tool id? [17:32] man xorg.conf [17:32] search for InputClass [17:33] should do what you want [17:36] tjaalton: Thanks. Will look into it. But if it does not, I will be back to complain, because I really need the hotplug per pen. 3 devices per tablet just dont do it. [17:36] then you build your own xserver [17:37] or fix the driver [17:38] tjaalton: is the option to build the dbus interface still there? [17:38] seems to be [17:38] ok. I havent been following X development lately :P [17:38] me neither, but this is what i know [17:39] Sucks tho if I have to go back to the same trick I did in intrepid. [17:39] the option is still there, but you get to choose between that and udev. [17:39] dbus requires hal, dont think you can use it with udev [17:39] yeah what he said :D [17:40] sigh... I KNEW there was going to be trouble with this. [17:41] Any explaining links on the InputClass thing? [17:42] http://who-t.blogspot.com/2010/01/new-configuration-world-order.html [17:42] man xorg.conf really does explain it well but this is good too - http://fedoraproject.org/wiki/Input_device_configuration [17:43] Ok, thanks. [17:43] Wacom is still packaged on its own for X and installs stuff for its own use, right? [17:44] i'm not quite sure what you are doing but /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules might be worth looking at too [17:45] not really :) [17:45] the links are pretty much useless these days [17:45] Sarvatt: I have a wacom intuos tablet and 4 pens. They provide 8 devices in total. I want X to understand that. [17:47] so you want each stylus device to have different settings? [17:49] yep [17:50] you could do that before? it could tell which stylus you were using when you switched automatically? [17:50] Yep [17:50] Its a driver feature. [17:50] I load an instance per my device with tool ID set. [17:51] Then, events come from the device with the matching tool id. [17:51] thats why I was thinking you might need to edit the udev rules since i think it only makes 1 stylus device per tablet now [17:51] Sarvatt: I used to do this through the dbus interface. [17:51] the udev rules don't create them [17:51] What does? [17:52] xorg.conf.d snippet [17:52] well no [17:52] the driver does [17:52] when it loads [17:52] ? [17:52] detects the model and creates what it supports by default [17:53] tjaalton: Theres no way for me to configure N devices with tool ID-s then! [17:53] well how did it work with dbus? [17:53] if udev knows about the devices then surely you can [17:53] tjaalton: I called AddDevice for each device I wanted cerated. [17:54] tjaalton: Udev cant know about the pens. [17:54] tjaalton: Theres ever just one at a time in the range. [17:54] then raise the issue on linuxwacom-devel [17:54] Sigh. [17:55] It worked perfectly for me in karmic and now people have forgotten about this usecase AGAIN. [17:55] i was thinking there may be a way to create the 4 pen devices in the udev rule, then assign them in the xorg.conf somehow [17:55] there's no way to turn that on [17:55] dbus support that is [17:55] so you're screwed anyway [17:56] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576136 [17:56] no, but something needs to be provided for this usecase. [17:56] Debian bug 576136 in xserver-xorg-input-wacom "xserver-xorg-input-wacom: multiple pens not handled" [Important,Open] [17:56] I know this guy. [17:56] I wasnt aware it was this bad on the X side tho. [17:57] so the logical step is to raise the issue on the devel list, no? [17:57] tjaalton: I will, no worries about that. I need to have this working. [17:57] if the 2 people who use that just complain 6 months after stuff gets done, you're not going to see stuff improve [17:57] yeah bringing it up on linuxwacom-devel would be the best step for sure if you wouldn't mind [17:57] Alexia_Death: why do you know udev can't handle it [17:57] ? [17:58] tjaalton: Becase I know how it works. [17:58] tjaalton: the device IDs need to be read before they can be used from a fully configured device. [17:58] only driver can do that. [17:58] read from where? [17:59] jcristau: Its a code the pen provides with its data. [17:59] jcristau: And I would have complained sooner had I known it was going to get all broken again. Like I said, all worked in karmic. [18:00] Alexia_Death: so the driver reads events from the tablet, and gets the code from there? what prevents it from creating a device for that pen at that point? [18:00] (besides "events are read in the signal handler, and creating a device is not signal safe") [18:01] jcristau: I dont know. May be it is possible. [18:01] may be easier to have an xorg.conf option to list the pens you want to use [18:02] jcristau: I want them hotpluggaable. [18:02] ok [18:02] jcristau: its a laptop [18:02] Cant runna round with my intuos permanelty connected. [18:02] err. [18:02] so with how you had it before, you didn't specific specifically that there were going to be 4 pen devices? you could add a 5th and it would pick the default settings for it? [18:02] not sure what you mean [18:02] that's why you use InputClass [18:03] the new pens wont be new devices to udev to get picked up by InputClass though? [18:03] tjaalton: ? I read the section and I cant say how it covers my usecase. [18:03] Sarvatt: no [18:03] yeah saying why I think that wont work [18:03] Alexia_Death: if you can configure it in xorg.conf, then you are able to do it in a hotpluggy fashion [18:04] Alexia_Death: if the driver had, say, Option "number of pens" "10", then it could create 10 devices for your pens when the tablet was hotplugged, and then use that. would that work for you? [18:04] jcristau: no. Each pen is specific and has an ID. Some of them have an eraser, some of them dont. [18:05] Alexia_Death: have you even tried lucid? [18:05] tjaalton: Im typing this from lucid [18:05] ah, k [18:05] Alexia_Death: not sure what that means.. [18:05] tjaalton: did a clean install today. [18:05] Alexia_Death: pretend i've never seen a tablet [18:06] the driver itself creates the eraser device so that should be ok [18:06] jcristau: Most wacom pens have two ends, stylus, and eraser. For X they are separate devices. [18:06] for the driver [18:06] not x [18:06] Alexia_Death: and the driver can't recognize whether something is stylus or eraser when it gets events? [18:07] jcristau: High end tablets support a Tool Id on each pen and driver supports or used to support several pens as independent devices. [18:07] jcristau: yes. [18:07] Alexia_Death: do you know if I can use a graphire pen with an intuos to test this? [18:07] i have an intuos 3 and a few graphires [18:07] Sarvatt: No. you need an intuos or cintiq for this. [18:07] so who's going to buy me another pen for the intuos4 :) [18:07] only 1 intuos pen though [18:07] lol [18:08] Sarvatt: and atleast 2 pens. [18:08] the airbrush looks nice [18:08] tjaalton: Get an artpen. Then you get the full pain. 100€ [18:08] Alexia_Death: they all are normal pens? [18:08] that you have [18:08] tjaalton: No, I have 2 normals, an arpen and an airbrush. [18:09] i mean the driver should know what they are, at least the kernel driver has something about it [18:09] tjaalton: got a full set for gimp development/testing but I hneed the stack underneath to work for that:P [18:09] maybe it's just that hotplug doesn't work [18:09] yet [18:09] tjaalton: As far as i know, artpen/arbrush are somehow diefferent from normals but IIRC not frm each other. [18:10] tjaalton: Problem is the multiple pen hotplug et all. [18:11] do we even need the wacom udev rule? [18:12] Sarvatt: for serial devices yes [18:12] ah yeah [18:12] but other than that no [18:13] ron knows about it, and probably will clean it up later [18:13] ah wait yeah, I couldn't use wacom without an input/whatever symlink it recognized last time i tried [18:14] then your conf is wrong ;) [18:14] and looking for the path [18:16] this was back in january before the xorg.conf.d stuff anyway [18:16] ok [18:19] so mesa won't build due to libdrm being too old [18:19] but uploading libdrm would break nouveau? [18:19] mesa merge pushed [18:20] in a minute.. [18:20] nouveau is broken by new kernel anyway aiui [18:20] ah right [18:21] Alexia_Death: it looks like you can add the 4 stylii to xorg.conf and seperate them by serial number? [18:22] Sarvatt: Yes. but I need hotplug [18:22] it basically still is [18:22] ? [18:22] I know it sucks, but why couldn't you just create all 4 in the xorg.conf? [18:23] you plug in the tablet, and it'll use the settings when the pen is in vicinity? [18:23] they should work on the fly switching them if you did [18:23] Sarvatt: Its a laptop. I dont want to restart X when I plug in the intuos. [18:23] ... [18:23] and keeping it connected at all times is not anoption. [18:23] you wouldn't have to, just define all 4 pens once and they should work on the fly whenever you used them [18:24] Sarvatt: sure about that? [18:24] of course [18:24] that's the point of inputclass [18:24] Option "DebugLevel" "6" to the wacom rule, then grep your Xorg.0.log for serial_num t for the serial [18:25] tjaalton: Uh? Inputclas? [18:25] well, one of them anyway [18:25] Alexia_Death: read the blog or wiki links we gave you [18:25] and have Option "Serial" "whatever" in each stylus device section and give them unique names [18:25] tjaalton: reading as I go- [18:26] Sarvatt: inputclass doesn't let you create more than one device per kernel device though, i think [18:26] tjaalton: But from what I see, the input class does not allow me to add four devices. [18:26] Sarvatt: so that would require driver options to tell it how many pens to create and their parameters and stuff [18:26] (maybe that already exists, i know nothing of wacom) [18:26] ok, so back to the driver [18:26] jcristau: exactly what I understood. [18:27] tjaalton: yes. so Im going to bother whot about this. [18:27] Alexia_Death: on the list preferably [18:27] tjaalton: I suspect the driver will end up with options where you can list any ID-s you need added. [18:28] tjaalton: Im not subscribet to that list. [18:28] tjaalton: only the user one. [18:28] listing the IDs in the config is kind of lame though [18:28] Alexia_Death: if the driver has a way to know the devices it can handle, it should be doable to make it hotpluggable [18:28] would be better to have something more dynamic [18:28] i'm certain that it can be done [18:28] Im not. [18:29] As a user I may not want any outospawning of a new device. === Bernardo|away is now known as Bernardo [18:30] hi [18:30] A device that a) I havent named and b) I havent configured in gimp etc so it wont auto-work as extended. [18:30] Sarvatt: what did you want to sync btw? [18:31] Alexia_Death: that's fine, if you get a new X device that lets gimp know about it so you can name/configure it [18:31] and client policy can disable unknown new devices [18:31] tjaalton: http://sarvatt.com/downloads/libdrm/ [18:31] oh sync, pixman [18:32] Sarvatt: no need to file a bug about it, I can sync it too [18:32] pretty significant arm speedups in the latest pixman stable compared to 0.16.4 [18:33] jcristau: its disrupting to the workflow. and at least for now, hoplugged devices require a reastart on GTK side to appear. [18:33] the ubuntu delta in pixman can be dropped [18:33] its upstream now [18:33] Alexia_Death: that'd be a gtk bug.. [18:33] jcristau: its a lack of feature. [18:33] whatever :) [18:34] jcristau: theresa branch that teis to remedy it. But its far feom stable. [18:34] still, should be easy enough to have a session daemon disable unknown new wacom devices [18:35] jcristau: I fail to see the point of this. [18:35] It jsut makes my tablet/pen not working. [18:35] how so? [18:35] disable means not functional, no? [18:35] you said you didn't want unknown devices enabled before you configure them [18:35] Sarvatt: so we don't need any Breaks for libdrm or so? [18:36] tjaalton: breaks on old xserver-xorg-video-nouveau would make sense imo [18:36] jcristau: yep, read the thread on debian-x [18:36] jcristau: what I meant was, that having to configure mid work is distracting. If you hold the pen, disabling it to configure just does not make sense. [18:37] you're adding new pens mid work? [18:37] if not then i don't understand the 'distracting' point [18:37] I might, if I have a pen I havent used before. [18:38] I have four pens. If I dont explicity configure them in one go, it may be that I grab a new pen. [18:38] hmm not sure i understand. you said you don't want new pens enabled before you can name/configure them. then you say you want to be able to add a new pen mid work, but not have to configure it. [18:38] shouldn't the kernel have breaks too in that case? [18:39] Sarvatt: the kernel shouldn't break userspace ABI... [18:39] jcristau: I think i cant explain it properly. [18:39] Alexia_Death: maybe i'm just slow :) [18:40] jcristau: Reality is, that I will have to show each device I plan to use to the tablet before starting gimp If I cant explicitly configure them. [18:41] well libdrm breaks x-x-v-nouveau which needs a rebuild against it, 2.6.34 breaks libdrm/x-x-v-nouveau but 2.6.33 still works with the older libdrm/nouveau, the new libdrm doesn't work with 2.6.33 based kernels, such a mess [18:41] jcristau: tablet does not know anything about a pen untill it starts sending data. [18:41] Alexia_Death: that's because gtk can't handle devices appearing after it's started, right? [18:42] jcristau: yes. And I dont expect it to be fixed in next 6 months, maybe more. [18:42] okay [18:42] Sarvatt: and the default on maverick is still .32 [18:42] Alexia_Death: i think i'm starting to understand :) [18:42] :) [18:42] i got upgraded to .34 a few days ago [18:42] oh [18:42] that's good [18:43] they uploaded the meta before the kernel even built, pointed at one that failed [18:43] Sarvatt: package dependencies can't really express userspace/kernel abi issues. since you can have more than one kernel installed, e.g. [18:43] so nouveau is broken anyway [18:43] I'll just upload then :) [18:43] yeah I was just thinking out loud and realized that after [18:44] though if there are people on .32 because of that.. [18:44] there's more abi thats not even tracked in libdrm for nouveau in the form of nouveau_class.h.. [18:44] won't help them anyway [18:44] at least thats gone post 2.4.20 [18:45] but the ddx needs an update to build against 2.4.20, or just updated past when the ddx started shipping nouveau_class.h and ignoring libdrm altogether [18:46] i put both in x-updates for people trying to use the lucid kernel a few days ago [18:46] err maverick kernel [18:48] ok, libdrm uploaded [18:51] Exception: apt-cache madison does not contain pixman/maverick [18:51] meh [18:53] thanks tjaalton, I need stuff to add to a MOTU application :) [18:53] hmm [18:54] maybe because it was copied over from lucid? [18:55] or missing deb-src maverick in sources.list? [18:56] apt-cache madison pixman [18:56] pixman | 0.16.4-1ubuntu2 | http://us.archive.ubuntu.com/ubuntu/ maverick/main Sources [18:56] it was an older version, the one from bzr works [18:56]