[06:39] pwnguin: the tablet-thread on u-d-d [06:50] heya tjaalton [06:51] s/thread/war/ [06:52] wgrant: well that too [06:54] bbl-> [06:56] ah, i dont actually read u-d-d [06:57] im a bit dissapointed that vicenzo didn't send any mail to the toshiba tablet team he started [07:32] bryce: hey dude [08:06] hmm, writing this mail could take the whole day [08:27] tjaalton: which email? [08:33] bryce: the follow-up to the tablet-thread [08:33] actually, I'll start a new one === wgrant_ is now known as wgrant [08:42] tjaalton: ah, ok; I ignored that thread (just looked like a flame war) [08:44] It's certainly getting that way... [08:44] people don't realize that things do work just like before if they want to [08:45] bryce: and that's the reason why I'll start a new thread.. [08:49] night [08:51] night bryce [09:05] dammit, forgot to remove the sig [09:36] tjaalton: Heh, I wondered if you intended to send that. [09:37] tjaalton: Is the XI property API stuff in your PPA done? [10:17] oh :) [10:17] Not entirely what I expected... I presume an X crash combined with some bad kernel interaction. [10:17] Damn video drivers. [10:19] wgrant: evdev uploading [10:20] I guess this means yet another input driver ABI bump... [10:21] only those that support properties, which is evdev/syaptics [10:21] +n [10:21] Are you sure? There seems to have been a renumbering of some constants in the first patch. [10:22] hmm [10:22] (I'm looking at the one sent to the list, not the one you applied, so I might be wrong) [10:22] well, does evdev work for you otherwise? [10:23] It seems to. [10:23] I have devices. [10:23] wgrant: the patch sent to the list applied to master, which has all the XI2 changes [10:23] I have a minimal xorg.conf. [10:23] So I presume evdev is working its magic. [10:23] jcristau: I suspected something of the sort. [10:23] So it's probably not as dangerous as I initially suspected. [10:23] the backported properties only changed the numbering of the new stuff [10:24] the XI 1.4 stuff hasn't changed, so only property-using drivers are affected [10:24] OK, excellent. [10:24] might be good to at least bump serverminver though [10:24] sigh, so many places to touch :) [10:26] * wgrant kicks buildd-master. [10:26] I've forgot what was the name of the function that wacom should use in order to be able to init multiple instances using the same driver [10:26] There are 10 idle i386-xen buildds, yet the build hasn't started. [10:26] NewFoo.. [10:27] NIDR, i think :) [10:27] oh right, not NDIR:) [10:28] lunchshlibs for libxi6 [10:29] whoops [10:29] *lunch -> [10:29] Mmmm. lunchshlibs. [10:50] tjaalton: Still hardlocks... any idea how to debug this? [11:35] how come we're blacklisting eaglelake? [11:35] (that's G45/X4000, right?) [11:58] Ng: no, something newer [11:59] wgrant: could be that the evdev upload was incomplete, but can't check right now [12:00] I'm at a seminar.. [12:02] (II) intel(0): VESA VBE OEM: Intel(r)Eaglelake Graphics Chip Accelerated VGA BIOS [12:02] that's in my Xorg.0.log at home, which is a G45 [12:02] I have no idea what Intel codenames mean, I just remembered that from logs [12:03] ok, bryce said it would be something experimental [12:03] http://ark.intel.com/chipsetgroup.aspx?codeName=26554 [12:03] maybe a newer revision [12:05] well it's different to the PCI ID I have [12:10] ok [13:04] jcristau: is NIDR a part of the input-hotplug stuff that daniels wrote? [13:04] yeah. but it's not exported to drivers atm i think [13:07] right, looked through the changelog.. magnus even did some fixes to it last year [13:10] unfortunately he's the only one who seems to care about wacom with current servers. too bad he seems to be doing something else atm [13:10] I mean, work or real life [17:57] tjaalton: what needs done for wacom? [17:57] (heya btw) [18:00] bryce: a lot, but it's upstreams headache [18:02] probably needs rework due to input-hotplug-ness [18:03] I wonder what that entails [18:03] afaik, input hotplug has some work done on it [18:03] its the serial devices like tabletPC that get the shaft [18:04] pwnguin: any ideas on how those could be handled via i-h, or is it completely impossible? [18:04] i-h is the hal stuff? [18:05] my theory has been to detect the laptop model and set it up that way [18:05] ah good call [18:05] i-h != hal, but they do come together [18:05] but i have no clue how to write .fdi rules for that [18:05] or rather, i-h relies on hal [18:06] ah, see http://wiki.ubuntu.com/X/Config for examples [18:06] fdi files are pretty straightforward once you get the hang of them [18:06] well, as straightforward as XML can be straightforward [18:06] whats the difference between append and merge? [18:07] wacom already has an fdi file, that's not the point [18:07] well, I haven't seen a formal definition, but my guess is that append adds a new entry, and merge combines your new settings with any pre-existing settings already made [18:09] to fully enable the device, you'd need to open it several times (pen/stylus/..) and that's not possible with hal [18:09] so the driver needs to be reworked to use NewInputDeviceRequest [18:09] the problem is that it's not exported to drivers as jcristau pointed out [18:09] I'm not sure if master is any different [18:10] tjaalton: that should be easy to fix [18:10] jcristau: well yes, but to make the driver use it?-) [18:10] well, hopefully not too hard [18:10] whot said that -joystick has some hack to work around the current situation, but NIDR is the preferred way [18:11] but, i've never looked at linuxwacom code, so... [18:17] jcristau: bug 276357, looks fine for debian as well? [18:17] Launchpad bug 276357 in xorg "disable xauth for local users" [High,Triaged] https://launchpad.net/bugs/276357 [18:18] * Ng sure there is deeper borkage to be found in changing your hostname, but I can't specifically name anything [18:19] I'm just sure that NM shouldn't be doing insane things with my hostname just because I join a network :( [18:20] NM shouldn't change your hostname [18:20] that's utterly wrong and broken, imo [18:20] but isn't xauth useless for local users? [18:23] why? [18:23] tjaalton: run "xauth list" :) [18:24] jcristau: I agree, but there are people who will be netbooting dozens/hundreds of identical images and setting the hostname from DHCP, which NM is likely to be doing from 0.7 [18:24] it really is growing into a full system-wide network interface configurator [18:24] it really has no business setting the hostname... [18:36] tjaalton: ideas on lp #275825 [18:36] Launchpad bug 275825 in xorg "X does not detect a keyboard after upgrade" [Undecided,New] https://launchpad.net/bugs/275825 [18:36] ? [18:40] bryce: evdev not installed? [18:41] maybe xserver-xorg-core should depend on it [18:42] yeah [18:42] jcristau: maybe I just don't see the point in it [18:43] or dcbw for that matter ;) [18:43] tjaalton: this is seen only on upgrades, not fresh installs. My guess is maybe there was some old hal bits that omitted the x11 _driver? See http://heh.fi/tmp/x-problem/x.log esp at the end [18:43] I remember seeing a bug about this before, where the user changes the hostname from X [18:43] um, "when X was running" [18:44] tjaalton: -evdev is installed [18:45] bryce: dunno, would have to look closer [18:45] http://heh.fi/tmp/x-problem/lshal is the lshal output - note that input.xkb.model = 'evdev' [18:46] but not driver [18:46] right [18:52] What's responsible for setting input.x11_driver? [18:53] debian-setup-keyboard [18:53] check /etc/hal/fdi/policy [18:54] debian-setup-keyboard doesn't seem to set anything resembling input.x11_driver [18:54] On another box that has been running intrepid for a while, input.x11_driver is correctly set. [18:54] right [18:54] it doesn't [18:55] but /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi does [18:55] older hal maybe? [18:55] That file looks right. I'll take a better look. [18:55] or you have some fdi files lying around that break it [18:56] I just installed a fresh 8.04 and then ran do-dist-upgrade -blahblah [18:56] And X didn't find HIDs. [18:59] cool, a new background image [19:00] ion_: heh.fi is down? [19:00] hm no [19:03] hald with --verbose=yes didn't seem to print anything interesting. [19:03] ion_: I don't see any keyboards in the lshal output, btw.. [19:03] bryce: what does EDID quirk: Detailed timing is not preferred, use largest mode at 60Hz mean? [19:04] tjaalton: How about the "AT Translated Set 2 keyboard"? [19:05] ion_: oh, right :) [19:05] bdmurray: that means a quirk is needed for working around monitor brokenness [19:05] bdmurray: see http://wiki.ubuntu.com/X/Quirks [19:05] ion_: still, 10-x11-input.fdi is not run [19:05] or read [19:05] So it seems. I wonder how to debug that? [19:05] I'll strace hald. [19:06] bryce: could the quirk be new between hardy and intrepid? [19:06] bdmurray: basically it means that the edid from the monitor was saying "I like resolution foo", but that can't be trusted, so instead pick the highest resolution at 60Hz [19:06] bdmurray: maybe; I'd need to check [19:08] bryce: the quirks page doesn't say where to find the files with quirk information [19:08] bdmurray: which info exactly do you need? [19:09] tjaalton: re: localuser.sh, it probably makes sense to add it. i guess i'd just like the NM people to stop being crazy... [19:09] jcristau: yeah that's another story ;) [19:09] bryce: I was jut looking at bug 273543 and saw that message in Xorg.log [19:09] Launchpad bug 273543 in xorg "Laptop external screen resolution wrong" [Undecided,New] https://launchpad.net/bugs/273543 [19:10] bryce: Additionally, it seems like if the wiki page tells people a file to check it'd be useful to know where that file can be found [19:11] ion_: --verbose should show the order the fdi files are loaded [19:13] bdmurray: ah, it does say a couple paragraphs above that, the file is in the file hw/xfree86/modes/xf86EdidModes.c, however I could see how that's missed. I'll update. [19:14] I renamed /var/cache/hald/fdi-cache away, it works now. According to strace, hald stat'd the x11 fdi file but never opened it. [19:14] bryce: right, where can I look at that file? [19:15] ion_: did you reboot? [19:15] ion_: after the upgrade [19:15] bdmurray: it's in the xorg-server package [19:16] Yes [19:17] ion_: bug pitti then, that cache should probably be removed at some point :) [19:17] Perhaps hald's postinst should just rm it. :-) [19:17] I'm not sure if it was from the hardy install or what [19:17] but nice that you found out why it didn't work [19:22] gone -> [19:22] bryce: there's no bug number referenced for the quirk used... [19:24] bdmurray: bummer [19:24] * bryce looks at the bug again [19:26] seems like it's just different choices for initial configuration between the two xserver versions [19:31] bdmurray: /* Acer AL1706 */ [19:31] if (memcmp (DDC->vendor.name, "ACR", 4) == 0 && [19:31] DDC->vendor.prod_id == 44358) [19:31] return TRUE; [19:32] (found by searching on the prod_id number) [19:32] bryce: right I saw that, some them reference a bug number though and that one doesn't [19:32] yeah, next to look in upstream's git log [19:32] I always put in bug id's but not everyone does [19:35] aha [19:35] commit cc4eb1c7ea1bace7ed69cfd80c99d22933282ae1 [19:35] Author: Keith Packard [19:35] Date: Fri Apr 13 15:04:29 2007 -0300 [19:35] Add quirk for Acer AL1706 monitor to force 60hz refresh. [19:35] [19:35] This Acer monitor reports support for 75hz refresh via EDID, and yet when [19:35] that rate is delivered, the monitor does not sync and reports out of range. [19:35] Use the existing 60hz quirk for this monitor. [19:35] (cherry picked from commit 1328a288e9030a472a915077160f090d1afd4126) [19:37] bdmurray: I don't think keithp works to a bug tracker - he just knows when X is bad or good [19:39] bdmurray: is this giving you the info you're looking for? [19:40] that quirk appears to have been in the codebase since before hardy [19:40] bryce: yeah, I think so. People could also use http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=tree to check for quirk info right? [19:41] yes [19:41] the one caveat is that there may be differences between that and what we actually ship in ubuntu [19:41] I always grab the current source, then cd into it, run './debian/rules patch', and then look at the file [19:41] that accounts for any quirk patches we are carrying [19:43] bdmurray: oh also monitor quirk bugs like 273543 can be filed against xorg-server rather than xorg [19:43] bryce: cool, I'm trying to work through the regression- tagged X bugs [19:44] ah cool [19:45] I'm making another pass through the -ati bugs today [19:46] If you see any bugs tagged unnecessarily as regressions feel free to remove the tag [19:46] ok [20:18] tjaalton: bug 260589 might have the information you need now [20:18] Launchpad bug 260589 in xkeyboard-config "combining diacritics replaced by deadkeys" [Unknown,Confirmed] https://launchpad.net/bugs/260589 [20:21] hi [20:21] do you think it is safe to backport xcb from intrepid to hardy? [20:24] Sonne: probably; why do you ask? [20:24] because i want to use awesome3, and it requires newer xcb than the ones in hardy [20:25] i know xcb are part of xorg's "internals", but i don't know xorg infrastructure so much to be able to determine the risk of such an action :) [20:27] well i'll try, let's hope i don't break anything :) [20:29] aw... i just found out that even intrepid's xcb are not new enough.. [20:29] i fear i will have to git [20:29] good luck [20:29] any better ideas than git'ing lastest xcb-util, copying debian/, incrementing changelog and debuilding? [20:29] :P [20:30] that ought to work [20:30] you may need to rebuild libx11 as well [20:30] oh, there's no need to git, xcb 0.3.0 are out already as release [20:30] hrm [20:31] why's that? [20:31] xcb replaces some of libx11's internals. [20:31] but I don't know how it's all glued together internally [20:32] i know less than you, so wish me luck.. [20:32] Sonne: xcb-util and libxcb aren't the same thing.. [20:32] well they pertain to the same source package [20:33] no [20:33] http://packages.ubuntu.com/intrepid/libxcb-event0 <-- so it says here... [20:33] source is xcb-util [20:34] Sonne: jcristau's right. libxcb-event != libxcb [20:34] nice [20:34] xcb-util is a wrapper atop libxcb [20:34] hrm [20:35] maybe you'll need to upgrade both? [20:35] the package i'm trying to compile says it doesn't find xcb-{event,aux,atom,keysyms,icccm} and cairo-xcb [20:35] what should i do then? [20:35] except for the cairo thing, all seem to pertain to xcb-util [20:36] so xcb-util and libxcb seem to be separate projects.. maybe i don't need to backport both [20:38] could be [20:38] could you pastebin the full error log? [20:38] you mean cmake's? [20:39] yeah [20:39] http://rafb.net/p/mMY4AQ88.html [20:39] actually it's no longer reproducible, i've tried luck and installed the backported xcb-util [20:40] now it's only complaining about cairo-xcb, i still have to figure out what the hell it's about [20:40] stating to google, only people that got to compile this thing made it on archlinux [20:41] yeah there's probably also an xcb-enabled cairo package that it's looking for or something [20:41] not in ubuntu; maybe available from the cairo website [20:41] maybe ubuntu's cairo already silently integrates xcb patch... [20:42] i'll take a look to debian/patches [20:43] nah, nothing [20:43] let's take a look at cairo's website [20:43] cairo in sid has the xcb backend enabled, at least [20:44] i'd guess intrepid also has that [20:44] hrm [20:44] xcb support is included in upstream cairo [20:44] but it's disabled via ./configure in debian/rules [20:45] so, a little 'enable' instead of 'disable' and a debuild should do the trick [20:45] aha [20:45] not sure what old cairo package you're looking at then.. [20:45] hardy's [20:46] cairo-1.6.0 [20:46] should i backport that too from intrepid? [20:46] probably not [20:46] guess it's risky [20:47] or maybe not [20:47] on hardy's sources, xcb support is marked as "experimental" [20:47] maybe it's not on intrepid's [20:47] oh, on intrepid is still marked as experimental & unsupported, but it's enabled by default [20:48] there must be a reason i guess [20:48] well, intrepid's cairo requires too many libs from intrepid, i'll stick with 1.6 [20:49] the reason it's enabled in the cairo package now is that awesome 3 needed it [20:49] but awesome3 isn't in intrepid either [20:49] right [20:50] is it being worked on? [20:51] but, ubuntu packages come from debian... [20:51] most of them anyway [20:51] on launchpad there's just a bug report suggesting to use debian/experimental's [20:51] and people exchanging their opinions [20:51] no traces of "serious" work at first sight [20:54] meh, now i need libev, which require debhelper >=7... [20:55] i'm starting to no longer see the end of this [20:59] oh my, it compiles! [20:59] * Sonne cheers [20:59] no, it doesn't [21:08] haha, now it does! [21:08] thanks jcristau and bryce :) [21:30] bryce: bug 260341 seems really interesting [21:30] Launchpad bug 260341 in xserver-xorg-video-intel "[945G] wrong LCD resolution detected" [Undecided,Confirmed] https://launchpad.net/bugs/260341