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