[14:15] <tjaalton> bryce: san jose has caltrain, not BART :)
[14:50] <tjaalton> public transport seems pretty cheap there, but caltrain is surprisingly slow
[14:51] <tjaalton> ~2h from the hotel to the airport, but only $7.25
[16:16] <mvo> tjaalton: so you are comming?
[16:17] <mvo> hm, so I read reports that compiz does hang on a i945 for intrepid
[16:17] <mvo> anyone here with more information?
[16:18] <tjaalton> mvo: yes
[16:26] <tjaalton> no idea about the i945 issue
[16:27] <mvo> 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] <mvo> bryce: ^--- ?
[16:29] <tjaalton> mvo: bryce knows better, but I think he's been talking to jbarnes at least
[17:42] <pcjc2> hi guys
[17:42] <pcjc2> Anyone about who knows about the evdev vs. joysticks problem?
[17:43] <tjaalton> o/
[17:43] <pcjc2> 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] <pcjc2> Not fixed for me, and 3Dconnextion space-navigator device
[17:44] <pcjc2> according to changelog for the evdev driver, it was only an Amd64 big which was fixed
[17:45] <tjaalton> yes
[17:45] <tjaalton> evdev should refuse to use them
[17:45] <tjaalton> so it's still picked for you?
[17:51] <tjaalton> pcjc2: ^^
[17:58] <bryce> heya
[17:58] <bryce> (on holiday today)
[17:59] <tjaalton> howdy
[17:59] <bryce> tjaalton: ah, that's too bad, I thought bart went down that far
[17:59] <tjaalton> not yet anyway, depends on how the ballot went :)
[18:00] <bryce> too bad mvo's not online
[18:00] <tjaalton> they are planning to extend it 16mi to san jose (the eastern route)
[18:05] <bryce> 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] <pcjc2> hi, sorry, got distracted in the lab
[18:05] <pcjc2> tjaalton: Yes, lshal shows evdev being picked for the space navigator
[18:05] <pcjc2> want the output posting somewhere... pastebin?
[18:06] <jcristau> lshal picking evdev is ok, i think
[18:06] <tjaalton> pcjc2: logfile should show if it's actually being used
[18:06] <pcjc2> logfile does indeed show it being used
[18:07] <pcjc2> (II) 3Dconnexion SpaceNavigator: Configuring as mouse
[18:07] <pcjc2> (II) XINPUT: Adding extended input device "3Dconnexion SpaceNavigator" (type: MO
[18:07] <pcjc2> USE)
[18:07] <tjaalton> 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] <bryce> ah, good idea
[18:11] <pcjc2> Seems that evdev's "is it a mouse" heuristic is being broken by the SpaceNavigator reporting as having mouse buttons
[18:11] <pcjc2> (as well as axis)
[18:11] <tjaalton> well, maybe the buttons are within the permitted zone
[18:14] <tjaalton> duh, I've forgotten the command to show the keyid's of an input device?
[18:14] <pcjc2> I have a driver I wrote / copy-pasted for it
[18:14] <pcjc2> and it is finding those buttons as BTN_0 from the kernel's /dev/input/
[18:15] <tjaalton> s/ten//
[18:15] <pcjc2> ten?
[18:15] <tjaalton> ok, s/forgotten/forgot/ :)
[18:16] <tjaalton> I'm tired or somthing..
[18:16] <pcjc2> ah... was looking for a number - brain didn't register the word forgotten
[18:16] <tjaalton> heh
[18:16] <pcjc2> ok, so its coming under the BTN_MISC rangeC
[18:17] <pcjc2> s/C//
[18:17] <pcjc2> But are there any devices which _are_ mice, which have no buttons under the BTN_MOUSE range?
[18:18] <pcjc2> 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] <tjaalton> hm, dunno
[18:18] <pcjc2> s/>/>=/
[18:18] <tjaalton> you should probably ask whot on #xorg-devel, although it's rather early down under
[18:18] <pcjc2> 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] <pcjc2> xorg developers are in Oz?
[18:19] <jcristau> x input developers are
[18:19] <pcjc2> ok
[18:19] <tjaalton> yes, whot and daniels both are :)
[18:19] <pcjc2> I'll knock up a patch which seems "right" here, and post that and an explanation on xorg-devel
[18:19] <pcjc2> (email)
[18:20] <jcristau> but, you'll probably break something else if you change that check..
[18:20] <pcjc2> No doubt... but as a local workaround, and a discussion point, it makes a good start
[18:20] <jcristau> yup
[18:20] <pcjc2> It would be nice to have this device handled properly by XINPUT generally
[18:21] <pcjc2> 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] <pcjc2> k
[18:22] <pcjc2> its reporting relative axis, which IIRC, the joystic driver integrates
[18:22] <pcjc2> where you really just want the raw-numbers (perhaps scaled) back for a 6DOF controller navigating a 3D application
[18:23] <pcjc2> it makes no sense that the XINPUT system tries to return coordinates in X device space
[18:24] <jcristau> doesn't XI give you the raw coordinates?
[18:27] <pcjc2> it has been a while since i played with the device..
[18:28] <pcjc2> there are about "n" different ways you can interface withit
[18:28] <pcjc2> the proprioraty drivers open the USB device directly. You can use linux's input device support, X11...
[18:29] <pcjc2> 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] <tjaalton> pcjc2: have you filed a bug on launchpad about this?
[18:39] <pcjc2>  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] <pcjc2> ah crap...
[18:39] <pcjc2> Xinput is now a microsoft directX "name" as well
[18:45] <pcjc2> Any idea what the easiest way to black-list the device is... so that evdev doesn't even try to use it?
[18:45] <pcjc2> My application (and the "official" propriotary drivers) expect to own the device
[18:45] <jcristau> an fdi file to unset the input.x11_driver key for that device
[18:46] <pcjc2> Like in the comment here: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-October/005956.html ?
[18:47] <jcristau> yeah
[18:48] <tjaalton> pcjc2: people are reporting similar issues on bug 274203, so I'd like to redirect them to the new bug
[18:50] <jcristau> i didn't know people made proprietary drivers for joysticks..
[18:51] <pcjc2> this is a Ndof controller. The proprieraty driver communicates with the application with X messags
[18:52] <pcjc2> 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] <pcjc2> On the plus side, the "Personal edition" is much cheaper, and with an OSS driver, no different to the expensive version ;)
[18:53] <jcristau> heh
[18:55] <pcjc2> didn't take too long for someone to clone the driver interface either... http://spacenav.sourceforge.net/
[19:16] <bryce> http://www.collegehumor.com/video:1886349
[19:18] <pcjc2> that would be funny if my XP desktop were _slower_ than my Intrepid install on this laptop...
[19:26] <pcjc2> actually, it lots better since apt-get remove tracker* jockey* and landscape*
[19:27] <pcjc2> I was upset to see how much disk IO was spent checking for propriatory drivers I don't have on the system
[19:27] <tjaalton> yeah, they are such resource hogs ;)
[19:27] <pcjc2> landscape is some kind of remote admin?
[19:27] <jcristau> it's canonical's attempt to make money on support contracts aiui
[19:28] <pcjc2> thought as much, hence apt-get remove 
[19:28] <pcjc2> also, the gdm prefetch list was pointing to some bad links
[19:28] <pcjc2> those readahead / prefetch files bitrot damned fast!
[19:30] <tjaalton> 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] <pcjc2> landscape-sysin took about 11 seconds blocking on disk-io if I'm interperting this bootchart correctly
[19:32] <tjaalton> ah
[19:33] <pcjc2> My laptop has a slow-spinning HDD, so I suffer from IO intensive boot processes
[19:33] <pcjc2> 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] <pcjc2> (It can wait a few seconds!)
[20:09] <superm1> 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] <superm1> eg if NV were to do an updated 177 driver that fixed bugs
[22:21] <tjaalton> duh, pcjc2 left.. http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=64554e4799a697d37dfd8be480f8eee636b9bea1
[23:22] <bryce> superm1: it's something that there's been discussion about from time to time
[23:22] <bryce> esp. around when we were thinking of doing an sru for -fglrx
[23:23] <bryce> in general the release team is very uncomfortable doing sru's for binaries and would prefer avoiding it
[23:23] <bryce> 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] <bryce> in cases where the driver works for some people already, then the case to do an sru is harder to make
[23:25] <bryce> with backports, the release team would be fine with that
[23:26] <bryce> the trouble is aiui, the backport team is fairly manpower limited
[23:26] <bryce> however that may be less of an issue in the case of binary drivers since they come precompiled ;-)
[23:27] <bryce> and of course there's also envyng for solving the need
[23:33] <superm1> 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