bschaeferRAOF, hey, so a few questions on the review for attestable cookie (also my test is failing now). Cant read the keyboard udev file any more or rather no events00:10
bschaeferRAOF, also, when it comes to a platform such as libinput/x11 how does that tie into mir server it self?00:10
bschaeferdoes it replace the android backend?00:10
RAOFYes, ish.00:11
RAOFBut not the bits you touched.00:11
bschaeferRAOF, so either way we still use the low level android stuff that talks to the kernel?00:12
RAOFNo, we replace the low level stuff.00:12
RAOFBut not the IPC stuff.00:12
bschaeferRAOF, trying to read anpok branch on libinput and how to add a configuration, but his branch only has platform changes00:12
bschaeferRAOF, hmm IPC?00:13
bschaeferinter process com?00:13
bschaeferadd an API so U-S-C can set things needed for a barrier (similar to how unity7 works with xinput2)00:14
bschaeferRAOF, also i dont think main is fixed yet for protobuf :(00:14
RAOFSo, we absolutely should not add an API to U-S-C providing barrier-like behaviour.00:15
bschaeferRAOF, i think its to add an API to umm set settings like00:15
bschaeferspeed of cursor00:15
bschaeferor some things that is needed to be set in libinput00:15
RAOFYeah, I think that's also incorrect to use USC for.00:15
RAOFWe *should* have Unity8 in charge of drawing the pointer.00:15
RAOF(Whether or not we need to, as a short-term hack, introduce such an API is left as an exercise for the reader)00:16
bschaeferRAOF, right hmm, was just under the impression that letting U-S-C render the cursor since greyback didnt want unity8 to draw the cursor00:16
RAOFgreyback is wrong. At least long-term.00:17
* bschaefer cant see long term very well atm00:17
bschaefermainly because im missing a lot of context00:17
bschaeferRAOF, so in the short team, this shouldnt be to hard ... my main issue is not even knowing how an API should be set up like this since the only thing00:18
bschaeferthe branch touches is things in src/platforms, meaning i would have to write a C API to touch the platform bits?00:18
bschaeferie. set the cursor device configurations?00:18
bschaeferunless U-S-C gets access to a separate C++ API im not aware of00:19
bschaeferbut either way, im not super familiar with exposing things from the platform --> client00:19
bschaeferRAOF, is it platform --> server --> client?00:20
bschaeferand back down? platform <--- server <--- client?00:20
RAOFYeah, platform → server → client.00:20
bschaeferalright, so mainly i just need to figure out how to send simple data down the RPC00:21
* bschaefer can never remeber the right letter order00:21
bschaeferRAOF, that'll at lease be a good start, the only thing im worried about is short term tends to be long term :(00:21
bschaeferRAOF, whats the ideal solution for this?00:22
RAOFThere are a number of plausible options.00:24
RAOFOne would be to pass the evdev fds down to the nested compositor and manage switching via EVIOCREVOKE.00:25
bschaeferthat way they can change the device settings them selfs?00:26
RAOFRight; then the nested compositor has a full input platform and can go to town.00:26
bschaeferthat would be a small impact in mir...and would require some work in U-S-C00:27
bschaeferbut i cant imagine it being crazy00:27
bschaeferRAOF, well small impact in the sense that i have no clue what it would require besides 1 function :)00:27
RAOFIt'd be mostly easy. It'd be easier if we didn't have to pretend that USC was a normal Mir server and U8 was a normal Mir client :)00:28
bschaeferhaha ... i suppose that complicates things...00:29
RAOFEh, it just makes things a little messy.00:29
bschaeferRAOF, i was mainly just going off what was talking about and the card00:29
bschaefererr what was talked*00:29
* bschaefer would rather do it the right way vs a hack that will be shoved into mir00:30
bschaeferthen it'll happen again and again and you're left with x11v2 :)00:30
bschaeferRAOF, ill try to talk about it tomorrow at the stand up to see any other ideas00:31
RAOFWe could also potentially expose various bits of currently-internal libinput handling.00:33
bschaeferRAOF, such as the device it self? So settings can be manually changed in U-S-C?00:33
* bschaefer has been reading through the libinput code00:34
bschaeferand it just seems to turn everything from a device into a mir event00:34
bschaefernow ... i dont even know what *settings/configuration* needs to changed/set yet :)00:34
RAOFSo the nested compositor (ie: unity8) can twiddle the behavioural tweaks itself.00:34
bschaeferbut from what i understand its mainly the cursor/pointer00:34
bschaeferright, that might be better then adding a full blown API like mir_platform_set_cursor_speed(int speed);00:35
bschaeferRAOF, that would make U-S-C explicit on the platform though right?00:35
RAOFThat's not a full-blown API :)00:35
* bschaefer haha... well thats kind of what i imagined i would attempt to add in the api (from what that card says)00:36
bschaeferthen figure out how to change libinput00:36
RAOFA full-blown API is something like mir_input_get_device_properties() mir_input_set_device_properties() :)00:36
bschaeferto what they want00:36
bschaeferRAOF, well... what if for now i just went through and figured out every function that would be needed00:36
RAOFFrom which you receive arbitrary blobs of data, and to which you push arbitrary blobs of data :)00:36
bschaeferthen just add function support for that?00:36
bschaeferwould make it easier to remove i suppose00:36
* RAOF is not serious about that; that's pretty much the worst possible API.00:36
RAOFI'll make some coffee while thinking.00:37
bschaeferalright i've asked far to many questions this early for you haha00:37
bschaeferRAOF, o also this if for the pocket PC so i can imagine it having some priority00:45
RAOFIt's not all *that* early :)00:45
bschaeferall the settings: https://wiki.ubuntu.com/MouseAndTouchpad#prompting00:45
* bschaefer has no clue if those are even *real* settings00:46
bschaeferin libinput00:46
bschaefermainly i see this: http://paste.ubuntu.com/12076130/00:46
bschaeferlooking at http://wayland.freedesktop.org/libinput/doc/0.21.0/libinput_8h_source.html00:47
RAOFIs the relevant bit for HEAD.00:47
bschaeferRAOF, oo sweet thanks00:47
bschaeferright i see we are more after device configuration00:48
RAOFSo, our relevant design constraints are:00:55
RAOFa) We ideally don't want to have to expose every input device property (for every input device type) in an API.00:57
RAOFb) We ideally preserve the opportunity for the system-compositor to act on input without worrying about a nested compositor also handling that input.00:57
bschaeferRAOF, input porperty mouse/keyboard?00:58
bschaefero i see yeah00:58
RAOFc) The users' shell needs access to various device input properties.00:59
bschaefero right ... yeah they'll need to get_* them as well so they can display the value00:59
bschaeferthat doubles what i thought needed to be done :)01:00
bschaeferRAOF, now B)...01:00
bschaeferwe need to let U-S-C connect with these devices to listen to events out side of mir?01:00
bschaeferor provide a way for U-S-C to get events01:00
bschaeferbut not eat them01:00
RAOFu-s-c already has a way to do that (as does U8)01:02
bschaeferRAOF, o i see, hmm and wouldnt we ideally want to make sure all the libinput stuff is hidden?01:02
bschaeferie. have an API with generic get/set for these types of properties*01:02
bschaeferRAOF, thats if done how the card is proposed atm01:02
RAOFRight; that runs into desire (a) :)01:03
bschaeferright hmm01:03
bschaeferRAOF, hmm soo it just sounds like the only way to do this well is to expose libinput stuff01:05
bschaeferand have U-S-C handle whats missing01:05
RAOFSo, I think probably the *nicest* solution is to have u-s-c hand off input fds to the U8.01:05
RAOFSo the nested compositor has a full input platform, and U8 can poke it directly without needing a client API.01:06
bschaeferthen that would make u8 have to poke the API here right? http://wayland.freedesktop.org/libinput/doc/latest/group__config.html01:07
bschaeferbased on the FD01:07
bschaeferRAOF, you did mention that would be ideal if U-S-C and U8 were setup correctly (in the fact that U8 is a mir client etc)01:08
RAOFBut that would be an internal, mirserver API, and that's far more malleable than a client API (which then needs RPC support and such).01:08
bschaeferRAOF, what problems would that cause us in how things are set up now?01:08
RAOFThis also has the added benefit of reducing input latency somewhat, as U8 doesn't need to wait for usc to wake up, process the input event, write it to U8's socket, and then U8 wakes up.01:08
bschaeferRPC support sounds annoying, but there was a mention of dbus to libinput?01:08
RAOFThat's the sideband option, yes :)01:08
bschaeferso we could just skip from a client api --dbus> platform (libinput)01:09
RAOFThat option is: U-S-C exposes a DBus API for prodding these things.01:09
bschaeferbut that still means we would need an API in mir which would need a list of device properties01:09
RAOFThat basically just replaces the mirclient RPC component with a DBus RPC component.01:09
bschaeferand libinput it self hooks up to?01:10
bschaeferby passing a client api?01:10
bschaeferRAOF, i suppose that would make things more ... platform independent01:10
RAOFWell, not really.01:10
* bschaefer has no context on the idea of having multiple platforms01:10
bschaeferfor mir at lease01:11
RAOFIt has exactly the same problems as a mir client API :)01:11
bschaefersince i see an X11 platform (which just uses libinput)01:11
RAOFExcept that dbus is a nicer RPC mechanism than ours ;)01:11
bschaeferyeah as each platform could have its own quirks01:11
bschaeferthat 1 api couldnt rule over01:11
bschaeferRAOF, o ... and U-S-C IS the MIR SERVER01:12
bschaeferplatform --> USC --> client?01:12
bschaeferplatform --> USC --> U8?01:12
RAOFusc is *a* mir server, yes.01:12
bschaeferi see, i just now understood that part...01:12
RAOFPlatform is entirely hidden from USC by libmirserver.01:12
bschaeferso platform --> libserver --> USC?01:12
bschaeferin how things would have to talk?01:13
bschaeferor does libmirserver even have a public API?01:13
RAOFOh, absolutely.01:13
RAOFIt's the API that USC uses.01:13
bschaeferi see ok01:13
RAOFMostly it's mir::Server01:13
bschaeferso the client API would sit between USC and U*01:13
RAOFU8 is *also* a Mir server.01:14
bschaeferso then the client API would expose a FD01:14
bregmawhat's wrong with having a D-Bus API for enumerating devices and their settinsg (and maybe changing some as appropriate)?01:14
bschaefero...geez right01:14
bschaefersince its a *nested* server01:14
RAOFbregma: Mainly that you now need to abstract over your input platforms, and leak that abstraction through to a client.01:15
bschaeferbregma, like a DBUS API for mouse settings (get/set) and keyboard (get/set)?01:15
RAOFbregma: You also need to be able to identify *which* client, as a multi-user system is going to have different configuration for different users.01:16
bregmaRAOD, it's going to need that abstraction somewhere01:16
RAOFbregma: Absolutely; but the less that abstraction is exposed the easier it is to change.01:17
bregmaalso, there is an arbitrary number of input devices and types and attrubites and settings and most of them are hot-pluggable, and D-Bus is ideal for that01:17
bregmaD-Bus decouples everything so nicely01:17
* bschaefer needs to learn dbus better01:18
RAOFYeah, but ‘arbitrary number and types of attributes’ is just pushing complexity on to the client.01:18
RAOFI mean, it makes it easier to have code that *builds*, but more difficult to have code that *works*.01:18
bregmawell, it's complex and only the client really understand what it wants to do with the input01:18
RAOFCorrect! Which is why it should be doing the input processing :)01:19
bschaeferRAOF, why cant we give the client already in use devices? ie. a list of all connected devices in which they can get/set info to? (im missing a lot of context here) :(01:19
RAOFSee-also: pointer barriers ;)01:19
bschaeferin such a way where we enum over the connected devices rather then potential devices01:19
bregmawe're going to need something like pointer barriers sooner rather than later, because of the whole press-the-left-edge-to-reveal-the-Launcher thing going on01:20
RAOFYes. That should be implemented by the shell, *not* by USC.01:20
RAOFHaving it implementable by the shell is one of the major architectural motivations for Mir-like things!01:21
bregmaprobably...  I lack the architectural view of some of this stuff01:21
bregmaRAOF, you're thinking the best thing to do would be to pass an evdev fd through a C api to the client and let it worry about doing settings things itself?01:22
bschaeferRAOF, which i think we all agree on, the only thing we are trying to figure out is how to get configuration changes to libinput;...01:22
bschaeferwhich right ... theres all these different ways to do this :)01:23
* bschaefer talking about having the shell implement barriers01:23
bregmathat sort of implies sticking to libinput exclusively in the future, no?  Or is it an evdev-level fd that bypasses libput?01:23
RAOFIt's an evdev-level fd that bypasses libinput.01:23
RAOFI guess it's not even necessarily an evdev fd; it's just *an* fd.01:24
bschaeferwouldnt they still need their own input platform which connects directly to libinput?01:24
bregmaI though some of the settings being passed were libinput settings, not evdev settings01:24
bschaeferright, at lease that can be abstracted01:24
RAOFIt just so happens that we don't currently have any input devices that *don't* use evdev, but I'm not sure that's something we can reliably bake in.01:24
bschaeferbregma, well i think you get an FD device then use it to change libinput01:24
RAOFYou give the fd to libinput.01:24
bschaeferso sometime in the future when libinput isnt around, you would just pass the fd to w/e handles input at that point?01:25
bregmaI'm just thinking things like pointer acceleration is a libinput thing, not an evdev thing01:25
* bschaefer just thought you would pass the fd to libinput then change the acceleration your self in the shell01:26
bschaeferfrom the evdev FD01:26
RAOFRight. This does need libinput to be extended with the ability to create a device from an evdev fd rather than a path.01:27
RAOFbschaefer: Exactly. The nested compositor has an input platform, which will be libinput, and adds devices based on the fds it receives.01:28
bschaeferRAOF, it sounds nice, i just dont 100% know all the details in this :)01:28
bregmamaybe anpok can add that with his other upstream changes01:28
bschaeferthat would be nice...01:28
* bschaefer kind of assume you could get a evdev FD from a libinput device01:28
RAOFYou can't, no.01:28
bschaefero :(01:29
RAOFBut we create libinput devices from evdev fds (or, rather, from /dev/input/* paths), so that's fine.01:29
bschaeferi can at lease start making the API for that is suppose ... should just really be a function to mir_platform_get_fd?01:29
bregmais that a sadface with a little hat?01:29
bschaeferbregma, haha maybe01:29
bschaeferRAOF, right now i think i understand the supppppper broad picture, i think ill generate more questions in the details01:30
bschaeferthe only thing that seems to block this is actually getting a evdev fd01:31
bschaeferfrom the device to send to the Shell01:31
bregmajust so you know, anpok is off until the 20th (and I'm off until next Tuesday)01:31
bschaeferyeah ...my goal was to try to do as much as i could until he got back :)01:31
bschaeferbregma, enjoy your time off! Is it still summer there?01:32
RAOFI think the API would actually be something like mir_surface_set_raw_input_handler(), which would set up the callback to handle the fds sent.01:32
bschaeferthen the function pointer would just be01:32
RAOFbregma: But you're not on holiday today?01:32
bschaefer(int fd)01:32
bschaefervoid* ctx01:32
bregmabschaefer, I've got tickets to a Broadway show in NYC, I understand it's 32 and sticky there01:32
bschaeferbregma, o geez! But awesome! I think you told me you had those01:32
bschaeferor are you going again?01:32
bschaeferits 28C here now :(01:33
* bschaefer does not do well in hot weather01:33
RAOFbschaefer: You'd need a bit more than just int fd; although possibly just int[] fd, int num_fds.01:33
bregmano, this is it, my wife's 50th birthday presemt01:33
bschaeferbregma, awesome, well that sounds like a fun trip01:33
bschaeferRAOF, a list of FDs? I was thinking each FD would get sent individually but idk why :)01:34
bschaeferwhich is fine01:34
RAOFEither is probably fine; a list probably makes it a bit easier.01:34
bschaeferRAOF, that function would get called....when an input came down on the fd?01:34
RAOFThat function would get called each time:01:35
RAOFa) A new input device was added01:35
bschaeferor one removed01:35
RAOFb) The surface received focus (and so a set of input device fds need to be sent)01:35
bschaeferoo that makes sense, was thinking that would be independent of surfaces01:35
bschaeferbut i guess surfaces can filter what devices work on it?01:36
RAOFYeah, it can't really be.01:36
bschaeferor something?01:36
RAOFThis is the bit where having an explicitly different system-compositor→nested compositor would make a whole lot of sense.01:36
bschaeferwhich is what we have now?01:36
bschaeferwith USC->U8?01:36
RAOFWhich is not what we have now.01:37
* bschaefer needs to learn how to draw that arrow01:37
RAOFAny API that U8 needs is also available to an arbitrary other cilent.01:37
bschaefero i see01:37
bschaefersince its the server/client01:37
RAOF(Modulo permission bits enforced by USC)01:37
bschaeferat the same time01:37
RAOFU8 *is* a Mir client :){01:37
bschaeferhmm yeah01:37
bschaeferRAOF, so far this is making sense but i know as soon as i start to write any code my mind will go blank :)01:38
bschaeferbut so far that makes sense01:38
RAOFThe reason we need to send device fds on surface focus is that we will *revoke* those fds on surface unfocus.01:38
bschaeferRAOF, fds are specific to each surface?01:39
bschaeferi see, didnt know that i thought it was more server specific01:39
bschaeferand a surface on the server it self would have the same FD/devices01:39
bschaefersoo thats a part that will have to be touched in the server, when a surface is released to send that off01:40
RAOFhttp://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7dc65737c9a607d3e6f8478659876074ad129b8 is the relevant bit.01:40
bschaeferRAOF, duh, that makes a lot more sense from the first sentence haha01:40
bschaeferRAOF, cool thanks for all the info! Ill be sure to have more questions come next week01:41
* bschaefer tries to write everything down so far coverd01:41
bschaeferRAOF, o also there was some questions on the attestable cookie MP when ever you get a chance to read though01:50
RAOFYeah, I'm looking through it.01:51
bschaefer(one being about providing a way to produce cookies public wise)01:51
bschaeferRAOF, cool thanks!01:51
=== c74d is now known as Guest68804
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
alan_galf: @mir-on-x-grab-keyboard - am I missing some incantation to activate the grab? "$bin/mir_demo_server --launch-client bin/mir_demo_client_multiwin" and try various key combinations.09:02
alfalan_g: what works for me is explicitly setting the input platform --platform-input-lib=lib/server-modules/server-mesa-x11.so.409:31
alan_galf: that helps. Thanks09:39
=== greyback__ is now known as greyback
=== pete-woods1 is now known as pete-woods
alan_gWTF?! "static inline std::chrono::nanoseconds seconds_to_nanoseconds(std::chrono::nanoseconds secs)"10:31
=== chihchun is now known as chihchun_afk
=== alan_g is now known as alan_g|lunch
=== MerryChristmas is now known as benonsotfware
=== benonsotfware is now known as benonsoftware
=== alan_g|lunch is now known as alan_g
attentehi. unity-system-compositor is crashing for me with: "/usr/sbin/unity-system-compositor: relocation error: /usr/sbin/unity-system-compositor: symbol _ZN3mir6Server24add_configuration_optionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_NS_10OptionTypeE, version MIR_SERVER_32 not defined in file libmirserver.so.32 with link time reference"13:25
alan_gattente: that's a g++5/g++4 mismatch. (Part of the "gcc5 transition")13:27
attentealan_g: oh... is there any temporary workaround for it?13:29
alan_gWell, I've just avoided updating anything from archive.13:30
alan_gWhat stack are you seeing this on?13:31
attentealan_g: just did an update on wily13:31
alan_gYour using unity-system-compositor on a desktop?13:33
attentealan_g: yes, was trying to run u813:33
alan_gYou've likely downloaded a bizarre mix of g++4.9/g++5 packages. So...13:34
alan_gYou could try finding an 4.9 build of USC and reinstalling, but you're likely to run into other (similar) problems depending what's in archive.13:35
alan_gFWIW The "__cxx1112basic_string" is g++5's new string implementation. So USC is built with g++5 and libmirserver isn't.13:36
attentealan_g: ok, thanks. do you think rebuilding the mir packages with g++5 would work?13:43
alan_gattente: maybe. It depends what 4.8/5 mix of libs you now have. (e.g. boost and protobuf)13:44
attentealan_g: ok, i'll try it anyways13:45
=== alan_g is now known as alan_g|EOW
popeykgunn: what's the state of silo 0, is it still broken? Any ETA for it not being?20:03
tedpopey, patches welcome! ;-)20:32
popeyted: you don't want my patches :)20:38
tedpopey, Perhaps, but we're talking about kgunn here — he knows how to translate from "Old English" to American. ;-)20:39

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