[03:17] <bryce> tjaalton: heya, what remains to be done before 1.6.0 can be uploaded?
[04:42] <tjaalton> bryce: new libdrm I guess
[05:35] <tjaalton> hmm no
[05:35] <tjaalton> it was intel that needed it
[06:01] <tjaalton> "Experience with the kernel portions of KMS (kernel mode switching) " :)
[06:04] <tjaalton> from the employment page
[09:10] <crevette> good morning
[09:11] <crevette> does anyone has some knowledge about bluetooth input device in Xorg ?
[09:11] <crevette> a reporter said it's bluetooth HID working under VT but not with Xorg
[09:16] <crevette> https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/328216
[09:48] <tjaalton> crevette: not much to say without Xorg.0.log
[09:54] <crevette> tjaalton, just I wanted some pointer, does a bluetooth device is listed in xinput ?
[09:55] <crevette> s/does/is/
[09:55] <crevette> and s/is//
[09:56] <tjaalton> I don't know
[09:58] <crevette> okay let ask the log first
[09:58] <crevette> can I add xorg as inpacted package?
[09:58] <tjaalton> not yet ;)
[09:59] <crevette> I'm sure this is xork, blame xorg
[09:59] <crevette> :)
[14:13] <tjaalton> so, fedora now has a patch for wacom to init all devices
[14:13] <tjaalton> http://cvs.fedoraproject.org/viewvc/devel/linuxwacom/linuxwacom-0.8.2.2-HAL.patch?revision=1.1&view=markup
[14:13] <tjaalton> Alexia_Death: ^^
[16:10] <superm1> bryce, i was talking to cjwatson about a 60 second delay to wait for X to start (or fail to start for that matter) in ubiquity-dm (used for --automatic).  i've got a case where it's failing to start because a monitor might not be plugged in.  do you know of any way to tell it to start up anyway even if it's not finding a monitor and bailing?
[16:11] <jcristau> there's no way to do that atm afaik
[16:15] <superm1> hmm okay then, the alternative solution would to be dropping that delay in the amount of time to wait until declaring X failed to start. what's a safer number that's less than 60?
[16:15] <superm1> assuming you can be starting off of live media and what not which is slower
[16:17] <jcristau> it'd probably be feasible to fix x to start at 800x600 (or 640x480) even if nothing's connected..
[16:28] <superm1> maybe forcing vesa as a fallback then.  i'm not if vesa is enforcing this too
[16:28] <superm1> *sure
[16:28] <superm1> this was with the intel driver that I was seeing this behavior
[19:07] <bryce> superm1, jcristau: I'd have no problem changing that, any ideas where this is being set?  xserver?
[19:10] <superm1> bryce, i think something would need to  be added to the X server to fall back to vesa and try that if the current driver should work and tries to work, but for some reason bales
[19:11] <superm1> because from the server's perspective, i dont think there is a way you'll see this situation
[19:11] <crevette> hey superm1
[19:11] <superm1> hi crevette 
[19:11] <bryce> hmm
[19:12] <bryce> superm1: ok, not totally sure what would need implemented, but can you file a wishlist bug against xorg-server for this?
[19:15] <crevette> superm1: as you're not on #u-mobile, if you're interested with testing bluez 4.32 (https://edge.launchpad.net/~bmillemathias/+archive/ppa)
[19:16] <crevette> superm1: and you're invited to report regression from 4.30 in https://bugs.edge.launchpad.net/bugs/337443
[19:17] <superm1> bryce, sure.  i think i've got a rough idea of what needs doing, just don't know the codepath, so i'll try best to word it
[19:18] <superm1> crevette, looks like a bug fix release other than " Add support for new BtIO helper library."
[19:18] <bryce> ok thanks, that may help. 
[19:19] <superm1> if nothing is using that, i dont see why an FFe would be denied (unless of course there Are regressions ;))
[19:19] <crevette> superm1: yes, there were some crasher, especially in 4.31 which wasn't uploaded
[19:19] <superm1> ah okay
[19:19] <crevette> 4.31 was crashy
[19:20] <superm1> i think bluez upstream does releases too quickly imho
[19:20] <crevette> "Release early, release often"
[19:20] <crevette> :)
[19:21] <crevette> it is hard to test all corner case for packagers
[19:21] <crevette> cases
[20:25] <jcristau> superm1: why would you fall back to vesa, as opposed to just making your driver set a default fallback mode?
[20:50] <Alexia_Death> tjaalton: HAL people wont accept that upstream.
[20:50] <Alexia_Death> tjaalton: so with that they will keep patching hal forever.
[20:53] <tjaalton> Alexia_Death: umm, it's a patch for wacom
[20:53] <Alexia_Death> The kernel driver?
[20:53] <Alexia_Death> Ping said that was too much work to be done sensibly...
[20:54] <jcristau> tjaalton's link is a linuxwacom patch...
[20:54] <jcristau> so not hal, and not kernel.
[20:54] <Alexia_Death> Sorry, I dont have time to take a closer look...  then I assume its X driver and makes the driver insitalize the rest.
[20:54] <tjaalton> yes
[20:55] <Alexia_Death> There are tons of things that can go wrong... and how does it know what is pesent for a particular tablet?
[20:55] <Alexia_Death> and how to name the devices?
[20:56] <tjaalton> don't ask me :)
[20:56] <tjaalton> ask peter
[20:56] <Alexia_Death> oh well... I hope they manage to sell that to ping.
[20:57] <Alexia_Death> If its good that is.
[20:57] <tjaalton> there alread was a patch on the list that was supposed to do the same
[20:57] <tjaalton> but this one is by _the_ X input dude
[20:58] <Alexia_Death> whot?
[20:58] <tjaalton> yes
[20:58] <Alexia_Death> then it has pretty good chances of being good.
[20:59] <Alexia_Death> doesnet solve it for serial devices tho. they need to be still loaded through dbus.
[21:02] <tjaalton> fedora's wacom.fdi has some rule for serial devices
[21:21] <superm1> jcristau, there would have to be support added to that on a driver by driver basis then
[21:21] <superm1> jcristau, whereas VESA will just work on anything at low res (in  theory)
[21:23] <jcristau> vesa would probably be easier, yes.  i'm just not sure it's the right thing to do
[22:59] <tormod> bryce: re bug 335214, how do we flag (bugs that need) cherry-picking upstream commits?
[23:02] <tormod> I think we previously had a list on the wiki, but w.u.c is broken now, so I can't check
[23:04]  * bryce looks
[23:04] <bryce> yeah I used to do it in wiki, but nowadays it's easier to just snag the cherries as I see them
[23:06] <bryce> tormod, so I would be okay with assigning to me and either a) downloading the patch and attaching it to the bug report, or b) putting [patch] in the title.  Whichever is easier
[23:06] <bryce> assigning to me is optional of course, but it'll add them to my todo list
[23:11] <bryce> heh @329562.  He could not find lspci-nnv so attached /usr/bin/lspci instead
[23:30] <tormod> bryce, thanks