[14:15] bryce: san jose has caltrain, not BART :) [14:50] public transport seems pretty cheap there, but caltrain is surprisingly slow [14:51] ~2h from the hotel to the airport, but only $7.25 [16:16] tjaalton: so you are comming? [16:17] hm, so I read reports that compiz does hang on a i945 for intrepid [16:17] anyone here with more information? [16:18] mvo: yes [16:26] no idea about the i945 issue [16:27] tjaalton: is there someone familiar with intel I could talk to? do we have a contact at intel? I mean, blacklisting i830,845,945 does not leave that many cards that we don't blacklist [16:29] bryce: ^--- ? [16:29] mvo: bryce knows better, but I think he's been talking to jbarnes at least [17:42] hi guys [17:42] Anyone about who knows about the evdev vs. joysticks problem? [17:43] o/ [17:43] https://help.ubuntu.com/community/Joystick_lshal_outputs suggests it is fixed with xserver-xorg-input-evdev 1:2.0.99+git20080912-0ubuntu6 [17:43] Not fixed for me, and 3Dconnextion space-navigator device [17:44] according to changelog for the evdev driver, it was only an Amd64 big which was fixed [17:45] yes [17:45] evdev should refuse to use them [17:45] so it's still picked for you? [17:51] pcjc2: ^^ [17:58] heya [17:58] (on holiday today) [17:59] howdy [17:59] tjaalton: ah, that's too bad, I thought bart went down that far [17:59] not yet anyway, depends on how the ballot went :) [18:00] too bad mvo's not online [18:00] they are planning to extend it 16mi to san jose (the eastern route) [18:05] tjaalton: if you can link up with enough other attendees, you can probably get a shuttle or taxi at a decent rate (and that will get you there faster) [18:05] hi, sorry, got distracted in the lab [18:05] tjaalton: Yes, lshal shows evdev being picked for the space navigator [18:05] want the output posting somewhere... pastebin? [18:06] lshal picking evdev is ok, i think [18:06] pcjc2: logfile should show if it's actually being used [18:06] logfile does indeed show it being used [18:07] (II) 3Dconnexion SpaceNavigator: Configuring as mouse [18:07] (II) XINPUT: Adding extended input device "3Dconnexion SpaceNavigator" (type: MO [18:07] USE) [18:07] bryce: well I think that I'll just go straight to downtown for a couple of hours before getting to the airport, that should minimize waiting times on stations :) [18:09] ah, good idea [18:11] Seems that evdev's "is it a mouse" heuristic is being broken by the SpaceNavigator reporting as having mouse buttons [18:11] (as well as axis) [18:11] well, maybe the buttons are within the permitted zone [18:14] duh, I've forgotten the command to show the keyid's of an input device? [18:14] I have a driver I wrote / copy-pasted for it [18:14] and it is finding those buttons as BTN_0 from the kernel's /dev/input/ [18:15] s/ten// [18:15] ten? [18:15] ok, s/forgotten/forgot/ :) [18:16] I'm tired or somthing.. [18:16] ah... was looking for a number - brain didn't register the word forgotten [18:16] heh [18:16] ok, so its coming under the BTN_MISC rangeC [18:17] s/C// [18:17] But are there any devices which _are_ mice, which have no buttons under the BTN_MOUSE range? [18:18] If not, that suggests a patch to the evdev driver to only register something as a mouse if it has axes, and (some) buttons which are > BTN_MOUSE [18:18] hm, dunno [18:18] s/>/>=/ [18:18] you should probably ask whot on #xorg-devel, although it's rather early down under [18:18] My Hardy workaround, was to ensure I never installed the evdev driver, but going forward it would be nice to fix this properly [18:19] xorg developers are in Oz? [18:19] x input developers are [18:19] ok [18:19] yes, whot and daniels both are :) [18:19] I'll knock up a patch which seems "right" here, and post that and an explanation on xorg-devel [18:19] (email) [18:20] but, you'll probably break something else if you change that check.. [18:20] No doubt... but as a local workaround, and a discussion point, it makes a good start [18:20] yup [18:20] It would be nice to have this device handled properly by XINPUT generally [18:21] I ended up writing a driver for the /dev/input/... device directly, rather than using XINPUT, due to various confusion about the way it represents its axis maxing it a bit screwey to use with xinput-joystic [18:21] k [18:22] its reporting relative axis, which IIRC, the joystic driver integrates [18:22] where you really just want the raw-numbers (perhaps scaled) back for a 6DOF controller navigating a 3D application [18:23] it makes no sense that the XINPUT system tries to return coordinates in X device space [18:24] doesn't XI give you the raw coordinates? [18:27] it has been a while since i played with the device.. [18:28] there are about "n" different ways you can interface withit [18:28] the proprioraty drivers open the USB device directly. You can use linux's input device support, X11... [18:29] its not picking up the right number of axis at the moment - I'd guess because evdev has grabbed it, and thinks it is a mouse [18:32] pcjc2: have you filed a bug on launchpad about this? [18:39] not yet, just figured I'd come and ask if this was supposed to be fixed along with the joystick issues which came up relating to evdev [18:39] ah crap... [18:39] Xinput is now a microsoft directX "name" as well [18:45] Any idea what the easiest way to black-list the device is... so that evdev doesn't even try to use it? [18:45] My application (and the "official" propriotary drivers) expect to own the device [18:45] an fdi file to unset the input.x11_driver key for that device [18:46] Like in the comment here: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-October/005956.html ? [18:47] yeah [18:48] pcjc2: people are reporting similar issues on bug 274203, so I'd like to redirect them to the new bug [18:48] Launchpad bug 274203 in xserver-xorg-input-evdev "Joystick detected as mouse, crashes X" [Undecided,Fix released] https://launchpad.net/bugs/274203 [18:50] i didn't know people made proprietary drivers for joysticks.. [18:51] this is a Ndof controller. The proprieraty driver communicates with the application with X messags [18:52] and their UI allows you to tune the 3D navigation preferences on a per-application basis. It is also their way of locking down using restrictive licensing... so I can buy a piece of hardware with no license to use the drivers for commercially related work [18:52] On the plus side, the "Personal edition" is much cheaper, and with an OSS driver, no different to the expensive version ;) [18:53] heh [18:55] didn't take too long for someone to clone the driver interface either... http://spacenav.sourceforge.net/ [19:16] http://www.collegehumor.com/video:1886349 [19:18] that would be funny if my XP desktop were _slower_ than my Intrepid install on this laptop... [19:26] actually, it lots better since apt-get remove tracker* jockey* and landscape* [19:27] I was upset to see how much disk IO was spent checking for propriatory drivers I don't have on the system [19:27] yeah, they are such resource hogs ;) [19:27] landscape is some kind of remote admin? [19:27] it's canonical's attempt to make money on support contracts aiui [19:28] thought as much, hence apt-get remove [19:28] also, the gdm prefetch list was pointing to some bad links [19:28] those readahead / prefetch files bitrot damned fast! [19:30] the landscape client has no daemon, so it's harmless to have, unless you hate the stats when logging in from the console/ssh :) [19:32] landscape-sysin took about 11 seconds blocking on disk-io if I'm interperting this bootchart correctly [19:32] ah [19:33] My laptop has a slow-spinning HDD, so I suffer from IO intensive boot processes [19:33] For that matter... can't we have a "cron" type replacement start with the desktop, so the computer doesn't immediately check for apt updates every time I login? [19:34] (It can wait a few seconds!) [20:09] bryce, has there been any thought put forth in deciding whether to do SRU's or backports for newer nvidia drivers in the same release series? [20:10] eg if NV were to do an updated 177 driver that fixed bugs [22:21] duh, pcjc2 left.. http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=64554e4799a697d37dfd8be480f8eee636b9bea1 [23:22] superm1: it's something that there's been discussion about from time to time [23:22] esp. around when we were thinking of doing an sru for -fglrx [23:23] in general the release team is very uncomfortable doing sru's for binaries and would prefer avoiding it [23:23] however, in the case where we would be going from a 100% non-functional binary driver, to a functional one, the case would be pretty evident [23:24] in cases where the driver works for some people already, then the case to do an sru is harder to make [23:25] with backports, the release team would be fine with that [23:26] the trouble is aiui, the backport team is fairly manpower limited [23:26] however that may be less of an issue in the case of binary drivers since they come precompiled ;-) [23:27] and of course there's also envyng for solving the need [23:33] bryce, okay well i expect a bug fix nvidia release very soon that is supposed to fix suspend regressions, so you'll see when it shows up i suppose