[01:57] <bschaefer> 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] <bschaefer> though the other way around will be a bit trickier
[01:57] <RAOF> Right.
[01:57]  * bschaefer assumes passing in the libinput struct
[01:57] <bschaefer> and fd
[01:57] <bschaefer> and going through all the event devices
[01:57] <bschaefer> and checking if the FD == FD
[01:58] <bschaefer> RAOF, cant imagine that taking to much time either
[01:58] <bschaefer> 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] <RAOF> 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] <bschaefer> per surface, and figure out where to send that info on the callback (if its setup for the surface)?
[01:59] <bschaefer> RAOF, o i see, the only function i saw that did that was a add_device
[01:59] <bschaefer> from a path
[01:59] <bschaefer> which im not sure if that what we *really* want
[01:59] <RAOF> Hm, why not?
[02:00] <bschaefer> RAOF, well wouldnt that add a device that is already added?
[02:00] <RAOF> Why would it be already added?
[02:00] <bschaefer> hmm well since we would be passing the FD?
[02:00] <bschaefer> to unity8
[02:00] <bschaefer> 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] <bschaefer> RAOF, cause the over issue is unity8 getting a libinput_device struct from a list of FDs we send it
[02:01] <RAOF> Yeah, Unity8 has its own libinput context.
[02:01] <bschaefer> ooo i see
[02:02] <bschaefer> so yeah... we'll need to pass and FD + path?
[02:02] <bschaefer> with this function?
[02:02] <bschaefer> so it can open it, it self?
[02:02] <RAOF> Yeah. We might be able to get away with just the fd, but I'm not sure.
[02:02] <bschaefer> yeah thats something that should be checked
[02:02] <RAOF> 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] <bschaefer> RAOF, we just want it to have a handled on the device that libinput_platform has right?
[02:03] <bschaefer> though if it has its own libinput context...
[02:03] <bschaefer> not 100% sure how that'll work out
[02:03] <RAOF> bschaefer: Unity8 will have a libinput_platform itself.
[02:03] <RAOF> ie: *both* USC and U8 will have a fully armed and operational input platform.
[02:03] <bschaefer> ooo ... ok that confuses things a bit :), since i thought the platform would set under USC
[02:04] <bschaefer> o geez yeah
[02:04] <bschaefer> so platform --> USC --> (platform --> U8)?
[02:04] <RAOF> The only difference being that USC populates its platform from udev + open(), and U8 populates its platform from the fds it receives.
[02:04] <RAOF> Right. platform → USC → platform → U8.
[02:04] <bschaefer> RAOF, they would both get events at the same time thougH?
[02:04] <bschaefer> from the same events
[02:04]  * bschaefer finds that strange
[02:05] <bschaefer> does U8 just filter out the extra events?
[02:05] <bschaefer> or listens to what it wants and ignore USC events?
[02:05] <bschaefer> im now imagining, USC handles its events
[02:05] <bschaefer> and U8 handles its events
[02:05] <RAOF> 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] <bschaefer> with out much talk
[02:06]  * bschaefer finds nested servers strange
[02:06] <bschaefer> RAOF, i think im slowly getting the idea though
[02:06] <RAOF> This is also not very different from the status quo - it's platform → USC → (nested) platform → U8.
[02:06] <bschaefer> right but theres
[02:06] <RAOF> We'd just be changing (a) what gets sent from USC → U8 and how the nested platform works.
[02:06] <bschaefer> USC --> (platform) --> U8 (server) --> U8 client
[02:07] <bschaefer> i see, i didnt think there was 2 platforms
[02:07] <bschaefer> so we just need to in a sense clone the platform layer
[02:07] <bschaefer> that sits below USC
[02:07] <bschaefer> to the nested platform?
[02:07] <RAOF> Pretty much, yeah.
[02:07] <bschaefer> now how will U8 change configurations then?
[02:07] <RAOF> By interacting with the input platform directly.
[02:08] <bschaefer> form the client?
[02:08] <bschaefer> or its nested server bit?
[02:08] <bschaefer> ie. its created server will have to talk to the 'cloned' platform
[02:08] <bschaefer> and then configure it, which will then configure the fds opened by udev in USC?
[02:09] <RAOF> 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] <bschaefer> i see that makes much more sense
[02:09] <RAOF> There's no configuration of the fds opened in USC.
[02:09] <RAOF> 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] <RAOF> So if U8's input platform is reading the events from the fds, it gets to do whatever it wants with them.
[02:09] <bschaefer> thats to far up
[02:10] <RAOF> Saved configurations is *definitely* U8's job.
[02:10] <bschaefer> RAOF, so we pretty much just need to tell U8 what devices to add
[02:10] <bschaefer> to its input context
[02:10] <bschaefer> 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] <bschaefer> point
[02:10] <bschaefer> RAOF, but i think im missing something :)
[02:10] <RAOF> bschaefer: Because U8 can't open the device itself - if it *could* open the device itself then it can read input.
[02:11] <bschaefer> o i see
[02:11] <RAOF> Even when (a) USC wants to eat that input, and more importantly (b) even when there's another session active.
[02:12] <bschaefer> 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] <bschaefer> which you were saying might not be possible
[02:12] <RAOF> If you pass in the device path as well it'll be easy.
[02:12] <bschaefer> with out a path, but reading libinput API it looks like add_device just needs a lib input context
[02:12] <bschaefer> right
[02:12] <bschaefer> it doesnt 'open' the device
[02:12] <bschaefer> it just adds it to the internal list of devices
[02:12] <bschaefer> which is what we want
[02:13] <bschaefer> RAOF, so yeah, i think we just need to pass a path vs needing an FD at all
[02:13] <bschaefer> libinput_path_add_device(struct libinput *libinput,
[02:13] <bschaefer>        const char *path);
[02:13] <RAOF> Right, but that's not going to work because libinput won't be able to open the device :)
[02:13] <RAOF> That's why we're passing in an fd.
[02:13] <bschaefer> If the device was successfully initialized... hmm
[02:14] <RAOF> 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] <bschaefer> yeah i need to take at look at what that means
[02:14] <bschaefer> so we'll have to figure out how to add a device with an FD and a path (which is unsupported atm)
[02:14] <bschaefer> from what i see
[02:14] <RAOF> 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] <RAOF> Exactly.
[02:15] <bschaefer> right, which i was missing
[02:15] <bschaefer> 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] <bschaefer> as i think we covered this, but if we dont need to 'open' the device then we shouldnt need the path :)
[02:18] <bschaefer> we just need to create a libinput_device based on that FD
[02:18] <bschaefer> vs going through evdev to create a device with the path
[02:19] <bschaefer> 'libinput does need a way to probe the udev properties for the device'
[02:19] <bschaefer> right which i uses the path for that
[02:19] <bschaefer> ok
[02:19] <bschaefer> that makes more sense now
[02:19] <bschaefer> that is... if it really needs to probe for those and if it uses the path or fd (ill have to check)
[02:20] <bschaefer> 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] <bschaefer> (that should be less then a day of work)
[02:20] <bschaefer> RAOF, after that... its mainly just U8 doing the rest of the work?
[02:21] <bschaefer> in qtmir?
[02:21] <RAOF> We then need to make the appropriate changes to the nested input platform.
[02:21] <RAOF> And expose the relevant configuration points out of the input platform.
[02:21] <bschaefer> that sits in qtmir right?
[02:21] <RAOF> Nah, Mir.
[02:22] <bschaefer> o hmm i thought qtmir was the nested server it self
[02:22] <bschaefer> or i need to look at the nested bits that are in mir it self?
[02:22] <RAOF> qtmir uses libmirserver...
[02:22] <bschaefer> i see yeah
[02:22] <RAOF> Yeah, the nested bits that are in Mir itself.
[02:22] <bschaefer> but we have to fix the functions it uses :)
[02:22] <bschaefer> 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] <RAOF> qtmir (should) run fine on the bare-metal, too. The choice of platform is contained within libmirserver, not in qtmir.
[02:23] <bschaefer> and populate a valid struct
[02:23] <RAOF> Yeah, that'd be a reasonable first step.
[02:23] <bschaefer> cool thanks that should be fun!
[02:23] <RAOF> Because most of the rest of this is going to be the same whether or not we do the input-bypass trick.
[02:24] <RAOF> Well, maybe not most. But we certainly need to provide the relevant configuration points from the input platform regardless.
[02:24] <bschaefer> yeah, the libinput stuff seems needed no matter way for the nested server stuff
[02:24]  * bschaefer cant english
[02:24] <bschaefer> and its my only language :(
[02:24] <bschaefer> no matter what* for the nested server
[02:24] <bschaefer> but ... really im not sure
[02:28] <RAOF> We certainly need configuration points in the input platform; they'll basically just forward to the relevant libinput thing.
[02:32] <bschaefer> RAOF, this will be the API that is needed overall?
[02:32] <bschaefer> so we'll just need to forward set_cursor_accel suff?
[02:32] <bschaefer> etc*
[02:32] <RAOF> Yeah, that's roughly it.
[02:33] <bschaefer> cool that should just be a simple 1to1 mapping
[02:33] <bschaefer> which would be very nice
[02:33] <RAOF> 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] <bschaefer> so either or we'll need those functions
[02:34] <RAOF> I think you mean ‘so either way we'll need those functions’?
[02:34] <RAOF> And, yes :)
[02:34] <bschaefer> RAOF, that is what i mean
[02:34] <bschaefer> :)
[02:35]  * bschaefer think 'either or' means if we pick 1 or the other
[02:35]  * bschaefer should work on english
[02:35] <bschaefer> its an xor haha
[02:36] <bschaefer> RAOF, would there be a benefit of having both implemented?
[02:36] <RAOF> Vaguely?
[02:37] <RAOF> Kinda, maybe.
[02:37] <bschaefer> just a thought is all (need to get more context on everything really)
[02:46]  * RAOF luncheons
[07:07] <RAOF> Woot! My branch fails for actual reasons!
[07:29] <duflu> RAOF: Yes, we have real sensible failures now :)
[09:20]  * guest42315 𝖎 𝖓𝖊𝖊𝖉 𝖇𝖑𝖔𝖔𝖉!
[10:55] <alf> 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] <greyback> alf: I just tried and it worked
[10:56] <greyback> oh hang, let me try exactly what you said
[10:56]  * greyback 's phone rebooted, suspects a trap
[10:57] <greyback> alf: I think that's a bug indeed
[10:58] <alf> 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] <alf> greyback: ok, I will file a bug in unity8, but I will also investigate USC in case something is going wrong there
[10:59] <greyback> alf: ok, thanks
[11:00] <greyback> note if you're looking for stuff to do, the display configuration api for system settings would be nice ;)
[11:07] <alf> 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] <greyback> alf: yeah understood, was just being cheeky :)
[11:11] <alf> 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] <greyback> alf: ack
[11:14] <alf> greyback: how does unity8 detect a long power-key press?
[11:16] <greyback> alf: is in unity8, qml/Components/PhysicalKeysMapper.qml - nothing too special, listens for key events, uses timer
[11:17] <alf> 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] <greyback> alf: probably, unless USC takes focus from the unity8 surface while display blanked
[11:18] <alf> greyback: interesting
[11:18] <greyback> 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] <alf> greyback: yes, so // FIXME: We only consider power key presses if the screen is 74             // on because of bugs 1410830/1409003.
[11:20] <alf> greyback: "... we simply won't
[11:21] <greyback> alf: which is lame
[11:21] <alf>  initiate any dialogs when the screen is off
[11:21] <alf> "
[11:21] <greyback> we can do that better
[11:21] <greyback> surely
[16:23] <alan_g> 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] <AlbertA> alan_g: ack...will updated 0.15
[16:23] <AlbertA> update
[16:24] <alan_g> AlbertA: thanks
[19:42] <bschaefer> RAOF, just an update, it looks like we will need the path, mainly for properties and asserting we arent a test device
[19:42] <bschaefer> as well as checking our fd opened is the same as our devnode
[19:42] <bschaefer> 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
[20:23] <bschaefer> also the other issue i need to consider.... when our libinput context gets cleaned up
[20:23] <bschaefer> we need to make sure not to close on the FD
[20:23] <bschaefer> since we didnt open it
[20:24]  * bschaefer will probably just add something to a struct to check if we own it or not
[23:19] <RAOF> bschaefer: Actually, it should be fine to close the fd on cleanup.
[23:19] <RAOF> 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] <bschaefer> RAOF, well i was seeing suspend/resume
[23:20] <RAOF> Aaah, yeah.
[23:20] <RAOF> Sure.
[23:20] <bschaefer> RAOF, o i see right on that part
[23:20] <bschaefer> was just worried about doing a close restricted on the fd it self :)
[23:20] <bschaefer> RAOF, ill just have to work with that (and be aware of that)
[23:20] <bschaefer> since we skip open when we get the fd/path
[23:21] <RAOF> 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] <bschaefer> RAOF, i think ill make note of it to check
[23:21] <bschaefer> but go with seeing what happens first :)
[23:21] <RAOF> Yeah, sounds sensible :)
[23:22] <bschaefer> RAOF, other then that... just trying to make more head way, trying to make just 1 function init  the struct it self
[23:22] <bschaefer> but just reading code at this point
[23:22] <bschaefer> also fixed up the attestable branch, was missing the ABI check in tools/update_package_abis.sh
[23:22] <bschaefer> and once this lands: https://code.launchpad.net/~brandontschaefer/mir/msg-auth-code-field-added/+merge/268383
[23:22] <bschaefer> i can clean up attestable and get it ready for an actual merge
[23:24] <RAOF> Woot!
[23:25] <bschaefer> would be nice :) (i would like to get RaiseWindow working once thats landed :)
[23:25] <bschaefer> for sdl
[23:25] <RAOF> Yeah, that'd be good.
[23:25]  * bschaefer wants to get as much SDL stuff done by 16.04
[23:26] <bschaefer> since SDL2 only stays with LTS :(
[23:26] <bschaefer> upstream