[08:20] bryce: I'll start uploading the input properties stuff now, starting from inputproto [08:25] heya tjaalton. sounds good [08:45] hum? lp doesn't show builds other than i386 anymore? [08:46] need to wait for the proto to get in the archive first, then libxi and xserver after that [08:58] hello [12:59] hey === mvo_ is now known as mvo [17:46] bryce: say, can include/misc.h have MAXCLIENTS raised? [17:46] bryce: maybe to 1024 from the current 256? [17:47] (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] how much extra ram will that allocate? [18:09] pwnguin: that I don't know. [18:10] I've opened bug 260138 for it, with upstream bug links, and proposed patches. (they're untested, though) [18:10] Launchpad bug 260138 in xorg-server "Xorg needs client limit raised" [Undecided,New] https://launchpad.net/bugs/260138 [18:10] i have to ask [18:10] why does nabble know so much about mailing lists? [18:23] kees: so uh. the stuff im reading says you'll need more than a simple header change? [18:24] (if you've tested the patches, that's at least a good sign) [18:26] pwnguin: nope, I haven't tested anything -- just prepared patches based on the discussion. [18:27] 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] honestly, if someone who know this area says "wtf? no way" that's fine too. :) [18:28] so that bit operation macro you wrote. it operates on ints? [18:29] s/wrote/extended/ [19:04] at least rhel4 has those patches [19:04] 20:52 < ajax> you trade more clients for fewer resources per client [19:11] bryce: bug 219952's recent comments don't look like an -video-ati bug right? [19:11] Launchpad bug 219952 in xserver-xorg-video-ati "ubuntu 8.04 RC don´t run in acer extensa 7620G - HD 2400 XT [1002:94c8] " [High,Incomplete] https://launchpad.net/bugs/219952 [19:14] bdmurray: it might still be the driver. the original issue seems resolved though (no picture with livecd) [19:15] tjaalton: it's before X starts though right? [19:16] bdmurray: ah, right.. that's the kernel/usplash doing something funny [19:16] so this bug is fixed [19:16] and they should open a new bug with those screenshots? [19:17] I'd say so, yes [19:28] yep [19:36] bryce: I've pushed the IDP patches for xorg-server in git, and it should be ready to go. Anything to add? [19:37] after that, driver support (evdev, synaptics) and a new xinput (and/or gui support) :) [19:43] 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] hrm [19:44] so what's the point of no return on this [19:44] the evdev rules just need to add support for jp106 & ABNT2 (and whatnot) [19:44] 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] pwnguin: what do you mean? [19:45] 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] i can recall a few times where a feature was pushed in and left there [19:45] we can't avoid evdev [19:45] forever.. [19:45] it's like the future or something [19:46] yeah, or something [19:46] im just wondering if there is such a mechanism in place [19:47] recall pulse audio troubles in hardy =/ [19:47] 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] well, pulse.. [19:48] in the mean time, HAL is on its way out for devicekit... [19:48] looks like it'll get sorted out finally [19:48] the pulse mess that is [19:49] i get the impression that pulse would have gone faster if it had been called "audioKit" [19:49] for some reason the *Kits have a level of inevitability [19:49] apart from the jp106 & ABNT2 brokenness, the input-hotplug change has been quite smooth [20:14] yup [20:15] 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] thats why i worry about this devicekit thing [20:28] it seems like every few years everyone runs away from the complexity of properly handling the broken hardware of the world === federico1 is now known as fooderico [21:01] bryce: what devices do you have in mind? [21:08] tjaalton: game controllers, tablets, etc. [21:09] why wouldn't game controllers work with evdev? [21:09] depends on your definition of game controller [21:09] as for why it might not work, have you tried any jcristau? [21:10] no [21:10] well, you're not alone [21:10] * jcristau <- not a gamer [21:11] heh [21:11] gamers dont use joypads on PC [21:11] they're so pedestrian [21:12] plus, there's so many of them, with different numbers of buttons and sticks and layouts [21:14] so we wind up with a few games in Ubuntu that are Designed for Xbox 360 [21:49] 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] also there's some driver issues, like certain buttons not working, or features not working in the same modes, etc. little stuff === fooderico is now known as federic1 === federic1 is now known as federico1 [22:05] hmm, my rumblepad doesn't seem to like evdev, or the other way around [22:05] (WW) Logitech Logitech RumblePad 2 USB: Don't know how to use device [22:05] but usually it's just that the fdi-files need to know about the devices (like the apple trackpads) [22:08] evdev should have the same features as mouse has, plus properties [22:09] and non-serial tablets should work OOTB [22:09] by now [22:10] evdev only has two bugs, of which one is likely fixed and the other one is asking for the moon [22:14] maybe I'll debug joysticks tomorrow then ;) [22:22] tjaalton: so protocol IV stuff is serial -- i should be making fdi rules for that? [22:23] pwnguin: serial devices can't be autodetected AIUI [22:23] you need some input from them first [22:23] heh [22:23] theres another trick [22:23] dont detect the serial [22:23] detect the laptop that should have one [22:23] that should work [22:23] could [22:24] unfortunately, the laptop team is dead [22:28] so revive it?-) [22:28] well, i kinda have [22:29] the toshiba tablet team! [22:29] btw, just matching the laptop model doesn't work. you need to match the device [22:30] and then tell it to load the driver for that device [22:30] "device" [22:30] you can't say "oh, this is toshiba FOO, load wacom" and expect it to work :) [22:30] see the output of lshal [22:31] your mouse probably has several devices [22:32] of which only one is the device that the driver can handle [22:32] the one that has info.capabilities ~= input.mouse [22:32] lshal's pretty damn long [22:33] heh [22:33] udi = '/org/freedesktop/Hal/devices/pnp_WACf004' info.capabilities = {'input', 'input.tablet', 'input.tablet.tabletPC'} (string list) [22:33] those ones [22:33] there you go [22:33] is that a serial device? [22:33] yes [22:34] sweet [22:34] two of em [22:34] err [22:34] so the wacom fdi should match the info.product of it [22:35] tjaalton: the launchpad team "Toshiba Tablet Team" should have an email you can reach random wacom tester/motu/devs at [22:36] ok [22:48] bryce: about bug 163044 if I can't recreate that is not an indication it is fixed right? [22:48] Launchpad bug 163044 in xserver-xorg-driver-ati "[M6] terminal display error when reading PDF files" [Unknown,Confirmed] https://launchpad.net/bugs/163044 [22:49] 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] 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] bryce: okay, but I never saw the bug originally so won't comment [22:49] 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] tjaalton: where is this wacom.fdi? [23:17] 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] anyone wanna confirm what i think is wrong with this patch? [23:24] + mkdir -p debian/$(package_xorg)/usr/share/hal/fdi/policy/20thirdparty/ [23:24] + dh_install debian/10-wacom.fdi usr/share/hal/fdi/policy/20thirdparty/ [23:25] +err [23:25] <-- fails