| === ashams_ is now known as ashams | ||
| nmpribeiro | hi there! can someone help me put x server allowing TCP connections please? | 15:40 |
|---|---|---|
| nmpribeiro | tried the security/DisallowTCP=false, rebooted and netstat -an | grep -F 6000 just brings nothing | 15:41 |
| 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:21 |
| maco | nevermind. code inspection wins. | 17:27 |
| === soreau__ is now known as soreau | ||
| === yofel_ is now known as yofel | ||
| 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:28 |
| 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:29 |
| 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:30 |
| RAOF | Doesn't unity fail to load when gestures aren't available? | 21:31 |
| 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:32 |
| cnd | when you forward port the patches, do forward port the gesture extension | 21:33 |
| 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:34 |
| 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:35 |
| RAOF | I'd kinda like to have an existing implementation to compare against when the new multitouch lands. | 21:38 |
| 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:39 |
| 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:40 |
| cnd | but that could easily be more work than you have time for :) | 21:42 |
| bryceh | weird; Ubuntu-X's subscription to xserver-xorg-video-ati seems to have been dropped in the past week or two | 22:22 |
| cnd | RAOF, bryceh: DBO says he'll fix the unity-geis bug | 22:48 |
| cnd | I asked him if he could since he wrote the code and would probably be faster at fixing it | 22:49 |
| RAOF | Woot! | 22:49 |
| bryceh | cnd, great to hear | 23:04 |
| bryceh | RAOF, got a thumbs-up from keith on our libxrandr-utils plan | 23:08 |
| RAOF | Also woot! | 23:10 |
| RAOF | I guess we'll do some design at UDS? | 23:11 |
| bryceh | good idea | 23:13 |
| 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:14 |
| bryceh | but might be hard to set aside a time otherwise | 23:15 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| RAOF | Ah, right. I see. | 23:33 |
| 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:34 |
| 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:35 |
| bryceh | sounds in-scope in my idea of libxrandr-utils as well | 23:36 |
| RAOF | It looks like we *might* want a UDS session for this after all :) | 23:40 |
| cnd | heh | 23:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| cnd | in a non-participating way | 23:50 |
| cnd | but it may just be a pipe dream :) | 23:50 |
| 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:51 |
| bryceh | RAOF, right | 23:52 |
| 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:53 |
| cnd | true | 23:54 |
| 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:55 |
| RAOF | I think this is a different case, really. | 23:56 |
| RAOF | And calls for a different type of transparency. | 23:57 |
| cnd | yeah, it is | 23:57 |
| 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:58 |
| RAOF | So as to avoid a camel :) | 23:59 |
| bryceh | exactly | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!