[08:20] <tjaalton> bryce: I'll start uploading the input properties stuff now, starting from inputproto
[08:25] <bryce> heya tjaalton.  sounds good
[08:45] <tjaalton> hum? lp doesn't show builds other than i386 anymore?
[08:46] <tjaalton> need to wait for the proto to get in the archive first, then libxi and xserver after that
[08:58] <crevette> hello
[12:59] <tjaalton> hey
[17:46] <kees> bryce: say, can include/misc.h have MAXCLIENTS raised?
[17:46] <kees> bryce: maybe to 1024 from the current 256?
[17:47] <kees> (a friend with like 20 work spaces and lots of RAM just ran into it, and it doesn't seem to be run-time configurable)
[17:56] <pwnguin> how much extra ram will that allocate?
[18:09] <kees> pwnguin: that I don't know.
[18:10] <kees> I've opened bug 260138 for it, with upstream bug links, and proposed patches.  (they're untested, though)
[18:10] <pwnguin> i have to ask
[18:10] <pwnguin> why does nabble know so much about mailing lists?
[18:23] <pwnguin> kees: so uh. the stuff im reading says you'll need more than a simple header change?
[18:24] <pwnguin> (if you've tested the patches, that's at least a good sign)
[18:26] <kees> pwnguin: nope, I haven't tested anything -- just prepared patches based on the discussion.
[18:27] <kees> pwnguin: I have no idea what the impact would be, but I figured since I could do the other legwork, I could contribute that bit.
[18:27] <kees> honestly, if someone who know this area says "wtf? no way" that's fine too.  :)
[18:28] <pwnguin> so that bit operation macro you wrote. it operates on ints?
[18:29] <pwnguin> s/wrote/extended/
[19:04] <tjaalton> at least rhel4 has those patches
[19:04] <tjaalton> 20:52 < ajax> you trade more clients for fewer resources per client
[19:11] <bdmurray> bryce: bug 219952's recent comments don't look like an -video-ati bug right?
[19:14] <tjaalton> bdmurray: it might still be the driver. the original issue seems resolved though (no picture with livecd)
[19:15] <bdmurray> tjaalton: it's before X starts though right?
[19:16] <tjaalton> bdmurray: ah, right.. that's the kernel/usplash doing something funny
[19:16] <tjaalton> so this bug is fixed
[19:16] <bdmurray> and they should open a new bug with those screenshots?
[19:17] <tjaalton> I'd say so, yes
[19:28] <bryce> yep
[19:36] <tjaalton> bryce: I've pushed the IDP patches for xorg-server in git, and it should be ready to go. Anything to add?
[19:37] <tjaalton> after that, driver support (evdev, synaptics) and a new xinput (and/or gui support) :)
[19:43] <tjaalton> bryce: also, the "evdev keyboard model" mess is not over yet. Since it broke jp106 & ABNT2, svu and daniels thought that it would be best to force the evdev _rules_, not model, and to allow changing the model like before, and no need to force it in gnome-settings-daemon either
[19:44] <bryce> hrm
[19:44] <pwnguin> so what's the point of no return on this
[19:44] <tjaalton> the evdev rules just need to add support for jp106 & ABNT2 (and whatnot)
[19:44] <tjaalton> this is already in upstream. we just need to make sure no-one notices anything when they upgrade. it shouldn't be too hard
[19:45] <tjaalton> pwnguin: what do you mean?
[19:45] <pwnguin> i recall someone important saying that no one feature was worth holding back the whole release, but i cant recall when a feature has been tried and rolled back
[19:45] <pwnguin> i can recall a few times where a feature was pushed in and left there
[19:45] <tjaalton> we can't avoid evdev
[19:45] <tjaalton> forever..
[19:45] <jcristau> it's like the future or something
[19:46] <tjaalton> yeah, or something
[19:46] <pwnguin> im just wondering if there is such a mechanism in place
[19:47] <pwnguin> recall pulse audio troubles in hardy =/
[19:47] <tjaalton> pwnguin: it should not hold back anything.. the next alpha is due in two weeks so there's plenty of time to upload :)
[19:47] <tjaalton> well, pulse..
[19:48] <pwnguin> in the mean time, HAL is on its way out for devicekit...
[19:48] <tjaalton> looks like it'll get sorted out finally
[19:48] <tjaalton> the pulse mess that is
[19:49] <pwnguin> i get the impression that pulse would have gone faster if it had been called "audioKit"
[19:49] <pwnguin> for some reason the *Kits have a level of inevitability
[19:49] <tjaalton> apart from the jp106 & ABNT2 brokenness, the input-hotplug change has been quite smooth
[20:14] <bryce> yup
[20:15] <bryce> although, it's not solved as many issues as I'd hoped... quite clearly input X drivers for uncommon devices don't get as much attention as they need
[20:27] <pwnguin> thats why i worry about this devicekit thing
[20:28] <pwnguin> it seems like every few years everyone runs away from the complexity of properly handling the broken hardware of the world
[21:01] <tjaalton> bryce: what devices do you have in mind?
[21:08] <bryce> tjaalton: game controllers, tablets, etc.
[21:09] <jcristau> why wouldn't game controllers work with evdev?
[21:09] <pwnguin> depends on your definition of game controller
[21:09] <pwnguin> as for why it might not work, have you tried any jcristau?
[21:10] <jcristau> no
[21:10] <pwnguin> well, you're not alone
[21:10]  * jcristau <- not a gamer
[21:11] <pwnguin> heh
[21:11] <pwnguin> gamers dont use joypads on PC
[21:11] <pwnguin> they're so pedestrian
[21:12] <pwnguin> plus, there's so many of them, with different numbers of buttons and sticks and layouts
[21:14] <pwnguin> so we wind up with a few games in Ubuntu that are Designed for Xbox 360
[21:49] <bryce> it's not so much they don't work, just that there's some manual configuration needed that we could probably do a lot more cleanly
[21:50] <bryce> also there's some driver issues, like certain buttons not working, or features not working in the same modes, etc.  little stuff
[22:05] <tjaalton> hmm, my rumblepad doesn't seem to like evdev, or the other way around
[22:05] <tjaalton> (WW) Logitech Logitech RumblePad 2 USB: Don't know how to use device
[22:05] <tjaalton> but usually it's just that the fdi-files need to know about the devices (like the apple trackpads)
[22:08] <tjaalton> evdev should have the same features as mouse has, plus properties
[22:09] <tjaalton> and non-serial tablets should work OOTB
[22:09] <tjaalton> by now
[22:10] <tjaalton> evdev only has two bugs, of which one is likely fixed and the other one is asking for the moon
[22:14] <tjaalton> maybe I'll debug joysticks tomorrow then ;)
[22:22] <pwnguin> tjaalton: so protocol IV stuff is serial -- i should be making fdi rules for that?
[22:23] <tjaalton> pwnguin: serial devices can't be autodetected AIUI
[22:23] <tjaalton> you need some input from them first
[22:23] <pwnguin> heh
[22:23] <pwnguin> theres another trick
[22:23] <pwnguin> dont detect the serial
[22:23] <pwnguin> detect the laptop that should have one
[22:23] <tjaalton> that should work
[22:23] <tjaalton> could
[22:24] <pwnguin> unfortunately, the laptop team is dead
[22:28] <tjaalton> so revive it?-)
[22:28] <pwnguin> well, i kinda have
[22:29] <pwnguin> the toshiba tablet team!
[22:29] <tjaalton> btw, just matching the laptop model doesn't work. you need to match the device
[22:30] <tjaalton> and then tell it to load the driver for that device
[22:30] <pwnguin> "device"
[22:30] <tjaalton> you can't say "oh, this is toshiba FOO, load wacom" and expect it to work :)
[22:30] <tjaalton> see the output of lshal
[22:31] <tjaalton> your mouse probably has several devices
[22:32] <tjaalton> of which only one is the device that the driver can handle
[22:32] <tjaalton> the one that has info.capabilities ~= input.mouse
[22:32] <pwnguin> lshal's pretty damn long
[22:33] <pwnguin> heh
[22:33] <pwnguin> udi = '/org/freedesktop/Hal/devices/pnp_WACf004' info.capabilities = {'input', 'input.tablet', 'input.tablet.tabletPC'} (string list)
[22:33] <pwnguin> those ones
[22:33] <tjaalton> there you go
[22:33] <tjaalton> is that a serial device?
[22:33] <pwnguin> yes
[22:34] <tjaalton> sweet
[22:34] <pwnguin> two of em
[22:34] <pwnguin> err
[22:34] <tjaalton> so the wacom fdi should match the info.product of it
[22:35] <pwnguin> tjaalton: the launchpad team "Toshiba Tablet Team" should have an email you can reach random wacom tester/motu/devs at
[22:36] <tjaalton> ok
[22:48] <bdmurray> bryce: about bug 163044 if I can't recreate that is not an indication it is fixed right?
[22:49] <bryce> bdmurray: generally if you were able to reproduce the bug in some fashion, and then with current code the problem does not occur, then that's considered a verification of a fix
[22:49] <bryce> however, if you're never able to reproduce the problem, and it just works, that's not sufficient to confirm it as fixed.
[22:49] <bdmurray> bryce: okay, but I never saw the bug originally so won't comment
[22:49] <bryce> if you have identical hardware to the reporter, then *maybe* that can be considered fixed, but it'd still be good to ask the original reporter to confirm.
[22:50] <pwnguin> tjaalton: where is this wacom.fdi?
[23:17] <pwnguin> tjaalton: so I can see this wacom rules mentioned in the changelog and in the source package, but it's not in the binary...
[23:24] <pwnguin> anyone wanna confirm what i think is wrong with this patch?
[23:24] <pwnguin> +	mkdir -p debian/$(package_xorg)/usr/share/hal/fdi/policy/20thirdparty/
[23:24] <pwnguin> +	dh_install debian/10-wacom.fdi usr/share/hal/fdi/policy/20thirdparty/
[23:25] <pwnguin> +err
[23:25] <pwnguin> <-- fails