[15:40] <nmpribeiro> hi there! can someone help me put x server allowing TCP connections please?
[15:41] <nmpribeiro> tried the security/DisallowTCP=false, rebooted and netstat -an | grep -F 6000 just brings nothing
[17:21] <maco> 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] <ubot4> 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] <ubot4> 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] <maco> nevermind. code inspection wins.
[21:28] <RAOF> 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] <cnd> RAOF, it'll be at least a month I think
[21:28] <cnd> due to the design sprint and uds
[21:29] <cnd> RAOF, it would be awesome if you could forward port the patches from oneiric
[21:29] <cnd> but fair warning:
[21:29] <cnd> the input side has changed some (function consolidation type changes)
[21:29] <cnd> and the code changes for multitouch are very hairy
[21:29] <cnd> so if you do venture in, bring your hat and whip
[21:30] <cnd> no telling what you find in there :)
[21:30] <cnd> it's also ok to upload without the multitouch patches for now
[21:30] <cnd> so don't let that gate your development for precise
[21:31] <RAOF> Doesn't unity fail to load when gestures aren't available?
[21:32] <cnd> RAOF, there was a bug with that, but it was unity failing to verify that geis initialized properly
[21:32] <cnd> so the fix for that is just to make unity not be dumb :)
[21:32] <cnd> however, that has nothing to do with multitouch :)
[21:32] <cnd> not yet at least
[21:33] <cnd> when you forward port the patches, do forward port the gesture extension
[21:34] <RAOF> Right.
[21:34] <bryceh> if unity simply needs a check on geis, maybe that'd be the easiest/safest way to go?
[21:34] <RAOF> Geis still looks for that?
[21:34] <cnd> RAOF, yeah, geis currently only looks for the gesture extension
[21:34] <cnd> we will be starting the geis backend for using the new multitouch-based architecture shortly
[21:35] <cnd> bryceh, that's the easiest way to get things working for now
[21:35] <cnd> and not having any gestures right now is ok
[21:35] <cnd> so if time is really an issue, feel free to just comment out all of our patches for the X server :)
[21:38] <RAOF> I'd kinda like to have an existing implementation to compare against when the new multitouch lands.
[21:39] <RAOF> But if that turns out to be annoyingly difficult I'll drop it like a stone :)
[21:39] <cnd> RAOF, ok
[21:39] <cnd> and I'm happy to answer any questions you have
[21:40] <cnd> 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] <cnd> there's two major changes, implementation wise, and a bunch of minor changes
[21:40] <cnd> like renames
[21:42] <cnd> but that could easily be more work than you have time for :)
[22:22] <bryceh> weird; Ubuntu-X's subscription to xserver-xorg-video-ati seems to have been dropped in the past week or two
[22:48] <cnd> RAOF, bryceh: DBO says he'll fix the unity-geis bug
[22:49] <cnd> I asked him if he could since he wrote the code and would probably be faster at fixing it
[22:49] <RAOF> Woot!
[23:04] <bryceh> cnd, great to hear
[23:08] <bryceh> RAOF, got a thumbs-up from keith on our libxrandr-utils plan
[23:10] <RAOF> Also woot!
[23:11] <RAOF> I guess we'll do some design at UDS?
[23:13] <bryceh> good idea
[23:14] <bryceh> 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] <bryceh> but might be hard to set aside a time otherwise
[23:24] <cnd> bryceh, RAOF, what's this libxrandr-utils plan?
[23:24]  * cnd is curious due to potential overlap with touchscreen to display mapping
[23:24] <RAOF> Yeah, it might well overlap.
[23:25] <RAOF> 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] <cnd> ok
[23:25] <RAOF> What do you need for touchscreen to display mapping?  This'd be done in a client app?
[23:26] <RAOF> I mean, and X client would be responsible for setting up that mapping, right?
[23:26] <cnd> yes, though I would hope at some point we should be able to determine what the mapping should be at startup too
[23:27] <cnd> I don't have any fully-fleshed ideas
[23:27] <cnd> 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] <RAOF> Determining the mapping at startup suggests that you'd want policy in the server, right?
[23:27] <cnd> oops, s/non-existent/existent/
[23:28] <cnd> RAOF, I dunno if it's policy per se
[23:28] <cnd> policy suggest you use heuristics to determine the best choice
[23:28] <cnd> we really just need a way to say "this touchscreen is physically attached to this display"
[23:28] <cnd> and the only policy is that by default, a touchscreen should be mapped to its attached display
[23:29] <cnd> right now, all touchscreens (if you actually have multiple of them on one machine) are mapped across the entire screen
[23:29] <cnd> by default
[23:30] <RAOF> Yeah.  Which is obviously suboptimal.
[23:30] <cnd> the first step should be to figure out how to determine what is attached to what
[23:30] <cnd> but the second step would be to allow configuration of the mapping in a nice utility
[23:31] <cnd> the current xinput coordinate transformation approach uses pixels as offsets when you need to translate the input in the screen
[23:31] <cnd> so any xrandr changes need to propagate to the coordinate transformation
[23:31] <cnd> or something like that
[23:32] <cnd> so I think there's potential for overlap in the utils, and also in the xrandr change propagation
[23:32] <cnd> so if you're going to have a discussion somewhere, physical or virtual, please count me in
[23:33] <RAOF> Ah, right.  I see.
[23:34] <RAOF> 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] <cnd> yeah
[23:35] <cnd> (b) is probably better
[23:35] <RAOF> Right.
[23:35] <cnd> I'm not a big fan of the server messing with properties of my input device
[23:35] <cnd> even if it probably does know better
[23:35] <RAOF> 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] <bryceh> sounds in-scope in my idea of libxrandr-utils as well
[23:40] <RAOF> It looks like we *might* want a UDS session for this after all :)
[23:40] <cnd> heh
[23:42] <bryceh> 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] <RAOF> 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] <cnd> bryceh, I worry about turning people away who would like to at least watch any designing
[23:44] <bryceh> cnd, why?
[23:44] <cnd> 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] <cnd> it just feels un-uds
[23:44] <cnd> (says the tech lead in product strategy...)
[23:45] <cnd> I'm just throwing that out as an option
[23:45] <cnd> I understand the interest in keeping it more private :)
[23:45] <bryceh> 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] <cnd> hmm
[23:46] <cnd> it seems like something we should keep trying though
[23:46] <RAOF> I think we could happily sit in a room with the microphones on and IRC.
[23:46] <cnd> with canonical and ubuntu being more at the forefront of design and implementation
[23:46] <cnd> than we have been in the past
[23:47] <RAOF> 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] <cnd> I agree that it doesn't fit in with the current uds session setup though
[23:48] <cnd> 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] <bryceh> 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] <cnd> heh
[23:48] <cnd> is this really the multimonitor that people are interested in though?
[23:48] <bryceh> 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] <cnd> yeah, it's not about tapping more value per se
[23:49] <cnd> 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] <cnd> in a non-participating way
[23:50] <cnd> but it may just be a pipe dream :)
[23:51] <bryceh> it's hard for me to get enthused about people who aren't going to be participating ;-)
[23:51] <RAOF> 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] <bryceh> 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] <bryceh> RAOF, right
[23:53] <RAOF> 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] <bryceh> one other thing I want to avoid is building up expectations sky high, like seems to always happen (wayland, etc.)
[23:54] <cnd> true
[23:55] <cnd> 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] <cnd> some of them at least :)
[23:56] <RAOF> I think this is a different case, really.
[23:57] <RAOF> And calls for a different type of transparency.
[23:57] <cnd> yeah, it is
[23:58] <RAOF> The set of people who will actually be users of this code is small.
[23:58] <bryceh> 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] <RAOF> So as to avoid a camel :)
[23:59] <bryceh> exactly