bryce | tjaalton: heya, what remains to be done before 1.6.0 can be uploaded? | 03:17 |
---|---|---|
tjaalton | bryce: new libdrm I guess | 04:42 |
tjaalton | hmm no | 05:35 |
tjaalton | it was intel that needed it | 05:35 |
tjaalton | "Experience with the kernel portions of KMS (kernel mode switching) " :) | 06:01 |
tjaalton | from the employment page | 06:04 |
crevette | good morning | 09:10 |
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:11 |
crevette | https://bugs.edge.launchpad.net/ubuntu/+source/bluez/+bug/328216 | 09:16 |
ubottu | Launchpad bug 328216 in bluez "Bluetooth keyboard not working in X in 9.04" [Undecided,New] | 09:16 |
=== seb128_ is now known as seb128 | ||
tjaalton | crevette: not much to say without Xorg.0.log | 09:48 |
crevette | tjaalton, just I wanted some pointer, does a bluetooth device is listed in xinput ? | 09:54 |
crevette | s/does/is/ | 09:55 |
crevette | and s/is// | 09:55 |
tjaalton | I don't know | 09:56 |
crevette | okay let ask the log first | 09:58 |
crevette | can I add xorg as inpacted package? | 09:58 |
tjaalton | not yet ;) | 09:58 |
crevette | I'm sure this is xork, blame xorg | 09:59 |
crevette | :) | 09:59 |
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: ^^ | 14:13 |
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:10 |
jcristau | there's no way to do that atm afaik | 16:11 |
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:15 |
jcristau | it'd probably be feasible to fix x to start at 800x600 (or 640x480) even if nothing's connected.. | 16:17 |
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 | 16:28 |
bryce | superm1, jcristau: I'd have no problem changing that, any ideas where this is being set? xserver? | 19:07 |
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:10 |
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:11 |
bryce | superm1: ok, not totally sure what would need implemented, but can you file a wishlist bug against xorg-server for this? | 19:12 |
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:15 |
crevette | superm1: and you're invited to report regression from 4.30 in https://bugs.edge.launchpad.net/bugs/337443 | 19:16 |
ubottu | Launchpad bug 337443 in bluez "[jaunty] Please update bluez to 4.32 version" [Undecided,New] | 19:16 |
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:17 |
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:18 |
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:19 |
superm1 | i think bluez upstream does releases too quickly imho | 19:20 |
crevette | "Release early, release often" | 19:20 |
crevette | :) | 19:20 |
crevette | it is hard to test all corner case for packagers | 19:21 |
crevette | cases | 19:21 |
jcristau | superm1: why would you fall back to vesa, as opposed to just making your driver set a default fallback mode? | 20:25 |
Alexia_Death | tjaalton: HAL people wont accept that upstream. | 20:50 |
Alexia_Death | tjaalton: so with that they will keep patching hal forever. | 20:50 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
Alexia_Death | whot? | 20:58 |
tjaalton | yes | 20:58 |
Alexia_Death | then it has pretty good chances of being good. | 20:58 |
Alexia_Death | doesnet solve it for serial devices tho. they need to be still loaded through dbus. | 20:59 |
tjaalton | fedora's wacom.fdi has some rule for serial devices | 21:02 |
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:21 |
jcristau | vesa would probably be easier, yes. i'm just not sure it's the right thing to do | 21:23 |
tormod | bryce: re bug 335214, how do we flag (bugs that need) cherry-picking upstream commits? | 22:59 |
ubottu | Launchpad bug 335214 in xorg-server "[RV570] devices could not be detected correctly" [Undecided,Confirmed] https://launchpad.net/bugs/335214 | 22:59 |
tormod | I think we previously had a list on the wiki, but w.u.c is broken now, so I can't check | 23:02 |
* 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:04 |
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:06 |
bryce | heh @329562. He could not find lspci-nnv so attached /usr/bin/lspci instead | 23:11 |
tormod | bryce, thanks | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!