=== ashams_ is now known as ashams [15:40] hi there! can someone help me put x server allowing TCP connections please? [15:41] tried the security/DisallowTCP=false, rebooted and netstat -an | grep -F 6000 just brings nothing [17:21] heya, i'm looking at bug 666509 and found that bug 721453 is similar but names another possibly missing package. looking at pkg-config's rdepends id be unsurprised to find it missing on a default kubuntu install, but can anyone nvidia-knowledgeable confirm that it is indeed needed by nvidia-settings? i dont think nvidia-specific stuff will be happy in a vm to test it with... [17:21] Launchpad bug 666509 in nvidia-settings (Ubuntu) "kubuntu - needs python-gtk2 in order to save to /etc/X11/xorg.con (affects: 2) (dups: 1) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/666509 [17:21] Launchpad bug 721453 in nvidia-settings (Ubuntu) "nvidia-settings should depend on pkg-config and python-gtk (affects: 1)" [Undecided,New] https://launchpad.net/bugs/721453 [17:27] nevermind. code inspection wins. === soreau__ is now known as soreau === yofel_ is now known as yofel [21:28] cnd: Do you have any ETA for multitouch-on-1.11 landing? If it's a ways away I might try my hand at refreshing the existing patches for 1.11 so we can push 1.11 to precise nice and early. [21:28] RAOF, it'll be at least a month I think [21:28] due to the design sprint and uds [21:29] RAOF, it would be awesome if you could forward port the patches from oneiric [21:29] but fair warning: [21:29] the input side has changed some (function consolidation type changes) [21:29] and the code changes for multitouch are very hairy [21:29] so if you do venture in, bring your hat and whip [21:30] no telling what you find in there :) [21:30] it's also ok to upload without the multitouch patches for now [21:30] so don't let that gate your development for precise [21:31] Doesn't unity fail to load when gestures aren't available? [21:32] RAOF, there was a bug with that, but it was unity failing to verify that geis initialized properly [21:32] so the fix for that is just to make unity not be dumb :) [21:32] however, that has nothing to do with multitouch :) [21:32] not yet at least [21:33] when you forward port the patches, do forward port the gesture extension [21:34] Right. [21:34] if unity simply needs a check on geis, maybe that'd be the easiest/safest way to go? [21:34] Geis still looks for that? [21:34] RAOF, yeah, geis currently only looks for the gesture extension [21:34] we will be starting the geis backend for using the new multitouch-based architecture shortly [21:35] bryceh, that's the easiest way to get things working for now [21:35] and not having any gestures right now is ok [21:35] so if time is really an issue, feel free to just comment out all of our patches for the X server :) [21:38] I'd kinda like to have an existing implementation to compare against when the new multitouch lands. [21:39] But if that turns out to be annoyingly difficult I'll drop it like a stone :) [21:39] RAOF, ok [21:39] and I'm happy to answer any questions you have [21:40] RAOF, if you are interested in helping out beyond just getting it to work, you could really help by porting it to match the upstream protocol at the same time [21:40] there's two major changes, implementation wise, and a bunch of minor changes [21:40] like renames [21:42] but that could easily be more work than you have time for :) [22:22] weird; Ubuntu-X's subscription to xserver-xorg-video-ati seems to have been dropped in the past week or two [22:48] RAOF, bryceh: DBO says he'll fix the unity-geis bug [22:49] I asked him if he could since he wrote the code and would probably be faster at fixing it [22:49] Woot! [23:04] cnd, great to hear [23:08] RAOF, got a thumbs-up from keith on our libxrandr-utils plan [23:10] Also woot! [23:11] I guess we'll do some design at UDS? [23:13] good idea [23:14] I'm unsure if we want to schedule a session for it; this type of project's something that'd pull in a huge peanut gallery which could be a distraction [23:15] but might be hard to set aside a time otherwise [23:24] bryceh, RAOF, what's this libxrandr-utils plan? [23:24] * cnd is curious due to potential overlap with touchscreen to display mapping [23:24] Yeah, it might well overlap. [23:25] The idea is to factor out the RANDR-specific stuff from gnome-desktop and xrandr (and also from kde) into a helper library. [23:25] ok [23:25] What do you need for touchscreen to display mapping? This'd be done in a client app? [23:26] I mean, and X client would be responsible for setting up that mapping, right? [23:26] yes, though I would hope at some point we should be able to determine what the mapping should be at startup too [23:27] I don't have any fully-fleshed ideas [23:27] but I would like to be part of any discussion that could make touchscreen mapping easier (or at least make it non-existent :) [23:27] Determining the mapping at startup suggests that you'd want policy in the server, right? [23:27] oops, s/non-existent/existent/ [23:28] RAOF, I dunno if it's policy per se [23:28] policy suggest you use heuristics to determine the best choice [23:28] we really just need a way to say "this touchscreen is physically attached to this display" [23:28] and the only policy is that by default, a touchscreen should be mapped to its attached display [23:29] right now, all touchscreens (if you actually have multiple of them on one machine) are mapped across the entire screen [23:29] by default [23:30] Yeah. Which is obviously suboptimal. [23:30] the first step should be to figure out how to determine what is attached to what [23:30] but the second step would be to allow configuration of the mapping in a nice utility [23:31] the current xinput coordinate transformation approach uses pixels as offsets when you need to translate the input in the screen [23:31] so any xrandr changes need to propagate to the coordinate transformation [23:31] or something like that [23:32] so I think there's potential for overlap in the utils, and also in the xrandr change propagation [23:32] so if you're going to have a discussion somewhere, physical or virtual, please count me in [23:33] Ah, right. I see. [23:34] You'd need either (a) an in-server hook between xinput and xrandr, or (b) a settings-daemon plugin that listens for xrandr events and does the appropriate changes. [23:34] yeah [23:35] (b) is probably better [23:35] Right. [23:35] I'm not a big fan of the server messing with properties of my input device [23:35] even if it probably does know better [23:35] And for that, you need some way to easily *identify* which display is which, and that's totally in-scope for (my idea of) xrandr-utils :) [23:36] sounds in-scope in my idea of libxrandr-utils as well [23:40] It looks like we *might* want a UDS session for this after all :) [23:40] heh [23:42] RAOF, maybe; I still worry we would get too many people and wouldn't get much actual design work done. Maybe a multimonitor configuration session in addition to the design session? [23:43] Possibly we want a xrandr-utils requirements-gathering session and a private design session; I don't think that code design is well-suited to UDS fishbowls, but we should know what we're designing *for* :) [23:43] bryceh, I worry about turning people away who would like to at least watch any designing [23:44] cnd, why? [23:44] could we make it clear that it's specifically for designing and only for those who really understand or just want to watch? [23:44] it just feels un-uds [23:44] (says the tech lead in product strategy...) [23:45] I'm just throwing that out as an option [23:45] I understand the interest in keeping it more private :) [23:45] cnd, we've tried that with other xorg things in the past, but haven't hit on the right signal to send; they always seem to end up overpopulated [23:46] hmm [23:46] it seems like something we should keep trying though [23:46] I think we could happily sit in a room with the microphones on and IRC. [23:46] with canonical and ubuntu being more at the forefront of design and implementation [23:46] than we have been in the past [23:47] But I don't think low-level API design really benefits from more than a couple of people being audiable at a time. [23:47] I agree that it doesn't fit in with the current uds session setup though [23:48] I think irc would be a waste of time, because it would be too hard to get things done if you included people on irc [23:48] normally I wouldn't argue the point of having visibility and soliciting input and feedback, but we've had multimonitor uds discussions pretty much every uds the past few years [23:48] heh [23:48] is this really the multimonitor that people are interested in though? [23:48] I seriously don't think we are going to tap a lot more value there, we pretty much know all the issues and what people expect and so on [23:49] yeah, it's not about tapping more value per se [23:49] I would hope someone interested would be able to just drop in and learn more, I guess is the value I would like to see [23:50] in a non-participating way [23:50] but it may just be a pipe dream :) [23:51] it's hard for me to get enthused about people who aren't going to be participating ;-) [23:51] This would be a significantly different session to our previous multi-monitor ones though, right? This would be low-level, API & code design, rather than "what behaviour would we like to have". [23:51] I'm sure whatever we do it's going to be posted to phoronix and sliced / diced / criticized to the nth degree regardless [23:52] RAOF, right [23:53] It's probably worth publishing the results & justifications of that design discussion; publishing the live stream of us talking about it wouldn't be terrible :) [23:53] one other thing I want to avoid is building up expectations sky high, like seems to always happen (wayland, etc.) [23:54] true [23:55] I'm fine with this being private, I just wish we had a way to make a design session work as well as other ubuntu sessions do [23:55] some of them at least :) [23:56] I think this is a different case, really. [23:57] And calls for a different type of transparency. [23:57] yeah, it is [23:58] The set of people who will actually be users of this code is small. [23:58] and fwiw it's not that it needs to be done private, there's nothing secret, just that we want to discuss it more closely than can be done in a room full of people [23:59] So as to avoid a camel :) [23:59] exactly