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