| 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:57 |
| 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:58 |
| 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? | 01:59 |
| 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:00 |
| * 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:01 |
| 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:02 | |
| 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:03 |
| 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:04 | |
| 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:05 |
| * 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 | |
| * 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| RAOF | We certainly need configuration points in the input platform; they'll basically just forward to the relevant libinput thing. | 02:28 |
| 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:32 |
| 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:33 |
| 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:34 |
| * 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:35 |
| bschaefer | RAOF, would there be a benefit of having both implemented? | 02:36 |
| RAOF | Vaguely? | 02:36 |
| RAOF | Kinda, maybe. | 02:37 |
| bschaefer | just a thought is all (need to get more context on everything really) | 02:37 |
| * RAOF luncheons | 02:46 | |
| === JanC_ is now known as JanC | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | Woot! My branch fails for actual reasons! | 07:07 |
| duflu | RAOF: Yes, we have real sensible failures now :) | 07:29 |
| * guest42315 𝖎 𝖓𝖊𝖊𝖉 𝖇𝖑𝖔𝖔𝖉! | 09:20 | |
| === guest42315 is now known as drk|aw | ||
| === greyback_ is now known as greyback|shops | ||
| === greyback|shops is now known as greyback | ||
| 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:55 |
| greyback | oh hang, let me try exactly what you said | 10:56 |
| * greyback 's phone rebooted, suspects a trap | 10:56 | |
| greyback | alf: I think that's a bug indeed | 10:57 |
| 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:58 |
| 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 | 10:59 |
| greyback | note if you're looking for stuff to do, the display configuration api for system settings would be nice ;) | 11:00 |
| 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:07 |
| greyback | alf: yeah understood, was just being cheeky :) | 11:08 |
| 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 |
| ubot5 | 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 |
| greyback | alf: ack | 11:11 |
| alf | greyback: how does unity8 detect a long power-key press? | 11:14 |
| greyback | alf: is in unity8, qml/Components/PhysicalKeysMapper.qml - nothing too special, listens for key events, uses timer | 11:16 |
| 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:17 |
| 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:18 |
| alf | greyback: yes, so // FIXME: We only consider power key presses if the screen is 74 // on because of bugs 1410830/1409003. | 11:20 |
| ubot5 | 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 |
| alf | greyback: "... we simply won't | 11:20 |
| 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 | 11:21 |
| === 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 | ||
| 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:23 |
| alan_g | AlbertA: thanks | 16:24 |
| === 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 | ||
| 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:42 |
| * bschaefer tries to figure out the smallest amount of changes needed for a libinput_device add_device_from_fd_and_path | 19:43 | |
| === dandrader|afk is now known as dandrader | ||
| 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:23 |
| * bschaefer will probably just add something to a struct to check if we own it or not | 20:24 | |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| RAOF | Woot! | 23:24 |
| 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:25 | |
| bschaefer | since SDL2 only stays with LTS :( | 23:26 |
| bschaefer | upstream | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!