[10:37] <persia> I've been looking at joysticks in intrepid.  While it's nice that they don't crash X anymore, it seems X still has an exclusive lock on them, so they don't work with any games.
[10:37] <persia> In order to blacklist them, would it be better to blacklist from HAL, or from X?
[10:39] <persia> I think X is hard because HAL seems to claim they are pointers, but seek confirmation before trying to change HAL.
[10:43] <tjaalton> locked by the evdev driver you mean?
[10:44] <persia> tjaalton, I believe so.
[10:44] <persia> At least not accessible to user programs attempting to access the deivce.
[10:45] <tjaalton> so -joystick would be better?
[10:45] <persia> No, that only exposes joystick events within X.  All the games are coded against /dev/input/js*
[10:45] <tjaalton> that should be easy to fix by adding the needed information to the joystick fdi file
[10:45] <persia> That doesn't help at all, until all the games are ported.
[10:45] <jcristau> or patch X and evdev to stop grabbing the device
[10:46] <tjaalton> ah..
[10:46] <tjaalton> now I finally see the problem :)
[10:46] <jcristau> persia: x-x-i-joystick grabs the devices as well?
[10:46] <persia> I like the idea of X being able to use a joystick as a pointer device, but I don't think we can port all the games for intrepid (or probably, jaunty).
[10:46] <persia> I'd like installing -joystick to be able to make X input with a joystick work, and uninstalling make the games work.
[10:47] <persia> That seems the least painful compromise until the games can be ported (changing libSDL will probably get 50% of them).
[10:47] <persia> jcristau, Yes, or at least limited testing with jstest and jsdemo indicates this.
[10:48] <persia> The annoying thing is that from what I can tell from lshal output, hal claims they are pointing devices (which is true).
[10:48] <tjaalton> right
[10:48] <tjaalton> that's why evdev steals them
[10:48] <persia> Right.
[10:49] <persia> So where I'm not sure is whether HAL should just not show them, or whether HAL should send an additional property that evdev uses as a negative selector.
[10:49] <jcristau> i guess it's a bit too late to stop the device grabbing for intrepid.. you'd have to deal with the duplicated events from xorg.conf devices
[10:49] <persia> Ideally, I'd like to have the solution either be a hack that can be reverted easily, or a path that works going forward, and will be the standard.
[10:50] <persia> jcristau, The problem is that I'm not getting duplicate events.  I'm getting no events.
[10:50] <persia> Duplicate events is probably acceptable.  The only use case I know it breaks is playing FPS with a mouse and joystick.
[10:50] <jcristau> i'm talking about what happens if evdev stops grabbing devices
[10:51] <jcristau> and you have mouse/kbd sections in xorg.conf
[10:52] <persia> RIght.  evdev stopping grabbing devices unilaterally is probably more of a headache.  Something that could detect that the item was a joystick would be better.
[10:52] <persia> I know this information is available from the kernel, as lsinput can tell if something is a keyboard, a mouse, or a joystick.
[10:53] <jcristau> info.capabilities in lshal contains joystick?
[10:55] <jcristau> input.joystick even
[10:56] <persia> No, it doesn't.  I could probably make it do so.
[10:56] <persia> (although someone else could probably do this faster)
[10:59] <tjaalton> pitti could know what needs to be done
[11:04] <persia> So, if input.joystick was exported, could they be blacklisted within X unless xserver-xorg-input-joystick was installed?
[11:04] <jcristau> not really. but they could be ignored by evdev.
[11:04] <persia> (where presumably xserver-xorg-input-joystick would then be able to use that as a filter when accessing devices, making the related .fdi file easier to write)
[11:04] <persia> Ignored by evdev is probably good enough at this stage for intrepid.
[11:05] <persia> To whom could I ship joysticks to help create a better solution for jaunty?
[11:10] <tjaalton> if input.joystick was exported, the fdi file in -joystick would be a lot saner than now (whitelisting models, blech)
[11:10] <persia> OK.  I'll go hack that up then.
[11:11] <tjaalton> oh you wrote that already, I'm slow :)
[11:11] <persia> tjaalton, Well, the difference between what I write and what you write is that the latter is more likely to be correct :)
[11:12] <tjaalton> ignored by evdev is probably the correct path anyway
[11:12] <persia> Great.  Now to figure out how inpututils does it.
[11:13] <tjaalton> persia: hmm, perhaps, although in this case they were essentially the same :)
[11:14] <tjaalton> persia: do ask pitti, he might know the answer already
[11:15] <persia> tjaalton, I probably will, but I generally find it's a good idea to read a little code before talking to pitti, or I may not understand the response.
[11:15] <tjaalton> persia: heh, could be
[11:20] <wgrant> persia: How does lsinput say that it knows it's a joystick?
[11:21] <persia> wgrant, Well, I thought it did.  Seems I may be mistaken
[11:21] <persia> Last time I was seriously trying to make joysticks work was feisty : since then we've been pretty stable.
[11:22] <wgrant> It would be nice if the kernel could tell us.
[11:22] <wgrant> Hmm.
[11:22] <wgrant> The kernel does know.
[11:22] <persia> Indeed.
[11:22] <wgrant> It gives me a /dev/input/js0
[11:23] <wgrant> apt-get source linux it is.
[11:23] <wgrant> Or udev, hmmm.
[11:23] <wgrant> No, Linux.
[11:25] <persia> Yeah.  It looks more and more like a kernel thing.  udev seems to lump joysticks and mice, and find them both with the same match rule.
[11:26] <wgrant> udev checks the name that the kernel gives it.
[11:28] <persia> Hrm.  Actually, there is a way to collect it from an API.  input-kbd and jstest get different information on the lists of available buttons.
[12:05] <davmor2> Morning guys.  I did and update to intrepid this morning all went except that nvidia -177 set my hz to 60 rather than 75 which made the desktop blurry and the bottom bar disappear off the screen.
[15:24] <mvo> tjaalton: bugs.freedesktop.org is the right bts for the screensaver patch at http://paste.ubuntu.com/60050/ ?
[15:24] <tjaalton> mvo: yes
[15:40] <persia> Hey.  So I finally got my i386 machine installed, and can confirm that the same hardware that doesn't work on amd64 works fine on i386.
[15:40] <tjaalton> persia: the joysticks?
[15:41] <persia> The HAL input looks similar, except for the lack of x11_driver on i386.  Would this be something in evdev then?
[15:41] <persia> Yep, the joysticks.
[15:41] <persia> (and no, I don't think telling all amd64 users to generate .fdi files is a good solution)
[15:42] <tjaalton> hehe
[15:43] <tjaalton> what do you get in the log with x86?
[15:43] <tjaalton> when you plug in the joystick?
[15:43] <tjaalton> oh, and what do you mean by working fine?
[15:43] <tjaalton> evdev _doesn't_ grab the device?
[15:44] <tjaalton> since that's essentially what happens to me, it refuses to use them
[15:44] <jcristau> he says there's no x11_driver
[15:44] <tjaalton> hrm, should read
[15:44] <jcristau> which points to hal or kernel
[15:44] <jcristau> afaict
[15:44] <tjaalton> yeah
[15:45] <persia> jcristau, So HAL is giving different output for i386 and amd64?  I thought input.x11_driver would be set by X.
[15:46] <tjaalton> persia: no, it's the hal fdi-files that do it
[15:46] <tjaalton> 10-x11-input.fdi
[15:48] <persia> Now I'm extra confused, as lshal shows input.mouse in info.capabilities, which is what 10-x11-input.fdi is matching.
[15:48] <tjaalton> this is a fresh install?
[15:49] <tjaalton> so nothing in /etc/hal/fdi/policy
[15:49] <persia> Yep.  Within the hour.
[15:49] <persia> There's a preferences.fdi file
[15:50] <tjaalton> that's normal
[15:50] <tjaalton> try restarting hal?
[15:51] <persia> restarting with the joystick attached?
[15:51] <tjaalton> shouldn't matter
[15:55] <tjaalton> bryce: the patch for bug 261977.. I gave it some thought. The fallback should be used _only_ if the .ids-files are used, since if the user doesn't have an xorg.conf, the first driver will then be vesa :)
[15:55] <tjaalton> good ubottu
[15:55] <tjaalton> mvo: gotta run now, but I'll apply the patch later today
[15:56] <mvo> thanks tjaalton
[15:56] <tjaalton> mvo: and upstream tomorrow when I get my fd.o account ;)
[15:56] <mvo> tjaalton: ha! excellent
[15:56] <persia> Nope.  Restarted HAL.  restarted X.  On i386, the joystick persists in showing info.capabilities including input.mouse, the HAL fdi file matches on input.mouse, and it doesn't work to control my pointer.  Same joystick on amd64 is grabbed by evdev.
[15:56] <mvo> tjaalton: you get commit access? congrats :-D
[15:56] <mvo> tjaalton: that is truely excellent news 
[15:56] <tjaalton> mvo: well, ajax said I'd need one.. why not. bryce should too :)
[15:57] <tjaalton> persia: duh, can't think of what's wrong then :/
[15:58] <tjaalton> anyway, got to go now for a while ->
[15:58] <persia> tjaalton, OK.  Is this maybe a bug on i386 that it works when it shouldn't?
[15:58] <tjaalton> persia: it's something bizarre that I haven't seen yet ;)
[15:58] <persia> OK.  Anyone else have any suggestions?
[15:58] <jcristau> persia: if you have input.mouse but no x11_driver, that sounds like a hal bug, yes
[15:59] <persia> jcristau, OK.  I'll go bug pitti again.  Sounds like it's a bug that I want replicated to amd64 as well :)
[19:00] <mvo> bryce: it looks like the gnome-control-center upload you did is not in bzr, did you forget to bzr push maybe?