=== ashams_ is now known as ashams
nmpribeirohi there! can someone help me put x server allowing TCP connections please?15:40
nmpribeirotried the security/DisallowTCP=false, rebooted and netstat -an | grep -F 6000 just brings nothing15:41
macoheya, 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
ubot4Launchpad 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/66650917:21
ubot4Launchpad bug 721453 in nvidia-settings (Ubuntu) "nvidia-settings should depend on pkg-config and python-gtk (affects: 1)" [Undecided,New] https://launchpad.net/bugs/72145317:21
maconevermind. code inspection wins.17:27
=== soreau__ is now known as soreau
=== yofel_ is now known as yofel
RAOFcnd: 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
cndRAOF, it'll be at least a month I think21:28
cnddue to the design sprint and uds21:28
cndRAOF, it would be awesome if you could forward port the patches from oneiric21:29
cndbut fair warning:21:29
cndthe input side has changed some (function consolidation type changes)21:29
cndand the code changes for multitouch are very hairy21:29
cndso if you do venture in, bring your hat and whip21:29
cndno telling what you find in there :)21:30
cndit's also ok to upload without the multitouch patches for now21:30
cndso don't let that gate your development for precise21:30
RAOFDoesn't unity fail to load when gestures aren't available?21:31
cndRAOF, there was a bug with that, but it was unity failing to verify that geis initialized properly21:32
cndso the fix for that is just to make unity not be dumb :)21:32
cndhowever, that has nothing to do with multitouch :)21:32
cndnot yet at least21:32
cndwhen you forward port the patches, do forward port the gesture extension21:33
brycehif unity simply needs a check on geis, maybe that'd be the easiest/safest way to go?21:34
RAOFGeis still looks for that?21:34
cndRAOF, yeah, geis currently only looks for the gesture extension21:34
cndwe will be starting the geis backend for using the new multitouch-based architecture shortly21:34
cndbryceh, that's the easiest way to get things working for now21:35
cndand not having any gestures right now is ok21:35
cndso if time is really an issue, feel free to just comment out all of our patches for the X server :)21:35
RAOFI'd kinda like to have an existing implementation to compare against when the new multitouch lands.21:38
RAOFBut if that turns out to be annoyingly difficult I'll drop it like a stone :)21:39
cndRAOF, ok21:39
cndand I'm happy to answer any questions you have21:39
cndRAOF, 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 time21:40
cndthere's two major changes, implementation wise, and a bunch of minor changes21:40
cndlike renames21:40
cndbut that could easily be more work than you have time for :)21:42
brycehweird; Ubuntu-X's subscription to xserver-xorg-video-ati seems to have been dropped in the past week or two22:22
cndRAOF, bryceh: DBO says he'll fix the unity-geis bug22:48
cndI asked him if he could since he wrote the code and would probably be faster at fixing it22:49
brycehcnd, great to hear23:04
brycehRAOF, got a thumbs-up from keith on our libxrandr-utils plan23:08
RAOFAlso woot!23:10
RAOFI guess we'll do some design at UDS?23:11
brycehgood idea23:13
brycehI'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 distraction23:14
brycehbut might be hard to set aside a time otherwise23:15
cndbryceh, RAOF, what's this libxrandr-utils plan?23:24
* cnd is curious due to potential overlap with touchscreen to display mapping23:24
RAOFYeah, it might well overlap.23:24
RAOFThe idea is to factor out the RANDR-specific stuff from gnome-desktop and xrandr (and also from kde) into a helper library.23:25
RAOFWhat do you need for touchscreen to display mapping?  This'd be done in a client app?23:25
RAOFI mean, and X client would be responsible for setting up that mapping, right?23:26
cndyes, though I would hope at some point we should be able to determine what the mapping should be at startup too23:26
cndI don't have any fully-fleshed ideas23:27
cndbut I would like to be part of any discussion that could make touchscreen mapping easier (or at least make it non-existent :)23:27
RAOFDetermining the mapping at startup suggests that you'd want policy in the server, right?23:27
cndoops, s/non-existent/existent/23:27
cndRAOF, I dunno if it's policy per se23:28
cndpolicy suggest you use heuristics to determine the best choice23:28
cndwe really just need a way to say "this touchscreen is physically attached to this display"23:28
cndand the only policy is that by default, a touchscreen should be mapped to its attached display23:28
cndright now, all touchscreens (if you actually have multiple of them on one machine) are mapped across the entire screen23:29
cndby default23:29
RAOFYeah.  Which is obviously suboptimal.23:30
cndthe first step should be to figure out how to determine what is attached to what23:30
cndbut the second step would be to allow configuration of the mapping in a nice utility23:30
cndthe current xinput coordinate transformation approach uses pixels as offsets when you need to translate the input in the screen23:31
cndso any xrandr changes need to propagate to the coordinate transformation23:31
cndor something like that23:31
cndso I think there's potential for overlap in the utils, and also in the xrandr change propagation23:32
cndso if you're going to have a discussion somewhere, physical or virtual, please count me in23:32
RAOFAh, right.  I see.23:33
RAOFYou'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(b) is probably better23:35
cndI'm not a big fan of the server messing with properties of my input device23:35
cndeven if it probably does know better23:35
RAOFAnd 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:35
brycehsounds in-scope in my idea of libxrandr-utils as well23:36
RAOFIt looks like we *might* want a UDS session for this after all :)23:40
brycehRAOF, 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:42
RAOFPossibly 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
cndbryceh, I worry about turning people away who would like to at least watch any designing23:43
brycehcnd, why?23:44
cndcould we make it clear that it's specifically for designing and only for those who really understand or just want to watch?23:44
cndit just feels un-uds23:44
cnd(says the tech lead in product strategy...)23:44
cndI'm just throwing that out as an option23:45
cndI understand the interest in keeping it more private :)23:45
brycehcnd, 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 overpopulated23:45
cndit seems like something we should keep trying though23:46
RAOFI think we could happily sit in a room with the microphones on and IRC.23:46
cndwith canonical and ubuntu being more at the forefront of design and implementation23:46
cndthan we have been in the past23:46
RAOFBut I don't think low-level API design really benefits from more than a couple of people being audiable at a time.23:47
cndI agree that it doesn't fit in with the current uds session setup though23:47
cndI think irc would be a waste of time, because it would be too hard to get things done if you included people on irc23:48
brycehnormally 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 years23:48
cndis this really the multimonitor that people are interested in though?23:48
brycehI 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 on23:48
cndyeah, it's not about tapping more value per se23:49
cndI would hope someone interested would be able to just drop in and learn more, I guess is the value I would like to see23:49
cndin a non-participating way23:50
cndbut it may just be a pipe dream :)23:50
brycehit's hard for me to get enthused about people who aren't going to be participating ;-)23:51
RAOFThis 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
brycehI'm sure whatever we do it's going to be posted to phoronix and sliced / diced / criticized to the nth degree regardless23:51
brycehRAOF, right23:52
RAOFIt'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
brycehone other thing I want to avoid is building up expectations sky high, like seems to always happen (wayland, etc.)23:53
cndI'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 do23:55
cndsome of them at least :)23:55
RAOFI think this is a different case, really.23:56
RAOFAnd calls for a different type of transparency.23:57
cndyeah, it is23:57
RAOFThe set of people who will actually be users of this code is small.23:58
brycehand 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 people23:58
RAOFSo as to avoid a camel :)23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!