[01:57] RAOF, hey, soo digging through libinput today, looks like minimal work to add a function to get an FD from a libinput_device [01:57] though the other way around will be a bit trickier [01:57] Right. [01:57] * bschaefer assumes passing in the libinput struct [01:57] and fd [01:57] and going through all the event devices [01:57] and checking if the FD == FD [01:58] RAOF, cant imagine that taking to much time either [01:58] RAOF, which from there... i should be digging around the libinput-platform in mir to figure out where we can collect said FDs [01:59] At worst we'd need to pass in the path and the fd; libinput does need a way to probe the udev properties for the device, and I don't think it'd be able to do that given just an fd. [01:59] per surface, and figure out where to send that info on the callback (if its setup for the surface)? [01:59] RAOF, o i see, the only function i saw that did that was a add_device [01:59] from a path [01:59] which im not sure if that what we *really* want [01:59] Hm, why not? [02:00] RAOF, well wouldnt that add a device that is already added? [02:00] Why would it be already added? [02:00] hmm well since we would be passing the FD? [02:00] to unity8 [02:00] we would need that FD to get a libinput_device struct [02:01] * bschaefer assumes at that point we already have added the device [02:01] RAOF, cause the over issue is unity8 getting a libinput_device struct from a list of FDs we send it [02:01] Yeah, Unity8 has its own libinput context. [02:01] ooo i see [02:02] so yeah... we'll need to pass and FD + path? [02:02] with this function? [02:02] so it can open it, it self? [02:02] Yeah. We might be able to get away with just the fd, but I'm not sure. [02:02] yeah thats something that should be checked [02:02] Well, we don't want it to open it itself (indeed, we want it to be *impossible* for it to open it itself) [02:02] * bschaefer is new to udev/evdev/libinput [02:03] RAOF, we just want it to have a handled on the device that libinput_platform has right? [02:03] though if it has its own libinput context... [02:03] not 100% sure how that'll work out [02:03] bschaefer: Unity8 will have a libinput_platform itself. [02:03] ie: *both* USC and U8 will have a fully armed and operational input platform. [02:03] ooo ... ok that confuses things a bit :), since i thought the platform would set under USC [02:04] o geez yeah [02:04] so platform --> USC --> (platform --> U8)? [02:04] The only difference being that USC populates its platform from udev + open(), and U8 populates its platform from the fds it receives. [02:04] Right. platform → USC → platform → U8. [02:04] RAOF, they would both get events at the same time thougH? [02:04] from the same events [02:04] * bschaefer finds that strange [02:05] does U8 just filter out the extra events? [02:05] or listens to what it wants and ignore USC events? [02:05] im now imagining, USC handles its events [02:05] and U8 handles its events [02:05] We can either (a) have U8 not register a surface event handler, or (b) send no surface events when a client has subscribed to raw mode. [02:05] with out much talk [02:06] * bschaefer finds nested servers strange [02:06] RAOF, i think im slowly getting the idea though [02:06] This is also not very different from the status quo - it's platform → USC → (nested) platform → U8. [02:06] right but theres [02:06] We'd just be changing (a) what gets sent from USC → U8 and how the nested platform works. [02:06] USC --> (platform) --> U8 (server) --> U8 client [02:07] i see, i didnt think there was 2 platforms [02:07] so we just need to in a sense clone the platform layer [02:07] that sits below USC [02:07] to the nested platform? [02:07] Pretty much, yeah. [02:07] now how will U8 change configurations then? [02:07] By interacting with the input platform directly. [02:08] form the client? [02:08] or its nested server bit? [02:08] ie. its created server will have to talk to the 'cloned' platform [02:08] and then configure it, which will then configure the fds opened by udev in USC? [02:09] The nested server bit; U8 is getting its input from its own input platform (as is currently the case) - if we send the fds over, U8's input platform can have full control over how to interpret the bits. [02:09] i see that makes much more sense [02:09] There's no configuration of the fds opened in USC. [02:09] The only configuration in the input platform is how the input platform interprets the events it gets on the fds. [02:09] * bschaefer wonders how handling saved configurations will be hanlded [02:09] So if U8's input platform is reading the events from the fds, it gets to do whatever it wants with them. [02:09] thats to far up [02:10] Saved configurations is *definitely* U8's job. [02:10] RAOF, so we pretty much just need to tell U8 what devices to add [02:10] to its input context [02:10] RAOF, then whats the point of sending the FD it self if we arent planning on changing the input context in USC? [02:10] * bschaefer thinks a device path would be better then an FD at this poin [02:10] point [02:10] RAOF, but i think im missing something :) [02:10] bschaefer: Because U8 can't open the device itself - if it *could* open the device itself then it can read input. [02:11] o i see [02:11] Even when (a) USC wants to eat that input, and more importantly (b) even when there's another session active. [02:12] RAOF, so .. the only thing im stuck on is how do we add a device to the input context with an FD :) [02:12] * bschaefer will have to dig into that [02:12] which you were saying might not be possible [02:12] If you pass in the device path as well it'll be easy. [02:12] with out a path, but reading libinput API it looks like add_device just needs a lib input context [02:12] right [02:12] it doesnt 'open' the device [02:12] it just adds it to the internal list of devices [02:12] which is what we want [02:13] RAOF, so yeah, i think we just need to pass a path vs needing an FD at all [02:13] libinput_path_add_device(struct libinput *libinput, [02:13] const char *path); [02:13] Right, but that's not going to work because libinput won't be able to open the device :) [02:13] That's why we're passing in an fd. [02:13] If the device was successfully initialized... hmm [02:14] If you do exactly that but *also* pass in an fd and use it instead of wherever libinput calls open() on that device... [02:14] yeah i need to take at look at what that means [02:14] so we'll have to figure out how to add a device with an FD and a path (which is unsupported atm) [02:14] from what i see [02:14] At some point in libinput_path_add_device there's going to be a call to open(/the/path) to get the fd libinput will poll on. [02:15] Exactly. [02:15] right, which i was missing [02:15] but yeah we'll have to add our own function to then use the FD [02:15] * bschaefer checks what else it uses that path for [02:17] * bschaefer needs to re-read the backlog [02:17] as i think we covered this, but if we dont need to 'open' the device then we shouldnt need the path :) [02:18] we just need to create a libinput_device based on that FD [02:18] vs going through evdev to create a device with the path [02:19] 'libinput does need a way to probe the udev properties for the device' [02:19] right which i uses the path for that [02:19] ok [02:19] that makes more sense now [02:19] that is... if it really needs to probe for those and if it uses the path or fd (ill have to check) [02:20] RAOF, so after that, ill need to look at adding a new function in toolkit for a mir surface to add a raw input handler [02:20] (that should be less then a day of work) [02:20] RAOF, after that... its mainly just U8 doing the rest of the work? [02:21] in qtmir? [02:21] We then need to make the appropriate changes to the nested input platform. [02:21] And expose the relevant configuration points out of the input platform. [02:21] that sits in qtmir right? [02:21] Nah, Mir. [02:22] o hmm i thought qtmir was the nested server it self [02:22] or i need to look at the nested bits that are in mir it self? [02:22] qtmir uses libmirserver... [02:22] i see yeah [02:22] Yeah, the nested bits that are in Mir itself. [02:22] but we have to fix the functions it uses :) [02:22] RAOF, so, ill try to focus on figuring out as much as i can with the libinput part (mainly just try to make a function that create a device based on the FD passed) [02:22] qtmir (should) run fine on the bare-metal, too. The choice of platform is contained within libmirserver, not in qtmir. [02:23] and populate a valid struct [02:23] Yeah, that'd be a reasonable first step. [02:23] cool thanks that should be fun! [02:23] Because most of the rest of this is going to be the same whether or not we do the input-bypass trick. [02:24] Well, maybe not most. But we certainly need to provide the relevant configuration points from the input platform regardless. [02:24] yeah, the libinput stuff seems needed no matter way for the nested server stuff [02:24] * bschaefer cant english [02:24] and its my only language :( [02:24] no matter what* for the nested server [02:24] but ... really im not sure [02:28] We certainly need configuration points in the input platform; they'll basically just forward to the relevant libinput thing. [02:32] RAOF, this will be the API that is needed overall? [02:32] so we'll just need to forward set_cursor_accel suff? [02:32] etc* [02:32] Yeah, that's roughly it. [02:33] cool that should just be a simple 1to1 mapping [02:33] which would be very nice [02:33] If we do the input-bypass, then the nested input platform can expose those easily. If we don't do input-bypass, then USC needs to expose those over DBus (or whatever). [02:34] so either or we'll need those functions [02:34] I think you mean ‘so either way we'll need those functions’? [02:34] And, yes :) [02:34] RAOF, that is what i mean [02:34] :) [02:35] * bschaefer think 'either or' means if we pick 1 or the other [02:35] * bschaefer should work on english [02:35] its an xor haha [02:36] RAOF, would there be a benefit of having both implemented? [02:36] Vaguely? [02:37] Kinda, maybe. [02:37] just a thought is all (need to get more context on everything really) [02:46] * RAOF luncheons === JanC_ is now known as JanC === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:07] Woot! My branch fails for actual reasons! [07:29] RAOF: Yes, we have real sensible failures now :) [09:20] * guest42315 𝖎 𝖓𝖊𝖊𝖉 𝖇𝖑𝖔𝖔𝖉! === guest42315 is now known as drk|aw === greyback_ is now known as greyback|shops === greyback|shops is now known as greyback [10:55] greyback: I noticed that on meizu with rc.proposed a long press of the power button doesn't show the power-off dialog if the screen is off when the press starts. Is this expected? [10:55] alf: I just tried and it worked [10:56] oh hang, let me try exactly what you said [10:56] * greyback 's phone rebooted, suspects a trap [10:57] alf: I think that's a bug indeed [10:58] greyback: ... happened to me too, I assumed it's because I pressed the power button for too long (waiting for the dialog to appear but never did) [10:59] greyback: ok, I will file a bug in unity8, but I will also investigate USC in case something is going wrong there [10:59] alf: ok, thanks [11:00] note if you're looking for stuff to do, the display configuration api for system settings would be nice ;) [11:07] greyback: Not actively looking, my plate is full (unless priorities change and move me to a different plate)... This bug just caught my attention and just wanted to ensure we haven't messed up USC somehow :) [11:08] alf: yeah understood, was just being cheeky :) [11:11] greyback: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1486953 , I'll check USC and if I find anything suspicious I will add the project to the bug [11:11] Ubuntu bug 1486953 in unity8 (Ubuntu) "Power-off dialog doesn't show if power key press begins when screen is off" [High,New] [11:11] alf: ack [11:14] greyback: how does unity8 detect a long power-key press? [11:16] alf: is in unity8, qml/Components/PhysicalKeysMapper.qml - nothing too special, listens for key events, uses timer [11:17] greyback: ok, so it doesn't depend on USC (which makes sense, since I don't see anything in use to notify of it), which I guess rules out USC being the problem. [11:17] alf: probably, unless USC takes focus from the unity8 surface while display blanked [11:18] greyback: interesting [11:18] but I do see evidence of unity8 reading display state while figuring out key long press, so that's more likely the culprit [11:20] greyback: yes, so // FIXME: We only consider power key presses if the screen is 74 // on because of bugs 1410830/1409003. [11:20] bug 1410830 in Canonical System Image "Shutdown dialog appears on resume, after a long delay in screen turning on" [Critical,Fix released] https://launchpad.net/bugs/1410830 [11:20] greyback: "... we simply won't [11:21] alf: which is lame [11:21] initiate any dialogs when the screen is off [11:21] " [11:21] we can do that better [11:21] surely === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [16:23] AlbertA: I just spotted a 0.15 bug: there's a 9.1 stanza in client/symbols.map, but include/client/mir_toolkit/version.h has #define MIR_CLIENT_MINOR_VERSION (0) - that ought to be #define MIR_CLIENT_MINOR_VERSION (1) [16:23] alan_g: ack...will updated 0.15 [16:23] update [16:24] AlbertA: thanks === drk|aw is now known as o === o is now known as Guest83769 === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|afk [19:42] RAOF, just an update, it looks like we will need the path, mainly for properties and asserting we arent a test device [19:42] as well as checking our fd opened is the same as our devnode [19:42] so far its a pretty length path down to a evdev_create (where the open happens) [19:43] * bschaefer tries to figure out the smallest amount of changes needed for a libinput_device add_device_from_fd_and_path === dandrader|afk is now known as dandrader [20:23] also the other issue i need to consider.... when our libinput context gets cleaned up [20:23] we need to make sure not to close on the FD [20:23] since we didnt open it [20:24] * bschaefer will probably just add something to a struct to check if we own it or not === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [23:19] bschaefer: Actually, it should be fine to close the fd on cleanup. [23:19] It'll only close the local handle, and since in the case where we're cleaning up the libinput context we clearly don't expect to receive any more input, that should be fine :) [23:20] RAOF, well i was seeing suspend/resume [23:20] Aaah, yeah. [23:20] Sure. [23:20] RAOF, o i see right on that part [23:20] was just worried about doing a close restricted on the fd it self :) [23:20] RAOF, ill just have to work with that (and be aware of that) [23:20] since we skip open when we get the fd/path [23:21] Even there we might be able to get away with it, as suspend will (probably?) happen when U8 loses focus and hence has its input fds revoked anyway? [23:21] RAOF, i think ill make note of it to check [23:21] but go with seeing what happens first :) [23:21] Yeah, sounds sensible :) [23:22] RAOF, other then that... just trying to make more head way, trying to make just 1 function init the struct it self [23:22] but just reading code at this point [23:22] also fixed up the attestable branch, was missing the ABI check in tools/update_package_abis.sh [23:22] and once this lands: https://code.launchpad.net/~brandontschaefer/mir/msg-auth-code-field-added/+merge/268383 [23:22] i can clean up attestable and get it ready for an actual merge [23:24] Woot! [23:25] would be nice :) (i would like to get RaiseWindow working once thats landed :) [23:25] for sdl [23:25] Yeah, that'd be good. [23:25] * bschaefer wants to get as much SDL stuff done by 16.04 [23:26] since SDL2 only stays with LTS :( [23:26] upstream